Closed Bug 1598277 Opened 2 years ago Closed 1 year ago

Asseco DS / Certum: CA certificates not listed in audit report

Categories

(NSS :: CA Certificate Compliance, task)

3.45
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtrapczynski, Assigned: wtrapczynski)

Details

(Whiteboard: [ca-compliance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

Based on this https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI m.d.s.p forum post regarding audit details for CA certificates we found 18 CA certificates with failed ALV results. As requested, we will provide an incident report no later than November 29, 2019.

Assignee: wthayer → wtrapczynski
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]
  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.

We became fully aware of this problem from a discussion on m.d.s.p. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI on November 21th, 2019.

  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.

08.10.2019 20:50 UTC – Mozilla informed on m.d.s.p. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI that there is now an "Audit Letter Validation (ALV)" button on intermediate certificate records in the CCADB. We saw this information but we mistakenly assumed that ALV test for our certificates has failed because of invalid format (spaces and lowercase letters) of SHA-256 Fingerprints we have in current audits statements. Then, we did not perform an insightful verification.
21.11.2019 15:51 UTC – As the discussion on m.d.s.p. was continuing we decided to perform a detailed inspection.
22.11.2019 13:00 UTC – We finished a review of all the affected certificates. We identified and prepared a description of all of these certificates (see point 4 this Incident Report).
26.11.2019 17:00 UTC – We finished an analysis of the impact of revocation of these certificates. We decided to revoke 15 certificates.
27.11.2019 12:00 UTC – We revoked 15 certificates.
27.11.2019 18:00 UTC – We added an appropriate comment in CCADB for the other 3 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.

This incident concerns certificates that were issued between 2008 and 2014. All our active certificates are included in our current audit reports.

  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.

We have 18 certificates with ALV test failed but we believe that 15 certificates should be considered as non-compliance.

The details explanation of each certificate (Common Name and SHA256 Fingerprints). We may divide them into several groups:

(1) Cross certificates with different Audit Information than all Certum’s CA certificates. SHA256 Fingerprints of these certificates are included in Certum’s audit statements but according to this Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1567062 we have changed the Audit Information section in CCADB and we have pointed out subject audit statements (SSL.com). I have added an appropriate comment in CCADB. In total, 2 certificates.

SSL.com Root Certification Authority RSA
ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B

SSL.com EV Root Certification Authority RSA R2
B97176F21B6ED64609267B2D1A2A9FAF0C4DEBD44644DC85EB6AE986FC867D5

(2) Invalid Self-signed root. Note from CCADB for this certificate: “This is the first version of the certificate which had been submitted to Mozilla but the submission was rejected because this root certificate has a 21-byte serial number - not compliance with RFC 5280. See https://bugzilla.mozilla.org/show_bug.cgi?id=99937. Since different versions of the same root cert have the same Issuer Name and are both signed by the same key, they both chain to each other. Therefore, the not-included self-signed root must also be disclosed to Salesforce as an intermediate cert.” I have added an appropriate comment in CCADB. In total, 1 certificate.

Certum Trusted Network CA 2
9F8B05137F20ACDE9B996410F4D0BF7971A1006DC99E094C346D279B93CFF7AE

(3) Old Certum CA certificates that we do not use anymore. All of these certificates were used for issuing SHA1 SSL, S/MIME, and Code Signing. There are no valid end entity certs issued by these certificates. We have revoked them all. In total, 15 certificates.

Certum Partners CA
A6CA043D5C838DD10E935ACDD1079C9686B6511FAF4C80C4DCFC9C54394DED5E

Shoper® SSL
45E0E9FA188DF98F379480F01B64BAC62CFE0975E6BB21C7D26DD8A8A161978B

Certum Class I CA
9D2B4698D46AB43733A561019B5F8EE8EDA6FF57E8204BC9551B52AAACD70FFB

nazwaSSL
363CDDBDE8BFE2E8D3DE0E32F8578A1FB676CBB76538A03FDE4DE3BD5BEB0497

Certum Global Services CA
E71DB3A6FE82C4C8B78A6D6A5BEFDA5279082E2FAC0CC7EE7878C04AC9A59263

Certum Level II CA
4AA4641706D04220B6BB08ADD302094E56BFCACF145D623E3AE8AAE72E0E1DFA

Certum Level I CA
D84C21D568BCADFEF335DC897D9B6F9D8059782F9BA05113CC45923BF9C98969

Certum Level III CA
5735A8D44CF917B4D1475673629C5E094D02C1767C43DCA7991CF1FFAE4E72DA

Certum Level IV CA
4B890BFBBE669090928707351DE6149765AEFC5505B203B305A9E57FE6C089A9

Certum Trusted Network CA
33F959714B8FA7AB272BEA2CA239403A879044D83A8FD008534D7EE65FA0D42B

GIS CA
982F71BA61EFFF00356D2C623701E57482D7DA554919559F2EA2A09AF0C19FD9

GIS CA
9CE3B21A9934F88506430F52C35E3E01FEF32CCEE7847E52783BFCDB42AB7D2F

SpaceSSL CA
619ED5ADE1F1862446D23F792F2CA3D53E6AF107B07A465DF71DC61AEDC42E2B

nazwaSSL
1EA3D5FB380D3C3C9C63BD83446CF43A768FFA26F6399C308F61B055EC484126

Certum Extended Validation CA
73BA7942E5187015176F1DFD358D324D7BAF0F98366442154FE72CCB4A6A3C3F

  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.

https://crt.sh/?id=155177095
https://crt.sh/?id=759010256
https://crt.sh/?id=759010264
https://crt.sh/?id=6419
https://crt.sh/?id=18068150
https://crt.sh/?id=974813
https://crt.sh/?id=6418
https://crt.sh/?id=728
https://crt.sh/?id=857807
https://crt.sh/?id=22280
https://crt.sh/?id=230
https://crt.sh/?id=47108
https://crt.sh/?id=1292311
https://crt.sh/?id=709857
https://crt.sh/?id=3719463
https://crt.sh/?id=164619
https://crt.sh/?id=16859
https://crt.sh/?id=6005922

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

As we no longer use these 15 certificates in production and there are no valid end-entity certificates issued by these certificates we did not include them in audit scope.

  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.

We revoked all 15 certificates not listed in current audit reports.
For all certificates that should be in audit scope, we follow the earlier established procedure to be sure that any certificate will not be omitted in audit statements.
We will create another Bugzilla Bug to explain the lack of timely revocation no later than December 2, 2019.

Wayne: The related issue is Bug 1600158. I'm not fully sure I understand the answer in Comment #1 to Question 7 in terms of future prevention; it sounds like more-recently established procedures already mitigate the risk of a lack of disclosure. Barring further questions/clarifications, I think this can be closed?

Flags: 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.