Technical Details

(Last Update - 21:50 GMT+2, January 07 2013)

A few technical details about the case by TURKTRUST

Please find some critical points below about the root cause of the instance:

• The case occurred in August 2011 during a software migration operation, before the first successful ETSI TS 102 042 audit which took place in November 2011. The sequence of events that led to the mistaken issuance of two certificates can be best summarized as follows.
• Prior to June 2011, the certificate profiles on the production system were exported to the test system, containing a particular number of certificate profiles.
• For the sake of testing purposes, 2 more profiles were added that contain CA extensions.
• In the meantime, the production system was also updated to meet the need of demand to contain 3 more SSL certificate profiles. Hence the production system and the test system appeared to have different number of profiles by one, and the two sets matched only in the profiles at the date of the first data migration.
• The tests were completed before June 30, 2011. It was the unfortunate event that the production system was patched with the profiles in the test system, which had happened to contain 2 wrong profiles and lacked 3 correct profiles.
• The wrong profiles were only used on August 8, 2011 to issue those two faulty certificates which were certainly not intended to be sub-CA certificates.
• A certificate request on the 10th of August had called the use of one of the missing profiles, which was drawn to attention by a thrown exception. In order to fix this the whole set of certificate profiles was this time replaced to contain all correct profiles. Therefore the problem had been fixed once and for all although the unfortunate event that the certificates were mistakenly issued remained hidden.

Although the system is now immune to any such kind of errors, further preemptive measures are implemented as described below:

One is a post process control and the other is a run time control checking end entity certificates.

Via the post process control, the following controls are implemented for a generated certificate, which is not yet saved to be delivered to the end user: The validity period must be less than or equal to 3 years; basic constraints CA extension must be set to false , the certificate must have AIA and CRL distribution point extensions. KeyUsage extension is also checked against the certificate profile and the appropriateness of an end user cert. The post process control triggers per generation as a separate and independent service from the end user certificate generation module of the CA software. The control can be also configured as a cron to check the certificates in the database.

The run time control, on the other hand, enforces basic constraints CA set to be false and checks if AIA and CRL distribution point extensions are not null. It also checks the validity period is less than or equal to 3 years. The run time control is embedded into the end user certificate generation module.

Both controls are implemented in the production as of January 3, 2013.

All OCSP requests and CRL data have already been analyzed to detect any anomaly during the entire period. The data revealed no anomaly at all.

The following issues are also worth considering at the moment:

1. One of the mistakenly issued certificates has been revoked before putting into use upon the request of the customer.
2. We have verified that EGO started the firewall set-up on the 6th of December. MITM proxy feature service started on the 21st of December. Chrome browsers in the LAN had started to give access errors to Google site on the very same day. This information is based on the declaration of the firewall vendor and EGO. We believe that it is most likely that the faulty certificate was automatically generated by the firewall on the 21st of December (cloning all attribues but few, worth reminding that the faulty certificate differ from the true Google cert only in a few fields). The likelihood of a malicious usage is indeed barely above zero.
3. That certificate was reported to sign a faulty certificate (*.google.com) with the date of issuance December 6, 2012. The curious facts on this issuance are as follows:
1. Google has renewed its certificate from Google Internet Authority on December 6, 2012. The certificate can be checked at the site https://encrypted.google.com.
2. It is too much of a coincidence that the faulty certificate and the true Google certificate match exactly in each and every field except the issuer, serial number, CRLDistributionPoint, SubjectKeyIdentifier, AuthorityKeyIdentifier, and AuthorityInformationAccess. It is a well-known fact that the firewall automatically generates a MITM proxy certificate once a certificate with BasicConstraints CA extension was installed on the firewall (for an explanation how it works visit URL-1 and URL-2 «« Disclaimer »»).
3. This seems to be a very plausible scenario explaining how the faulty certificate was being generated. This and all other available data strongly suggests that *.google.com cert was not issued for dishonest purposes or has not been used for such a purpose.
4. The second certificate was immediately revoked as soon as it was brought to TURKTRUST’s attention by Google on December 26, 2012. It is also very well known that Google has already deployed “public key pinning” for some of its domains (http://ssl.entrust.net/blog/?p=615). This may also be explaining how this faulty MITM proxy certificate was caught by Google.

As of now, it is certain that there is no security breach on TURKTRUST systems. There is also not a bit of evidence that the certificate was used maliciously.

Best Regards,
TURKTRUST Inc.