Introduction of AD CS Certificate Transparency

Certificate Transparency (CT) is a new Internet standard that addresses the concern about mis-issued certificates and certificate repudiation by making the Transport Layer Security (TLS) ecosystem publicly auditable. Without CT, there is no way as a domain owner to be aware of certificates that are issued to your domain, unless you yourself requested it. By using CTs, it is easy to audit the quality of the certificates that the certificate authority (CA) issued and determine whether they conform to the standards that are enforced by the CA and Browser Forum (CAB Forum).

CT requires that all TLS certificates that are issued by a public CA are logged to a publicly accessible log server. To make sure that all certificates are logged, web browsers that support CT * will verify that each certificate has a corresponding Signed Certificate Timestamp (SCT) that is associated with it. These SCTs are used as proof that a certificate is contained within a log. Failure to present the SCT during the TLS handshake returns a warning to the user.

* Google announced on February 6, 2018, that Certificate Transparency will be enforced by its Chrome browser beginning on April 30, 2018.

The process for creating and validating certificates is updated as follows. 

1. The server operator purchases a certificate from the CA.
2. The CA validates the server operator by using Domain Validation (DV), Organizational Validation (OV), or Extended Validation (EV).
3. The CA creates a precertificate. [New]
4. The CA (or Client) logs the precertificate to a CT log server. The log server returns a signed certificate timestamp (SCT). [New]
5. The CA issues a Secure Sockets Layer (SSL) certificate.

An SSL certificate usually includes SCT. However, the certificate is not required to include SCT. When you use a browser to visit a server through a TLS connection, the following occurs:

1. The browser validates the SSL certificate during the TLS handshake.
2. The browser validates the SCT that is provided during the TLS handshake, either through OCSP stapling (currently only supported by IIS), through a TLS extension, or (most likely) from information that is embedded in the certificate.
3. The browser validates the SCT that was issued by a log server that's listed in its in-memory Trusted Log Server list. [New]
4. The browser makes a connection to the server.
5. The SSL certificate encrypts all data between the browser and server.
   
   

To enable Certificate Transparency on a CA in Active Directory Certificate Services (AD CS), turn it on by using the following registry keys:

1. Create a registry value that is named CertificateTransparencyFlags, and then type REG_DWORD under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>.
2. Enable the 0x1 bit on the CertificateTransparencyFlags (value 0x1). By default, this feature is disabled.

Clearing out the 0x1 bit on the CertificateTransparencyFlags (value 0x0) disables the feature. The new CT requests will be rejected, and mid-hop requests will not be issued. 

Applications that call AD CS to create certificates must be changed to support the following to "Precertificate" call updates:

1. To opt-in for certificate transparency per request, call ICertRequest::Submit and set the CR_IN_CERTIFICATETRANSPARENCY flag. 

   Note

   The Response will contain the precertificate. There will be no attributes that identify the precertificate in the full response because it is already returned separately in the same call.

2. After the precertificate is received, the calling service should add the returned precertificate to a public CT Log Repository.
3. When a precertificate is added to a CT log, an SCTList is returned.
4. To complete the request and issue the certificate, call ICertRequest::Submit and set the CR_IN_SIGNEDCERTIFICATETIMESTAMPLIST flag.
   
   Follow these guidelines:
    
   • SCTs from previous calls should be combined into an aggregated list (according to the RFC).
   • By default, a CA enforces an SCTList max size of 1 K. A standard SCTList should be about 100 bytes. Set the registry MaxSCTListSize REG_DWORD to customize.
   • SCTList will be validated for syntax and basic semantics (expected values are set).
   • Before it is issued, the X.509 certificate will again be compared to the original precertificate (in the RawPrecertificate column) to prevent it from becoming invalidated. For more information, see RFC 6962 Section 3.2.
   

The following customizations are supported by the AD CS implementation of Certificate Transparency under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>.

1. Set the MaxSCTListSize (REG_DWORD) to customize the max SCTList accepted, in bytes. The default is 1024 bytes.
2. Set the CTInformationExtensionOid (REG_SZ) to customize the OID in the issued certificate that contains the binary data that's returned to the CA in the second hop. (This could be the SCTList if CT v1, or the TransItemList if CT v2, or anything else.)
3. Set the 0x2 bit on the CertificateTransparencyFlags REG_DWORD to disable validation of the binary data that's returned to the CA in the second hop. (Use this if you want to use a TransItemList or other custom binary data.) Otherwise, the CA performs basic CT v1 SCTList syntax validation.