Closed Bug 1451953 Opened 2 years ago Closed 11 months ago

TeliaSonera: Intermediate Cert(s) Not Disclosed in CCADB

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: wayne)

Details

(Whiteboard: [ca-compliance] - Next Update - 01-May 2018)

The TeliaSonera CA has one or more intermediate certs that are not disclosed in the Common CA Database (CCADB).

https://crt.sh/mozilla-disclosures#undisclosed

Mozilla's Root Store Policy:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#publicly-disclosed-and-audited
"All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in the CCADB by the CA that has their certificate included in Mozilla’s root program."

How to disclose intermediate certs in the CCADB:
https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data
We updated CCADB now to include our new Sub CA certificates. Those are included in the next audit that has already begun.
They are still showing under "further disclosure required". Looks like you need to fill out the audit & CP/CPS info.
These two sub CA certificates that are still on the  list have been replaced with certificate versions that are technically constrained to get those excluded from disclosure/audit. Does it now solve the issue if we revoke those unused versions on the disclosure list and put them to out Root CRL/OCSP?
(In reply to pekka.lahtiharju from comment #3)
> These two sub CA certificates that are still on the  list have been replaced
> with certificate versions that are technically constrained to get those
> excluded from disclosure/audit. Does it now solve the issue if we revoke
> those unused versions on the disclosure list and put them to out Root
> CRL/OCSP?

Yes, revoking the undisclosed and unconstrained certificates will resolve the problem.
Thanks, we we'll revoke those later in April. We have to carefully plan this because revocation requires root key access, Root CRL/OCSP update and verification that all our clients have been updated to the constrained subCA version.
Please update this bug once the sub CA certificates have been revoked.
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-May 2018
Pekka: when will the two undisclosed, unconstrained intermediates be revoked?
Flags: needinfo?(pekka.lahtiharju)
These are not unconstrained but allow SMIME. They have been revoked several days ago. Plan is now that we'll add them to online CRL and OCSP responses on Monday 28th May (revocation was done in offline system). 

Delay is because we had to recreate the reissued CA certificate because of our utilizing system didn't accept the first replacement CA because at first we also changed the Subject name. Now the new replacement CA is only restricting the SMIME bit that was the cause for the issue when you started to require such CA certificates to be disclosed. The utilizing system is Finnish national Citizen ID and we simply can't put it down because of this.
Flags: needinfo?(pekka.lahtiharju)
New status: We have added these revocations to online CRL data as planned but we encountered a technical problem when updating online OCSP status data with offline revocations. The problem will be fixed on Monday 4th June and then status should be revoked on both (CRL and OCSP).
At last we were able to put revocation data also to OCSP system. We had technical problems and needed help from our OCSP software provider. Now this case should be closed. Can you confirm?
I updated the state of these intermediates to 'revoked' in CCADB and confirmed that they are no longer listed as non-compliant.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Another undisclosed intermediate certificate has been identified:

https://crt.sh/?sha256=5b312b7e11b70d07c14e0ab99f08d00748966098c52aa85a06a0822bbe59a02c&opt=mozilladisclosure

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report Please also post the report to the mozilla.dev.security.policy forum, and please ensure that the report explains how this issue will be prevented from happening again.
Status: RESOLVED → REOPENED
Flags: needinfo?(pekka.lahtiharju)
Resolution: FIXED → ---
The listed certificate was today re-added to CCADB. And Telia verified that we can see it now.

Incident report:
Telia created two new intermediate certificates in 29st Aug 2018. We tried to add both to CCADB soon after that but for some unknown reason one of them was not seen now on our CCADB listings. Internally we kept both as inserted. Error must have been some kind of failure to commit the changes of the second insert. The user interface of CCADB is not a straight forward wizard to prevent this kind of errors. Is there any way to see logs from CCADB to see what has exactly happened on that day?

In the future Telia will try to get another user account to CCADB so that we could use dual person process (creator-verifier) in CCADB updates. Do you know if this is possible? Even if not possible Telia will anyway add a new step to CCADB process to verify that all additions were successfully completed.
Flags: needinfo?(pekka.lahtiharju)
Now this issue is added also to mozilla.dev.security.policy forum as requested: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PZe31LgDFVk
A public report listing all certificates disclosed in CCADB is available: http://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat

I believe you can also request another CCADB login for a second Telia representative by emailing support@ccadb.org
Status: REOPENED → RESOLVED
Closed: Last year11 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.