Closed Bug 1404403 Opened 7 years ago Closed 7 years ago

SwissSign: Two certs issued with same issuer and serial number

Categories

(CA Program :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gerv, Assigned: cornelia.enke)

References

Details

(Whiteboard: [ca-compliance] [ca-misissuance])

The following serial number belongs to two nearly-identical certs:
https://crt.sh/?serial=49e1336e94e5b6a52da96ed48ae276

The difference between them is:

https://crt.sh/?id=12629343  -> Not After : Nov  1 12:00:00 2019 GMT
vs.
https://crt.sh/?id=198226194 -> Not After : Nov  2 07:03:46 2019 GMT

The version with the Nov 1st notAfter has been around for some time. The version with the Nov 2nd notAfter only appeared in CT in late August, some time _after_ the revocation. It's in the Google and Comodo logs, and of course it's not possible to tell how they got hold of it.

This particular issuer/serial number pair was revoked in July 2017, and came to our attention because SwissSign marked the certificate as revoked in the CCADB and it therefore passed through the pipeline into OneCRL.
https://ccadb.force.com/001o000000xOw2k
or
https://ccadb.my.salesforce.com/001o000000xOw2k

However, it's not totally clear which of the two certs is in the CCADB. Going to the URL above shows that the notAfter date is the November 1st version. However:
https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevoked
gives the notAfter date as November 2nd, and downloading the withPEM CSV version, taking the PEM and running it through OpenSSL shows November 2nd. I think we need to get Poonam to have a look at this.

Regardless, we consider this a misissuance. SwissSign: can you please investigate and tell us how this situation came to be, bearing in mind the advice given at:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance
?

Many thanks,

Gerv
Thanks, 
for the investigation. We detected that the certificates were incorrectly issued in 2009 with a double serial number. The CA software used in recent years had special protection against abusive issuing and revocation of certificates with the same serial number. This led to the situation that the certificate could not yet be officially revoked in our CRL by normal operational procedure. We have already discussed the right options with the operators of the root stores. We will continue to try to circumvent the protection of our CRLs for these certificates and to allow the use of same serial number in our CRL despite different certificates (as an exception).

We will inform in this thread about our next steps.
Please also provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Status: NEW → ASSIGNED
Whiteboard: [ca-compliance]
Of course, we will do that, to do it seriously we need time until Monday 9. Oct 2017
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the time and date. 

Nov. 10th 2016: This issue was detected during the setup and filling in of the CCADB and since then we have been in discussion with Mozilla and Trend Micro / Affirm Trust regarding this issue. 

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 

2.a) We have checked that all required documentation about this certificate is available. 
Result: all required documentation is available
2.b) Analyses have been performed to determine how this issue could occur
Result: see 6 
2.c) We have communicated extensively with Trend Micro / Affirm Trust to determine if and when we could revoke the affected certificates. Concerning the revocation see below.
2.d) In addition we have stopped accepting projects with any cross-signing where the CA is not under our physical and technical control.
2.e) At the time of the cross-signing external certificates were not yet handled and managed in our CA database. Thus a special method had to be developed to to handle the revocation of cross signed certificates. 
2.f) On June 27th, 2017 we revoked the certificate with S/N: 49:E1:33:6E:94:E5:B6:A5:2D:A9:6E:D4:8A:E2:76 see http://crl.swisssign.net/5B257B96A465517EB839F3C078665EE83AE7F0EE)

2.g) The last remaining certificate (S/N: CA: 00:84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9) will be revoked on Nov. 11th, 2017. 
2.h) In addition, we have checked our certificate database, to determine whether any other certificates with identical serial numbers are stored
Result: we couldn’t find any

3. Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. 

After an extensive review with TrendMicro (former Affirmtrust) they communicated to us the following two facts:
-  Neither the CA “/CN=Trend Micro Silver CA /O=Trend Micro Inc/C=US” nor the CA “/CN=Trend Micro Gold CA /O=Trend Micro Inc/C=US” has ever issued certificates but TrendMicro has communicated the above mentioned issuing CA certificate to their clients.
- The other issuing CA stopped issuing any certificates in October 2014. Since then the non-cross signed CA “CN=AffirmTrust Commercial, O=AffirmTrust, C=US” has been active.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. 

The following certificate serial numbers are affected with this issue:
•	S/N: 49:E1:33:6E:94:E5:B6:A5:2D:A9:6E:D4:8A:E2:76
•	S/N: 00:84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. 

The affected certificates are listed in the CCADB and are also in the CT-Logs.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. 

This issue was introduced at a time when SwissSign offered CrossSigning of issuing CAs without management of these CA certificates in our own database and software. In other words, we had to manually create a certificate template to achieve the goal that this CA was trusted by two roots. This procedure had to be performed outside of our standard technical process, which would have avoided such a situation. During this manual action the error was introduced. 

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
7.a) The offering of such a cross-signing solution has been stopped 
7.b) Technical constraints to avoid such issues in our CA-DB have been implemented and checked. We have introduced an additional software extension to enter all cross-signed certificates into our standard software and database. This means that immediate revocation of such certificates will be possible.
(In reply to Reinhard Dietrich from comment #4)
> 2.g) The last remaining certificate (S/N: CA:
> 00:84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9) will be revoked on Nov.
> 11th, 2017. 


Meaning that the last of the Trend Micro / Affirm Trust cross-signed certs will be revoked?

If yes, I've also been confused about the status of the following cert that Conny said was revoked on August 8, but the revocation is not reflected in the CRL:
Subject Common Name: Trend Micro Silver CA
Serial Number: 009f3484a1e39c4c77317a09fad54949
SHA-256 Fingerprint: 2C:2B:EC:F0:13:B5:EE:90:50:94:C1:D6:3C:65:2C:0B:F3:CC:E1:1D:CF:69:8F:91:AF:76:A8:39:49:9A:F6:01

Also, when you revoke the 00:84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9 certs on November 11, please check the CRL to ensure that it is indeed updated and the correct serial number added to it, and then update the 'Revocation Status' for both of the corresponding records in the CCADB.
(In reply to Kathleen Wilson from comment #5)
> If yes, I've also been confused about the status of the following cert that
> Conny said was revoked on August 8, but the revocation is not reflected in
> the CRL:
> Subject Common Name: Trend Micro Silver CA
> Serial Number: 009f3484a1e39c4c77317a09fad54949
> SHA-256 Fingerprint:
> 2C:2B:EC:F0:13:B5:EE:90:50:94:C1:D6:3C:65:2C:0B:F3:CC:E1:1D:CF:69:8F:91:AF:
> 76:A8:39:49:9A:F6:01

Fixing my sentence...
Conny reported on August 9 in the CCADB that the cert had been revoked on 6/27/2017.
But the cert has not shown up in the CRL.
@Kathleen Thanks for your remarks.

As described in the error report there had been some non-standard SwissSign processes in place previously. At the time (2011) Conny did not work for SwissSign and she did not subsequently receive all the correct information to fill in the CCADB properly.

SwissSign apologises for the inconvenience that caused.

This also meant that Conny marked the wrong certificate as revoked, which is obviously an error.

Therefore we are entering the missing certificate into the CCADB and setting the revocation status of all the certificates correctly.

In addition we have today revoked the certificate (S/N: 00:84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9) and published the CRL (http://crl.swisssign.net/5B257B96A465517EB839F3C078665EE83AE7F0EE)

We are sure that with the steps mentioned in section 7 of the error report we can avoid such problems in future.

Reinhard
I have verified that the CRL indicates this revocation, and have updated the corresponding records in the CCADB to indicate that the cert is revoked and ready to add to OneCRL.
@Kathleen thanks for verifying it.
I believe this bug can be closed as resolved. Gerv, do you agree?
Given that the issuance was in 2009 and the serial number is now revoked, yes, we can resolve this.

Gerv
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ca-misissuance]
You need to log in before you can comment on or make changes to this bug.