The purpose of this page is to maintain a list of known Microsoft hotfixes, patches and known issues related to the Active Directory Certificate Services role. The page will be updated as new releases are made by Microsoft as well as when new issues are identified. You can subscribe to the page to receive automated alerts when the content has changed. If you have any feedback or comments, or notice something that is missing, let us know.
Change Log - Last Updated April 3, 2019
April 3, 2019 - Added Certutil bug with custom Issuance/Policies/OIDs in certificate chain during validation.
July 15, 2018 - Added Certificate Transparency Hotfix
- KB 4093260 - Introduction fo AD CS Certificate Transparency. The update is part of the March 2018 Cumulative Update for Windows Server 2016 (KB 4088787) and available for download here: https://www.catalog.update.microsoft.com/Search.aspx?q=KB4088889.
Note: There are currently no known products or implementations known to support this new capability. Once a product is found that supports this new capability, this listing will be updated.
- KB 283789 (MSKB Archive) - The Issuer Statement Specified in the Capolicy.inf File Is Not Included in the Issued Certificate.
Note: Though indicated as Windows Server 2000, this article is applicable to all newer operating systems. The issue is relevant only for End Entity certs using certificate templates where the subject info is built from AD.
- KB 2960124 - The Online Responder service does not return a deterministic GOOD for all certificates not included in the CRL
Fix: The Hotfix 2960124 to update the Microsoft OCSP Responder is included Server 2016. However, the CA database dump script referenced in the KB article is needed (or something similar) on the Issuing CA. Without this dump and subsequent transfer of data to the OCSP Server, Deterministic Results will not be provided.
- Windows Server 2016 fails to validate certificates when custom issuance policies, application policies or OIDs are used in the chain. This affects certutil related commands such as
cerutil -urlfetch -verifyand
certutil -dcinfo. Certificates however are properly validated by the API (CAPI/CAPI2). More details in our blog post here.
- Interactive Services Session 0 Isolation and HSM CSP/KSPBeginning with Windows Server 2012, services running in a separate context than the user logged into the desktop are unable to interact. This is due to the Session 0 isolation built into the Kernel. This will prevent many Hardware Security Module CSP/KSPs from being able to interact with users. This will be prevalent when card sets are required to be used to authenticate prior to accessing CA keys. This is a known issue with the Thales nCipher security world - at least through S/W v 11.70. Thales is aware of the issue and is in the process of working on a fix. More information on Session 0 isolation is Interactive Services article.
Fix: Change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices to value 0 and reboot.
Update: Thales has released Security World version 12.1 which has changed the driver model and is no longer affected by this registry key.
- Windows XP Clients unable to enroll by default with a Windows Server 2016 CA
When a certificate request is received by a certification authority (CA), encryption for the request can be enforced by the CA via the RPC_C_AUTHN_LEVEL_PKT, as described in MSDN article Authentication-Level Constants. On Windows Server 2008 R2 and earlier versions, this setting is not enabled by default on the CA. On a Windows Server 2012 or newer CA, this enhanced security setting is enabled by default. More details available at Increased security enabled by default on the CA role service.
Fix: On the CA, run
certutil -setreg CAInterfaceFlags -IF_ENFORCEENCRYPTICERTREQUESTand restart Certificate Services.
- You cannot enroll in an Online Certificate Status Protocol certificate (CERT_E_INVALID_POLICY)
Windows Server 2008 and newer may be unable to enroll for a OCSP certificate. This is most often caused by a CA in the hierarchy that has specified specific OIDs but does not include the OCSP specific OID in its EKU (184.108.40.206.220.127.116.11.9). Refer to KB 2962991 for more information.
Fix: When specifying specific OIDs for CA EKUs, the OCSP OID must be included (18.104.22.168.22.214.171.124.9). No steps are needed when using the default "All Application Policies" configuration.
- Error when installing Certificate Authority with Powershell on a Computer or VM without a Network Adapter
This issue occurs when installing an offline, standalone Certificate Authority in a VM environment without a network adapter. In this configuration, using the Powershell
Install-ADCSCertificationAuthoritycommand will result in an error. If there is a network adapter present, unplugged or disabled, the error does not occur. The problem can occur in Windows 2008 or newer OS, however there are no native Powershell commands to perform the install prior to Server 2012. Custom scripts or Powershell cmdlets running on these older operating systems could experience the same error.
Fix: There are three options to workaround the error:
- Configure the VM guest with a network adapter that is unconnected, or is disabled. Once the installation is completed, you can remove the network adapter from the VM guest.
- You can also specify the location for the CA database, even if it is a the default location by appending the argument
–DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")to the Powershell command
- Use the Server Manager GUI to perform the installation.
- Error when installing ADCS on computers with host names longer than 15 characters in length
An error condition can occur when computer names are 16 or more characters in length and the network adapter is not connected (such as an offline CA). While the OS will indicate that possible Netbios name resolutions can occur, it does not prevent the use of a long name. When installing the ADCS role in Server 2012/R2 the installation will complete successfully, the secondary step to configure the role will result in Server Manager crashing. At this point, ADCS can not be uninstalled and consequently the computer name can not be shortened to 15 or fewer characters.
Fix: The fix to this issue is to either use host names that are 15 or fewer characters. If you have already installed ADCS and have experience this issue, temporarily connect the network adapter to enable ADCS to be uninstalled and then change the computer name.
- Renewing a Root CA certificate and changing the Validity Period with CAPolicy.inf fails
When renewing a Root CA's certificate, the validity period of the new certificate is equivalent to the validity period of the certificate being renewed (since Server 2008). If an alternate validity period is desired, the
RenewalValidityPeriodUnitssettings can be placed in a capolicy.inf to reflect a different value for the new certificate. However, ADCS will only use this value if it is equal to, or longer than the value of the certificate being renewed. You can not configure ADCS to renew a Root CA certificate for a lifetime shorter than the previous certificate.
certutil –signto sign and specify the desired lifetime of the certificate, add the modified cert to the CA's computer personal store and associate it with the private key, modify the CA’s registry (
CACertHash) and restart the CA.
- Network Device Enrollment Service reports "You do not have sufficient permission to enroll with SCEP." even for administrative accounts
If NDES is installed and additional components of IIS are manually selected, such as ASP.Net 4.5 NDES can be installed and configured incorrectly. When accessing the NDES Admin page, you will receive an error that you have insufficient permissions even if you have administrative rights. More details available on the original blog post documenting the error condition.
Fix: Uninstall NDES and all IIS role features, reinstall NDES and only use the default components selected. Alternative fix also available if the uninstall doesn't work.
- Windows Server sConfig Command Line tool allows Domain Membership and Computer Name changes even with an ADCS Certification Authority installed.
When ADCS server roles are installed, controls are placed on the server to prevent domain membership changes and host name changes. To make changes to either of these, ADCS must first be installed. This behavior is experienced when making changes in the Control Panel\System applet. However, when using sConfig (Server Core 2008 R2, or any version of Windows Server 2012+), there are no controls to prevent these changes. Changing the domain membership or computer name can break the functionality of Enterprise CAs and can result in an unsupported configuration.
Fix: Remove ADCS role features prior to using sConfig to make changes to domain membership or computer host name. Alternatively, when using the GUI version of Windows Server, use the Control Panel\System applet.