IT Consultant Everyday Notes

Just some problems/solutions storage

Category Archives: Certificates

PKI: Chrome 58 gives a warning with HTTPS connection to a Web Server

Scenario: Web Server protected by a certificate issued by Internal Certification Authority (Microsoft ADCS).

Certificate has a single Subject Name on it Internet Explorer works fine, only Chrome is affected



This Server could not prove that it is <server name>; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection.

Resolution: I reissued the certificate and added Subject Alternative Name (SAN) with the same FQDN to it. After that I assigned the new certificate to the Web Server interface and restarted IIS. Chrome connects to the web server without any warnings now.


More about SAN:

PKI: Enterprise PKI MMC displays a Subordinated CA as offline

I built a two layer PKI infrastructure and brought an Enterprise PKI MMC to verify the infrastructure health. All is ok but an Issuing CA. That was displayed with Status: ‘Error” and the message was “This CA is currently offline or unavailable”.


At the same time I could right-click it, select manage and it brought a very nice working CA MMC for me. So the CA is up and running and works fine, but for some reasons shown as offline in Enterprise PKI MMC.

Google did not bring too much, but search in Technet Forums gave a clue:

I granted all permissions to my Domain Admins (this is Lab, otherwise it would be a custom security group). By default it was Manage CA and Issue and Manage Certificates only.


and restarted the Certificate Services. After that Enterprise PKI became nice and green.

Certificates: The Do’s and Don’ts of PKI

This is a copy of Andrzej Kaźmierczak’s blog post:


DON’T install PKI without a detailed plan. Ask yourself what you need it for, what features will you use and would it be scalable enough in the future.

DO use Windows Server Enterprise Edition for Active Directory users enrollment. UPDATE: This only applies to Windows Server 2008 R2 or earlier, as for Windows 2012 or later you can use Windows Server Standard Editions.

DO use a CAPolicy.inf file during installation. There you can define attributes such as basic constraints extension, renewal key length and period, CRLs period, etc.

Server naming and CA (Certification Authority ) naming should be standardized. DO create naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Root CA shouldn’t follow the pattern and be named differently than other servers in organization.

DON’T change CA server name after ADCS role installation. It is possible to rename server and reconfigure infrastructure, but not recommended. Enrolled certificates will stop working.

DON’T use Root CA to issue certificates directly to the end users.

DON’T install CA on a domain controller. It is technically possible, but not recommended. CA should run on a separate machine.

For high availability DO failover clustering. Only one CA instance can be running at a time. Microsoft ADCS role can act as active-passive using failover feature of Microsoft Windows operating system.

DO create CPS (Certificate Practice Statement) and CP (Certificate Policy). Structure of those two documents should be based on the RFC 3647 recommendations. This allows subscribers and relying parties comparison with other, similar documents issued by other organizations.

DO create multi-tiers architecture. For huge organizations, depending on Active Directory structure and amount of forests and domains, DO use 2 or 3-tier architecture.

In 3-tier architecture, subordinate CAs located in the second tier, are called Policy CAs. Those CAs should only enroll for other CAs and no users. DO put in CAPolicy.inf file for Policy Issuing CA following section:
Pathlength = 1
Critical = true
After installation run following command:
certutil –setreg Policy\CAPathLength 1
This “Pathlength=” setting specifies the length of the path, the maximum number of CA certificates that may be issued as subordinated to the Policy CA. Pathlength with value set to „1” means that establishment CA two (or more) tiers below Policy CA is not possible.

DON’T domain join Root CA or Subordinate CA. Let those most important, top-level CAs stay in workgroup.

DON’T use online Root and Policy CAs, especially if it’s private keys are not protected by HSM (Hardware Security Module). Offline CAs hard drives or virtual disk files should be placed in a secure vault until a CA certificate needs to be issued or a new CRL needs to be issued and published.

If using HSM that are located in distant server room, DON’T restart CA server or certsrv service. You may find out that you need to insert operator’s cards set into HSM to start the service again. Sometimes it needs involving many people.

If not using HSM, CA’s keys are generated with software CSP. DO use at least 4096b keylength for Root CA.

DO change default system accounts. Local administrator should have its name changed, the default Enterprise andDomain Administrators group permissions for CA should be taken away, and Domain Admins group should bedeleted from the local administrators group on all systems belonging to the PKI.

DO use long and complex local administrator password and DO make sure it is kept in safe place.

DON’T leave default AIA (Authority Information Access) URLs with the CA hostname in issued certificates.  Default value is %windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt. The part „%%1_” in CA certificate will be replaced by „<CAservername>_” which will reveal internal naming convention and structure. „%%1_” should be deleted. It is important to remember that during renewal process because .crt file will be generated with %%1_ prefix, so it has to be manually deleted after renewal operation.

If implementing in organizations, DO use templates OID to differentiate company’s policy objects from default Microsoft policy objects tree. You should request PEN (Private Enterprise Number) from IANA organization (Internet Assigned Numbers Authority). Templates OID should be created with PREFIX (got from IANA) and individually created numbers for template structure.

DO customize templates, DON’T use default ones. Use organization name prefixes with templates names, customize them and add OID created with IANA’s PREFIX.

After ADCS installation DO use following commands to publish CRLs and .crts to the Active Directory:
certutil -dspublish -f "name_of_root_ca_cert.CRT"  RootCA
certutil -dspublish -f "name_of_ca_crl.CRL"

UPDATE: As HTTP is recommended path to publish CRT and CRL there is no need to use CDP and AIA with LDAP and to publish them to AD.

DO make CDP (CRL Distribution Point) redundant. Include in CDP and publish CRLs to both LDAP and HTTP. Make sure that at least one HTTP is accessible from Internet, WAN or partner’s network. It is required if you want to use certificates outside your intranet. UPDATE: DO NOT use LDAP in your CDP path at all – use only HTTP and make sure HTTP location is highly available, highly consider using split-brain DNS scenario.

If however, you decide to distribute CRL using Active Directory, DO bear in mind AD replication delays.

DO implement OCSP. Online Certificate Status Protocol reduces CRL usage (bandwith) and is more reliable. End-users workstations cache CRL in local user profile, so user’s certificate revocation may become effective when cached CRL validity period is over. Unlike this CRL weakness, OCSP uses delta CRL, so to work efficiently I suggest setting Active Directory Certificate Services Delta CRL time to minimum period (30 minutes):
certutil -setreg CA\CRLDeltaPeriodUnits 30
certutil -setreg CA\CRLDeltaPeriod "Minutes"
OCSP should be available from both Internet and intranet.  Keep in mind that despite the revocation of the certificate, thepreferred method for removing user access to resources is disabling AD account.

DO use PKI repositories. Those are places to keep PKI related data. It can be a public web folder for all with CRLs and CA’s certificates or private folder for internal users only with CP, CPS, user’s .crt certificates, user’s regulations. CRLs and CA’s .crts as well.

Microsoft ADCS default repository is C:\Windows\System32\certsrv\CertEnroll. To that directory are published CRLs and CA’s .crt certificates. As mentioned before, CDP and AIA should be published redundantly – with HTTP protocol. DON’T publish CertEnroll folder directly to the Internet. Instead create a copying script which copies *.crt and *.crl to another machine and folder and create task schedule to trigger it every, let’s say, 5 minutes. When in another folder, publish to Internet with your reverse proxy, for example Microsoft Forefront Threat Management Gateway UPDATE: Microsoft TMG is discontinued. Be careful on credentials that are provided to run script. You can use this simple code below to create batch file:
xcopy C:\Windows\System32\certsrv\CertEnroll\* \\\Repository\* /Y /Q

DO role separation. In simple scenario these should be: PKIBackupOperators, PKITemplateAdmins, PKIAuditors, PKICertAdmins, PKICAAdmins.

In some cases DO set private keys archivization. Thanks to that you will be able to recover old keys used to secure data in the past.

DO set KRA (Key Recovery Agent) and DRA (Data Recovery Agent). Those two are one of the most important accounts that help recover important data and must be protected with increased caution. KRA can restore lost private key. DRA is a user granted the right to decrypt data encrypted by other users.

DON’T write down your user’s certificate password/PIN and stick it to monitor or hide under the keyboard.

Whenever possible, DO use tokens or smartcards for users and special purpose accounts (Enrollment Agents, etc). Without them private keys are generated by software CSP and kept in Windows registry! Whoever has access to workstation and knows where and how to look, may find these interesting things. To protect from that situation use smartcards which lets keys be generated by hardware CSP and if FIPS-3 compliance, never leave the smartcard.

DO take into account above when disposing user’s hard drives, especially CA hard drives. If not on smartcard, user’s private key is still on that hard drive.

DO make sure that system time on CAs machines is set correctly. The best way (but not cheap) is to use NTP (Network Time Protocol).

DO renew the CA certificate with a supply of time so that certificates issued by the CA have shorter life time than the remaining life time of the CA certificate.

DO enable all auditing events for the CA when configuring Microsoft ADCS:
certutil -setreg CA\AuditFilter 127
Also, enable ‘Audit Object Access’ within Group Policy (for ‘Success’ and/or ‘Failure’ as required) in order for any Cert Services events to be logged.

DO health check of PKI infrastructure. If using Microsoft ADCS, use tool PKIView. Moreover, PKI events are logged inSecurity event log on CA server. Use event viewer to check for events especially those red and yellow ones.

If needed to increase level of logging, DO change value „3” to „4” in following registry path:
HKLM\CurrentControlSet\Services\certsrv\configuration\Subordinate CA\Loglevel

DO create CA backup, including private key, CA certificate, certificate database and certificate database log, CAPolicy.inf file and exported CA templates. Make copy of folder „Database” including certpkxp.dat, edb*.log and<CAname>.edb files. Also export settings of registry path:

DO make sure that system backup is done regularly. Backups should be protected with password and kept in safe place (vault).

DON’T consider internally issued certificates as a qualified certificates. Qualified certificate is issued to a person acting on his or her own behalf by Trusted Third Party CA. Qualified certificates can be used to authenticate to government organizations.

Lync 2013: Multi-user IM conferencing issue (really Certificate chain issue)


Our IT guys called me seeking for support with a weird issue. Multi-user IM conferencing starts to fail. I checked and see an attempt to start “Meet now” failed too with error on connection to conferencing server.

On Client side it gives Error 500 (source ID 239).


In Event Log of Front end Server I saw Event ID 32042 from LS User Services:

“Invalid Incoming HTTPS Certificate”



I checked the certificate and it looked perfectly fine, not expired and with a proper chain.

Next day most contacts in Lync Client were observed in “Updating…” state. Not good.



We deployed a Microsoft KB 2901554 to fix SChannel Authentication Provider on Windows Server 2012 R2

Next I Run the following Power Shell command (one line):

Get-Childitem cert:\LocalMachine\root -Recurse |Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File c:\computer_filtered.txt

to figure out if there are any intermediate certs in Trusted Root certificate folder as recommended in this article

And found one certificate in the wrong container. I moved it in Intermediate Certification Authorities and restarted Lync Services. After that the issue seems to be resolved.

Lync: Request certificate for Reverse Proxy

First of all, Microsoft has an article for that.

But, the article did not work for me – Entrust needed additional fields (like Country, Locality) filled and for some reasons all my CSRs had 1024 key request even though I put 2048 in MMC Wizard.

Finally I decided to do it old way, via .inf file and certreq tool.

here is .inf file I created:


Note: the CSR requests SHA-1 certificate. Microsoft supports SHA-1 until 2017. You can tweak it to request SHA-2 cert.

PKI: How to clean faulty Certificate Request

I recently needed to update an Entrust certificate on my Lync Reverser Proxy. Lync does not have a Wizard to generate CSR so I used Microsoft KB to generate it. Unfortunately KB does not say you need to add Country, Locality and other information and CSR generated failed on Entrust. I added information, but in this case CSR failed because of key length – it has 1024 even though I put 2048. so I end up with several faulty CSRs. How to clean them out? Google search brought me some powershell scripts. Looked a bit too complex. Finally I found an answer on ExpertExchange.

You can basically use certificates MMC (local machine store) and delete unwaneted CSRs there. After that remove CSR files from location where you saved them.


PKI: Private Key Export failed during CA migration

I am currently lead a project for PKI migration from 2003 Servers to 2012 R2.

ISSUE: During migration one of CAs I observed an error when I tried to restore a Private Key saved on an old CA to the new CA.


The error said: Import private key: Active directory certificate services setup failed with the following error: Cannot find object or property. 0x80092004 (-2146885628 crypt_e_not_found)

RESOLUTION: I checked the machine local storage and found the old CA certificate there (without Private Key). The certificate was installed by GPO.  I deleted the certificate and retry Private Key import from CA installation wizard (where it failed). This time the cert was imported successfully.

SCCM 2012: Certificate requirements

PKI: Enable SAN support on Microsoft CA after server migration.


I migrated my Lab Enterprise CA from Windows Server 2008 R2 to Windows Server 2012 R2. I tried in-place upgrade. Everything seemed to be fine until I tried to request a SAN certificate from it.

It looks like this feature was lost in migration and I needed to re-enable it using

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

command (one line).


Do NOT forget to restart the CA service – the commend makes changes in registry.

More information about SANs and why you may decide to not enable them in this Technet Article

Certificate WEB request failed with: This Web browser does not support the generation of certificate requests.

Issue: I am trying to send a certificate request from my Windows 2012 Server running IE 10 (default).

The request fails with the error: “This Web browser does not support the generation of certificate requests.”


Resolution: Press F12 and select IE 10 Compatibility View. After that CertSrv page should be displayed properly: