1357067 - Camerfirma: certs with duplicate SANs and without localityName or stateOrProvinceName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Gervase Markham [:gerv]]

It seems that some Camerfirma certs are being issued with duplicate SANs, and without either a localityName or stateOrProvinceName.

https://crt.sh/?caid=1778&opt=cablint is the intermediate in question; see the cablint section for links to lists of affected certificates. https://crt.sh/?id=119105525&opt=cablint is an example . It seems like the CN may be being added to the list of SANs twice - once at the start and once at the end - and the system is not detecting this duplication.

CCing Inigo because although these certs are being issued under a Camerfirma root, I believe they may be being issued to StartCom customers. https://crt.sh/?id=115366302&opt=cablint is another example, and is a site which used to be served by StartCom: https://crt.sh/?q=asphostpage.net .

Gerv

Comment 1

[Iñigo]

Yes, sorry, this is a bug we had already found and knew and asked Camerfirma to fix it, which is happening this week. It affects only StartCom customers. We´re notifying all our affected customers, will revoke those wrongly issued certificates and issue them again including the locality name in the cert and without duplicate domains. It´s been a problem with the cert profile. Evertyhing will be fixed by the end of the week.

Iñigo

Comment 2

[Iñigo]

Hi,

I´ve responded in the other bug open but I can also clarify it here making a summary.

This is what happened

- we discovered the issue of not including the locality name in the OV cert and also the duplicate domain in the SANs and communicated to Camerfirma to fix the bug.
- Later you were notified
- regarding the locality name apparently everyting was correct, because in the form, when filling the data, in the RA application, etc. was "there" but then, it wasn´t included in the certificate´s subject at the issuance
- regarding the duplication on the SAN, it copied the CN of the subject twice in the SAN.
- Both issues have been fixed yesterday
- Once discovered no cert has been issued until being fixed.

Actions to take

- Re-issue all the OV certs affected with the locality name included and no duplicate SANs
- Inform the subscribers of the issue and ask them to replace the wrong ones with the new ones
- Once replace, revoke the wrong ones.

Timing

- we expect to finish this week reissuing all the certs but due to the delay on fixing the bug it can take a little bit more but hopefully not.
- revoke all the wrong certs next week.

I´ll keep you informed of the outcome

Regards

Comment 3

[Iñigo]

Hi,

all wrongly issued certificates have been re-issued and provided to the customers for replacement. Our goal is to revoke them all this week but have received feedback from some customers asking some more time because they have lots of servers where to make the replacement (one customer told us that they have to do it in more than 500 servers and will need more time)but hopefully the majority can be revoked.

OTOH, Camerfirma have started today to start with all validation process for OV certs as well.

Regards

Comment 4

[Ryan Sleevi]

Inigo,

Do you believe the process described is compliant with Section 4.9.1.1 of the Baseline Requirements?

"The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: "

9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the
CA’s Certificate Policy or Certification Practice Statement

Comment 5

[Iñigo]

Ryan,

yes, you´re right and we´d have to revoke those certs within 24 hours, but I wanted to give them a few more time taking into account that we already had the information validated and some may have find some issues replacing them.
We´ll start revoking all of them.

Regards

Comment 6

[Ryan Sleevi]

Inigo: I believe we want to close this bug out, but there's not exactly enough information here to determine whether and how this was resolved (that is, most of the discussion indicates pending/planned actions, rather than completed)

Could you please provide a timeline of the incident report and response, and the information discussed in https://wiki.mozilla.org/CA/Responding_To_A_Misissuance ?

My understanding is that we should expect these issues to be resolved, but want to make sure we document how this was resolved.

Comment 7

[Iñigo]

Hi Ryan,

All certs were revoked and replacements re-issued rightly. I will provide the report asap.

Regards

Comment 8

[Iñigo]

Attachment: Incident report

Comment 9

[Iñigo]

Attachment: Certs affected

Comment 10

[Gervase Markham [:gerv]]

Inigo: we would strongly prefer text, like the incident report you attached, to be pasted into the Bugzilla comments rather than attached as a Word document. That makes the conversaion much easier to follow. Could you do that please?

Once that is done, I believe this bug can be closed.

Gerv

Comment 11

[Iñigo]

INCIDENT REPORT

On April 14th, in an internal review discovered some issues with certificates issued under Camerfirma agreement, acting as resellers, which were not BR compliants. Later on, April 17th, Mozilla notified us about those issues and opened a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1357067
Those issues were related to warnings and errors related to duplicate domain names in the Subject Alternative Name and the absence of the locality name or StateorProvince name in SSL certificate types. The latter was catalogued as an error while the first was a warning.
We opened a ticket with Camerfirma that day.

CHECKING
The initial response after checking the current log of the issued certificate was to acknowledge that there was an issue in the RA certificate management profile.
After further investigation, checking some other logs and configuration, discovered that the RA request form was properly configured but the information sent to the certificate issuance process was not collected correctly because of missing fields in the profile configuration and not dealing correctly with the domain names included in both fields of the request form.
It was a problem with the template used in the RA online request form and how the information collected was sent to the issuance process. 

WHAT WENT WRONG
Unfortunately, there were 2 main issues related to this, the locality and the duplicated SAN entries. The first one was that despite the RA request form requested in the template to include the locality name this was not properly managed in the certificate issuance process due to a missing field (i.e. locality) in the certificate profile and not checking that this was a mandatory field and hence refuse the issuance. It didn´t log the response correctly for it, not allowing Camerfirma knowing the issue before.

The second one was also similar, due to the certificate profile from the information collected in the RA request form in which there were 2 fields, one for the CN and one for the SANs which also had to include the one of the CN but when sending to the RA issuance process, copied twice in the SAN. 

ACTION TAKEN TO ADDRESS THE PROBLEM
Firstly, we stopped the issuance that day, 14th, and wait for Camerfirma response about the the bug. Inmediately we started to contact customers to explain what happened and what we were going to do, which was going to replace the wrongly issued certs with new ones corrected and revoke those with problems, but due to easter holidays it was hard to contact the customers or have any response.

On April 20th, Camerfirma informed us that the bug was fixed and then we started to re-issue the certificates again.
On April 21st we started sending the replacement certificates and kept doing so the whole weekend. Most customers received their new certificates on April 24th. The majority of them were revoked on the 24th and 25th, but there were some others that took some more time.

The number of certificates affected that were replaced and revoked was 162.

FOLLOWING UP
Camerfirma explained and provided information to Mozilla about this issue back in May, including the certificates affected.