TURKTRUST CA Problems

Microsoft just publicly announced a release to actively “untrust” three certificates issued by Certificate Authority TURKTRUST and its Intermediate CAs, a subsidiary of the Turkish Armed Forces ELELE Foundation Company. According to Microsoft, the company made a couple major mistakes resulting in fraudulent certificate issuance that could be used to MiTM encrypted communications or spoof gmail and a long list of other google properties. A Chrome installation detected a “an unauthorized digital certificate for the “*.google.com” domain” late the night of Dec. 24th 2012, and the Google security team’s investigation began there.

TURKTRUST’s mistakes included issuing two certificates incorrectly. They created intermediate CA digital certificates for *.EGO.GOV.TR and e-islem.kktcmerkezbankasi.org, when they should have been issued regular SSL certificates. Also, both of these certs lacked CRL or OCSP extensions and were incorrectly issued as end-entity certs. These mistakes enabled the *.EGO.GOV.TR authority to be misused and fraudulently issue a certificate for *.google.com. Microsoft is not only issuing fixes for this CA trust problem, but including known CA fixes in the recent past. This list of Google properties are fixed by the release:

*.google.com

*.android.com

*.appengine.google.com

*.cloud.google.com

*.google-analytics.com

*.google.ca

*.google.cl

*.google.co.in

*.google.co.jp

*.google.co.uk

*.google.com.ar

*.google.com.au

*.google.com.br

*.google.com.co

*.google.com.mx

*.google.com.tr

*.google.com.vn

*.google.de

*.google.es

*.google.fr

*.google.hu

*.google.it

*.google.nl

*.google.pl

*.google.pt

*.googleapis.cn

*.googlecommerce.com

*.gstatic.com

*.urchin.com

*.url.google.com

*.yo

utube-nocookie.com

*.youtube.com

*.ytimg.com

android.com

g.co

goo.gl

google-analytics.com

google.com

googlecommerce.com

urchin.com

youtu.be

youtube.com

 
The release may cause some confusion. The vendors are handling the incident differently – the three certificates that are being “untrusted” by Microsoft do not include the TURKTRUST Trusted Root CA certificate itself. But the certificates for the two intermediate authorities are effected, as is the fraudulent Google property certificate. Also adding to the confusion is the fact that some systems seem to have TURKTRUST certificates included as a Trusted Root Certificate Authority on their Windows system, but others do not. This inclusion has to do with the ways in which Microsoft updates their root certificate stores on newer systems vs. older Windows OS systems. Microsoft provides a knowledge base article that presents all of the gory details on Microsoft Root Certificate updates. Just follow the link and go to the section “How Windows Updates Root Certificates”, where you will find information on both Windows Vista and Windows 7, on Windows XP and its manual update root package, and on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 OS systems. To sum it up, most users that do not visit web sites in the Middle East, especially Turkey and Cyprus, will not have the TURKTRUST Trusted Root CA certificate installed on their system (although Google did not disclose the location of the detected fraudulent certificate). So, for the most part, this release does not directly effect their system. Also, most helpful here is the automatic updater of revoked certificates released by Microsoft back in June, available for Windows Vista Service Pack 2, Windows Server 2008 Service Pack 2, Windows 7, and Windows Server 2008 R2.


Both Mozilla and Google posted information about the problem. Google pushed Chromes certificate revocation metadata on December 24th and 25th to block both of the Intermediate Certificate Authority certificates. An ongoing discussion exists over at the mozilla.dev.security.policy group. It appears that Mozilla is the only vendor of the three to altogether suspend trust in the TURKTRUST root CA cert: “We have also suspended inclusion of the TRKTRUST Bilgi letiim ve Biliim Gvenlii Hizmetleri A.. (c) Aralk 2007 root certificate, pending further review”. Please see the long list of links at the right side of the page for more information from the vendors and posts on past CA issues.

 
UPDATE: TURKTRUST is reaching out on various forums to present their findings on the problem. In the past, they have actively used manufacturer and vendor forums to request inclusion of their certificates in the trusted root authority store of various products. So while this communication may seem somewhat extraordinary, they have been this open in the past. From mozilla.dev.security.policy…

 
“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.

It is assured that, this clearly identifies the root cause that led to the generation of faulty certificates. All related data resides in archives, and the sequence was all traced back to understand what really had happened. The system had been finally updated on October 17, 2011 and went through a successful ETSI TS 102 042 audit by KPMG on November 2011.

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 for the certificates issued; the other is a run time control checking the certificate profile for end users.

Via the post process control, the validity period, basic constraints, CRL distribution point, Authority Info Access (AIA) and the other profile details are checked after certificate generation according to the certificate requirements coming from respective certificate policies before the certificate is delivered to the end customer. The post process control is planned as a separate and independent service from the certificate generation module of the CA software.
Via the run time control, the basic constraints are restricted to the end user certificates.

Both controls have already been implemented.
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) The other certificate was reported to sign a fraudulent certificate (*.google.com) on December 6, 2012.

3) Before the December 6, 2012, the certificate was installed on an IIS as a web mail server.

4) On December 6, 2012, the cert (and the key) was exported to a Checkpoint firewall. It was the same day as the issuance of the fraudulent certificate (*.google.com).

5) The Checkpoint firewall was said to be configured as MITM. It appears that the Checkpoint automatically generates MITM certificates once a CA cert was installed (http://www.gilgil.net/communities/19714)

6) The second certificate was immediately revoked as soon as it was brought to TURKTRUSTs attention by Google on December 26, 2012.

7) The available data strongly suggests that the *.google.com cert was not issued for dishonest purposes or has not been used for such a purpose.

8) There is certainly not a bit of data to show an evidence of a security breach on TURKTRUST systems.”

 
The interpretation of the Checkpoint MiTM usage for sniffing communications with Google properties seems especially interesting. Apparently, someone exported an intermediate CA certificate from a IIS webmail server that was issued in August 2011, created a *.google.com fraudulent certificate, installed the CA cert on a Checkpoint “SSL Inspection” device all in the same day months after the original certificates were mistakenly issued.