Certificate Transparency – The quick detection of fraudulent digital certificates

Posted by Liaquat Khan on Oct 4, 2017 2:25:45 PM

SSL Trust Issues

India's National Informatics Centre (NIC) has now joined the infamous Dutch CA DigiNotar in issuing fake and unauthorized digital certificates, yet again damaging the faith we place in Certification Authorities to provide high trust identity assurance. The NIC CA is chained to India’s Controller of Certifying Authorities (CCA) Root CA which is included in all copies of Microsoft’s Trusted Root Certification Authority Store. Thus any SSL certificate issued (i.e. signed) by NIC are automatically trusted by Windows systems and of course Internet Explorer and also by Google Chrome and other browsers that use Windows trusted certificate stores.

In July 2014, Google identified that the NIC CA had issued fake Google certificates and immediately informed CCA who revoked NIC issued certificates. Google also blocked all the fraudulent issued certificates to stop any further damage. Such events occur because of poor policy and procedures and poor IT physical and logical security. To prevent such breaches occurring again, stronger trust is needed that features a fast and open detection mechanism.

A Solution for Enhanced Trust

Google’s answer to these issues has been Certificate Transparency. This approach requires CAs to publicly publish information about their issued certificates so that anyone can check whether a certificate has been properly issued. Certificate Transparency (CT) does not stop fraudulent certificates being created, but it enables them to be quickly and easily detected. The CT solution uses three new entities: Log Servers, Auditors and Monitors:

    1. Log Servers These accept a yet to be issued certificate from a CA and return an SCT (Signed Certificate Time Stamp); a proof that the certificate has been received by the Log Server. The CA then embeds the SCT inside the issued certificate. Alternatively a CA’s OCSP Server can acquire SCTs for its certificate and place these inside OCSP responses. In either case the SCT data is processed by the end entity software, such as a browser.
    2. Auditor This is a lightweight software component used to check that a certificate does appear within a log, they also verify that the log server is behaving correctly and that they are cryptographically consistent.
    3. Monitors These are servers that constantly review log servers and watch for suspicious certificates, they may be run by large organisations to ensure that fraudulent certificates have not been issued or watch for certificates that have unusual certificate extensions.

Why Certificate Transparency

Certificate Transparency is an open framework that can quickly detect digital certificate trust threats and brings automatic checks and openness to the SSL certificate system.

    1. Early detection of fraudulent certificates and CAs CT provides much faster detection of fraudulent certificates in hours rather than days.
    2. Faster resolution CT enables quicker detection and thus enables faster problem resolution, by using standard procedures like revoking the fraudulent digital certificates.
    3. Better oversight of the TLS/SSL system CT is an open framework that allows any third party to observe and verify the integrity of Server SSL certificates, e.g. domain owners, the CAs.

How is SCT data used by end systems?

    1. Trusted CAs put the SCT data within SSL Server Certificates as an X.509 extension so that any software (such as a browser) can see and verify the SCT data. From February 2015 Google’s Chrome browser will no longer show the green Enhanced Validation (EV) indicator for certificates that do not have embedded SCT data. More details are provided within the EV CT Plan.
    2. For those CAs that cannot make this change in time, the alternative is to use OCSP Stapling. There are two methods: (a) The web server communicates with the CA’s OCSP responder, gets an OCSP with SCT embedded as an extension. The webserver then extracts the SCT to use it within the TLS/SSL handshake; or (b) The webserver communicates with the Log Server to get an SCT, which is later sent by using TLS hand shake.

ADSS Server and Certificate Transparency

The ADSS Server Q4 2014 release will support certificate transparency and have these features:

    1. ADSS CA Server will have an option in the SSL Certificate Template to include SCT data.
    2. ADSS Server Certification Service will request an SCT for an SSL Server Certificate as it is being created and embed this as a certificate extension as described above.
    3. Log Server URL(s) will be configurable for each CA.
    4. Following RFC 6962, ADSS Server will be able to embed more than one SCT. The recommendation is to use SCTs from 3 different Log Servers so that SSL clients can select any of the SCTs. Each CA will have a policy setting that defines the number of SCTs to be retrieved. If ADSS CA Server fails to get this number of SCTs then the certificate will not be issued. 
    5. SCTs are trust checked before being embedded within certificates and then they are stored in the database for future quick access.
    6. The ADSS Server transaction logs viewer will allow a certificate’s SCT data to be viewed.

Ascertia strongly supports high trust initiatives which make the internet a safer place for governments, business and consumers. Certificate Transparency is a good open approach to strengthen the way in which Server SSL certificates can be trust checked and make it easier to detect fraud.

Ascertia – delivering trust to e-business systems, documents and workflows

Topics: Certificate Transparency