Closed
Bug 1405815
Opened 7 years ago
Closed 7 years ago
Camerfirma: Certs issued with same issuer and serial number
Categories
(CA Program :: CA Certificate Compliance, task)
CA Program
CA Certificate Compliance
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kwilson, Assigned: ramirom)
References
Details
(Whiteboard: [ca-compliance] [ca-misissuance])
As reported here: https://groups.google.com/d/msg/mozilla.dev.security.policy/SM3cUnENmUw/ZeNCpR2eBgAJ This CA has issued intermediate certificates with the same issuer and serial number. This is a clear violation of the serial number uniqueness requirement of the BRs and RFC5280 4.1.2.2. Issuer: https://crt.sh/?caid=140 Issuer O: AC Camerfirma SA CIF A82743287 Issuer CN: Chambers of Commerce Root Subject CN: (id=1252) AC CAMERFIRMA AAPP (id=12625404) AC Camerfirma Express Corporate Server Serial #: 0d Certs: https://crt.sh/?id=1252 https://crt.sh/?id=12625404 Revoked?: No Please provide an incident report in this bug, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Reporter | ||
Comment 1•7 years ago
|
||
Incident report was provided in m.d.s.policy: https://groups.google.com/d/msg/mozilla.dev.security.policy/SM3cUnENmUw/OcgzjWCcAAAJ Copy-pasted here: 1) How your CA first became aware of the problem Affected certificates Serial number:0d dates:15 Nov-2007 to 8-Nov-2032 Name:AC Camerfirma Express corporate Server(1) Serial number:0d dates:23 Feb-2010 to 20-Feb-2022 Name:AC Camerfirma AAPP(2). We were aware some time later of Febr 2010 after issuing the (2) SubCA when we already had issued valid certificates. 2) A timeline of the actions your CA took in response. The SubCA (1) was an internal CA to issue only 6 test certificates. This SubCA is not used anymore since 08-11-2014. Certificates issued by SubCA (1) /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=127.0.0.1/emailAddress=info@camerfirma.com/serialNumber=A99999999 /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-sistemas@camerfirma.com/serialNumber=A82743287 /C=ES/ST=Avila/L=Avila/O=AC Camerfirma SA/OU=Sistemas/CN=*.camerfirma.com/emailAddress=admin-sistemas@camerfirma.com/serialNumber=A82743287 /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_valido/emailAddress=info@camerfirma.com/serialNumber=A99999999 /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_revocado/emailAddress=info@camerfirma.com/serialNumber=A99999999 /C=ES/ST=Madrid/L=Madrid/O=AC Camerfirma/OU=Tecnico/CN=test_caducado/emailAddress=info@camerfirma.com/serialNumber=A99999999 3) Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL The SubCA (1) issue no certificates since since 08-11-2014. 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. See answer 1. 5) The complete certificate data for the problematic certificates. See answer 1. 6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The generation of SubCA certificates is done manually, in the protected physical environment of our Root CA off-line, with the prior authorization of our management and in the presence of our internal auditor. We used a wrong template in the creation SubCA process. We reviewed the templates and classified them to avoid new problems. This control has been effective since no other similar problem has arisen so far. 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. Templates are now approved by the tech management and review by our internal auditor before going into production. ~~
Comment 2•7 years ago
|
||
Kathleen: is Inigo at StartCom the right assignee for this bug? The incident report came from ramirommunoz@gmail.com, although he doesn't have a Bugzilla account as far as I can see. To the Camerfirma representative: the incident report does not yet have sufficient detail. Why did you have _any_ templates with hard-coded serial numbers? Why did that serial number not meet the BR requirement to have 64 bits of entropy? Also, it seems like some of the certificates you issued with this "test CA" are non-compliant with the current BRs; one contains an internal IP address, and 3 contain internal server names. Can you confirm that these were issued before these practices were forbidden? Thanks, Gerv
Assignee: inigo → kwilson
Flags: needinfo?(kwilson)
Reporter | ||
Updated•7 years ago
|
Assignee: kwilson → ramirom
Flags: needinfo?(kwilson)
Comment 3•7 years ago
|
||
--> Why did you have _any_ templates with hard-coded serial numbers? Cause the CA certificates were made in proceeded ceremonies. End entity certificates are not issued using the same mechanism. --> Why did that serial number not meet the BR requirement to have 64 bits of entropy? Cause when those certificates were issued there were no such requirements (V1 adopted on 22 Nov. 2011 with an Effective Date of 1 July 2012) --> Can you confirm that these were issued before these practices were forbidden? Yes, they were issued before (2007-2008) the existence of BR Kind Regards Juan Angel
Comment 4•7 years ago
|
||
Given the age of this problem, the obsolence of the CA and the steps taken to improve processes, I think we can close this. Gerv
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•1 year ago
|
Product: NSS → CA Program
Updated•1 year ago
|
Whiteboard: [ca-compliance] → [ca-compliance] [ca-misissuance]
You need to log in
before you can comment on or make changes to this bug.
Description
•