Closed
Bug 1405815
Opened 8 years ago
Closed 8 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: kathleen.a.wilson, 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•8 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•8 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•8 years ago
|
Assignee: kwilson → ramirom
Flags: needinfo?(kwilson)
Comment 3•8 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•8 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: 8 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Product: NSS → CA Program
Updated•2 years 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
•