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)

task
Not set
normal

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
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.
~~
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)
Assignee: kwilson → ramirom
Flags: needinfo?(kwilson)
--> 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
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
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.