Closed Bug 1557085 Opened 2 years ago Closed 1 year ago

Camerfirma: Intesa Sanpaolo misissued certificates

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eusebio.herrera, Assigned: eusebio.herrera)

Details

(Whiteboard: [ca-compliance])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Camerfirma's Quality Control Team found these errors after checking the certificates issued by ‘Intesa Sanpaolo Organization Validation CA’ into crt.sh

a) L appears to only include metadata

b) Serial numbers must be 20 octets or less

c) BR certificates must not contain rfc822Name type alternative name

Since August 2017 Camerfirma’s Quality Control checks the certificates issued by Camerfirma and any of its subCAs.

  1. 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.

a) L appears to only include metadata

2018-02-27 17:17 UTC: The certificate was detected by CAMERFIRMA

2018-02-27 17:34 UTC: CAMERFIRMA communicated INTESA SANPAOLO’S POC the mississued certificate.

2018-04-03 07:38:17 UTC: INTESA SANPAOLO revoked the certificate. The delay in revoking the certificate is caused by Intesa Sanpaolo troubles to replace the certificate.

b) Serial numbers must be 20 octets or less

2017-10-18 12:21 UTC: The certificates were detected by CAMERFIRMA

2017-10-18 12:57 UTC: CAMERFIRMA communicated INTESA SANPAOLO’S POC the mississued certificates.

2017-10-19 08:46:30 UTC: INTESA SANPAOLO stopped issuing certificates at 08:46:30 UTC

2017-10-23: INTESA SANPAOLO installed the patch for CA's software to avoid this wrong serial numbers.

2017-12-22: INTESA SANPAOLO ends revocation of all mississued certificates. The delay in revoking the certificates is caused by Intesa Sanpaolo troubles to replace the certificates and by the number of involved certificates.

c) BR certificates must not contain rfc822Name type alternative name

2017-10-20 07:14 UTC: The certificates were detected by CAMERFIRMA

2017-10-20 07:39 UTC: CAMERFIRMA communicated INTESA SANPAOLO’S POC the misissued certificates.

2017-10-20: INTESA SANPAOLO stopped certificates issuance.

2017-10-23: INTESA SANPAOLO changed the software by which the CSRs were generated avoiding the inclusion of email address in the SubjectAlternativeName extension.

2017-12-13: INTESA SANPAOLO ends the revocation of all the misissued certificates. The delay in revoking the certificates is caused by the Intesa Sanpaolo troubles to replace the certificates.

  1. Whether your CA has stopped, or has not yet stopped, issuing 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.

2019-04-08 a new enrolment procedure has been installed in production environment. A pre-issuance lint check is done before sending the pre certificate to CT logs.

L appears to only include metadata 

2018-04-10 The CA software was modified in order to check not only that one of the two fields locality and the stateOrProvinceName is included in the SubjectDN but also that if any of them is present there shall be also a value

Serial numbers must be 20 octets or less 

The last certificate with these wrong serial numbers was issued on Oct 19 08:46:30 2017 GMT.

2017-10-23 The CA software was modified in order to generate 20 octets serial numbers with first bit set to 0.

BR certificates must not contain rfc822Name type alternative name 

Intesa stopped issuing certificates with this issue on 2017-10-20.

The CSR creation software was modified in order to avoid the inclusion of email address in the SubjectAlternativeName extension.

2017-11-28 The CA software was modified for avoiding issuing any other similar certificate

  1. 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.

    L appears to only include metadata

One certificate mississued

https://crt.sh/?id=326810668&opt=cablint

Serial numbers must be 20 octets or less 

There was mississued 62 certificates with this issue. (See attached file)

First certificate mississued https://crt.sh/?id=214233658&opt=cablint (2017/09/15 14:40:23 GMT)

Last certificate mississued: https://crt.sh/?id=287278706&opt=cablint (2017/10/19 08:46:30 GMT)

BR certificates must not contain rfc822Name type alternative name 

Seven certificates mississued.

https://crt.sh/?id=242854548&opt=cablint

https://crt.sh/?id=243455324&opt=cablint

https://crt.sh/?id=247499273&opt=cablint

https://crt.sh/?id=287278706&opt=cablint

https://crt.sh/?id=236180418&opt=cablint

https://crt.sh/?id=235450106&opt=cablint

https://crt.sh/?id=214233658&opt=cablint

  1. 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.

a) See item 4

b) (See attached file)

c) See item 4

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

a) L appears to only include metadata

When the certificate was generated, the CA software did not yet check that any locality and stateorprovince fields included in the SubjectDN contained a correct value.

b) Serial numbers must be 20 octets or less

InfoCert discovered the bug in the CA software. The software issued certificates with a serial number having 20 octets without checking that the first bit was set to 0 (therefore a few wrong serial numbers having 20 octets with the first bit set to 1 were generated).

c) BR certificates must not contain rfc822Name type alternative name

InfoCert discovered the bug in the CA software. The software issued certificates with a rfc822Name type in ‘X509v3 Subject Alternative Name’ field.

  1. 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.

In addition to the steps in item 3 , a pre-issuance lint check is done before sending the pre certificate to CT logs.

In the same way than in https://bugzilla.mozilla.org/show_bug.cgi?id=1556806,

At the time these incidents occurred, we were not fully aware of the need to register bugs immediately.
At that time we were acting by asking for incident reports to our subCAs and ordering for revoking these certificates.
This incidents are included in subCA Infocert audits.
Now we know this was our fail and we should have disclosed this incident report inmediatly.
In order to avoid these cases, we previously added additional staff to the team responsible for detecting, resolving and reporting incidents of this type.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Thanks for making sure to file these.

Had these been filed contemporaneously with the issue, a significant question would have been raised about this statement:

INTESA SANPAOLO ends the revocation of all the misissued certificates. The delay in revoking the certificates is caused by the Intesa Sanpaolo troubles to replace the certificates.

Your answers to Question 7 seem to address the role of supervision of sub-CAs, but I'm particularly concerned about the steps both Camerfirma and INTESA SANPAOLO are taking to ensure that the BR revocation timelines are being honored.

As discussed repeatedly in m.d.s.p., "troubles to replace the certificates" is not a valid answer, and any failures to revoke require systemic changes to ensure there will not be future failures. Reviewing the incident reports from December 2018 to present (for all CAs) show this to be a common area of concern being raised.

I encourage review of all of both the closed and open incident reports, and a response back as to what steps are being taken to ensure timely revocation of problematic certificates going forward.

Assignee: wthayer → eusebio.herrera
Type: defect → task
Flags: needinfo?(eusebio.herrera)
Whiteboard: [ca-compliance]

Do you have an update?

Emailed POCs on 2019-07-04 regarding this issue, highlighting https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed

We are working to definitively secure with Intesa Sanpaolo the procedure to ensure that the BR revocation timelines are being honored.

Therefore CAMERFIRMA will apply this policy in any eventual new case of certificates misissuance.

Camerfirma confirms that Intesa Sanpaolo has an active new policy in order to ensure that the BR revocation timelines are being honored and that it will be applied in any eventual new case of certificates misissuance.

Flags: needinfo?(eusebio.herrera) → needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.