[cabfpub] A few technical details about the case by TURKTRUST

[mert.ozarar]

Dear All,  

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 [1]) 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 [2]). 
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 [3]) 
6) The second certificate
was immediately revoked as soon as it was brought to TURKTRUST's
attention by Google on December 26, 2012. 
7) The available data
strongly suggests that the *.google.com [4] 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. 

Best Regards, 

TURKTRUST Inc. 

 


Links:
------
[1] http://google.com
[2] http://google.com
[3]
http://www.gilgil.net/communities/19714
[4] http://google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130104/c9042449/attachment-0003.html>