Closed Bug 1417771 Opened 2 years ago Closed Last year
Cert: Symantec non-constrained/non-disclosed intermediates
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce: This is a difficult issue to file as so much of it is still unknown, but I thought I should file a compliance report early and update as things become more clear. Right now, I think there are 279 non-constrained TLS-capable issuing CAs that are not reported. I believe all of these ICAs hosted within the old Symantec infrastructure and should have been covered by Symantec's previous audit. However, the ICAs are not in CCADB. The ICAs are only permitted to issue client certs, which is why there was confusion originally about whether filing was required. My understanding of the requirement is that all TLS-capable ICAs should have been reported through CCDAB, regardless of whether the CA is actually issuing TLS certs. This is also why they are not included in the audit reports - they aren't actually issuing TLS certs. We'll upload the ICAs to CCDAB as we get the PEM files. I'll also post more info as we figure it out.
Summary: Symantec non-constrained/non-disclosed intermediates → DigiCert: Symantec non-constrained/non-disclosed intermediates
Jeremy: any update here yet? Gerv
Yes! I finally have enough info to share something. The issuing CAs can be split into three camps: 1) Hosted and disclosed to CCADB but not included in the audit 2) On-prem without constraints but chain to a root where TLS is not enabled 3) Hosted but where the third party has RA privileges, but the cert is not permitted (through system constraints) for use in TLS 13 fall under #2. 5 fall under #3. The rest are under #1. #1 seems like a minor issue as they are all disclosed, just not included in the audit reports. The audit report being generated right now will list them. #2 is not too bad as the impact is limited to s/MIME certs. Some of them are not audited and there is a lack of sufficient controls over email validation. We are working with the entities to migrate them to a hosted solution or, at least, get them audited and properly verifying the email addresses. #3 is not too bad either but lacks the same necessary email controls as #2. We are patching those systems (while migrating them) to ensure email verification is required. I'm working on an ETA for this, but I lack sufficient information to know what the update will take or how long. Trying to get that. Jeremy
Hi Jeremy, Seems to me that the #3 certs need adding to OneCRL, our standard practice for legacy intermediates with insufficient technical constraints. Did you disclose the #1 certs in CCADB or did Symantec? Seems like these need adding to OneCRL too? Are there really 279 - 13 - 5 = 261 of them? Gerv
All three are being included in the coming audit report. There's about 1000 issuing CAs listed. As for compliance issues: #1 and #3 are a compliance issue. #1 is disclosed in CCADB. #3 is not. Neither really issue TLS certs (only email certs). They aren't properly technically constrained, but since they are controlled by DigiCert, we know that no TLS certs were issued under them. Once they are included in the audit (which is finished), both issues should be resolved. #2 falls under the new requirement where all CAs must be constrained or audited by Nov or revoked in March. All of these are being included in the current audit or will be revoked in March. The audit report should come out the end of this month I think. I'll post another update right after we see it and compare the listed Sub CAs to what we have on file.
Jeremy: Questions: - Can you confirm that the new audit reports include these intermediates? - For those in group #3, have they been added to OneCRL? - For those in group #2, assuming they chain to a root in the Mozilla program enabled for S/MIME, will they be audited & disclosed in CCADB by April 15? - Can you provide a list of these ICAs?
Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254
QA Contact: gerv → wthayer
Jeremy or Ben: I believe the assertion here is that this issue has been resolved through a combination of CCADB disclosure and audits (or technical constraints per Mozilla policy section 5.3) - is that correct? In my spot checks, not all of these ICAs are [technically constrained or] listed on the new audit report. For example, "Polbank EFG CA" and "ADACOM Qualified Services CA" are not technically constrained and are not listed on the audit report for the "VeriSign Class 2 Public Primary Certification Authority - G3". The ICA these chain to is listed, but I don't believe that is sufficient. If you agree with my analysis, then what is the plan for these non-compliant subordinate CA certificates?
They are all being distrusted in Sept right? I think the plan is to wait until the roots get distrusted. I think Symantec lacked sufficient records on their ICAs for us to ever be sure that they were all disclosed or audited.
(In reply to Jeremy Rowley from comment #9) > They are all being distrusted in Sept right? I think the plan is to wait > until the roots get distrusted. I think Symantec lacked sufficient records > on their ICAs for us to ever be sure that they were all disclosed or audited. No - the Sept distrust only applies to TLS, and the examples I cited are valid for S/MIME.
Hi Wayne - I'm following up on this bug. The ICAs are disclosed and audited as per the last period audit for Symantec (ending Oct 31, 2017). For ICAs used by organizations that you cited as an example "Adacom Qualified Services CA", we rely on their audits to attest to their compliance. These organizations are on different audit cycles from Digicert's. For Adacom, their ETSI audit period is June 2, 2017 to June 2, 2019 and are working on their annual assessment now. We will upload once we get the final report. Let me know if you need more info.
This post is in response to a "Needinfo" request from 5/23/2018. (In reply to Wayne Thayer [:wayne] from comment #8) > Jeremy or Ben: I believe the assertion here is that this issue has been > resolved through a combination of CCADB disclosure and audits (or technical > constraints per Mozilla policy section 5.3) - is that correct? This Bug was originally filed in November 2017, before the deadline to update the CCADB for SMIME CAs. The SubCAs in question were subordinate to the Verisign/Symantec Class 1 and Class 2 roots, which were not enabled for SSL/TLS server issuance, but for SMIME. So part of this issue was resolved in February 2018 when, in compliance with Mozilla Policy, we uploaded these CAs to the CCADB. A secondary task after uploading these CAs to the CCADB has been to file audits for them or to replace them with technically constrained CAs. As noted by Brenda in Comment 11, some of the CAs are listed/covered under Symantec's 2017 audit. A while ago we updated the CCADB for those CAs referenced in the WT 2.0 audit - https://cert.webtrust.org/SealFile?seal=2393&file=pdf. However, as Brenda notes in Comment 11, others of those CAs are covered by the WebTrust/ETSI audits of third parties, which are on different audit cycles. It is this latter group of CA certificates that can cause the most confusion. We continue to education ETSI auditors (and WebTrust auditors outside of North America) on the Mozilla Policy requirements for identifying all CA certificates by SHA2 hash, and other applicable audit requirements, but it has been a much more difficult task than we thought it would be. We often explain what is required, but when we get the audit report, items are still missing. Often the CA and the auditor neglect to include a still-valid CA under the impression that is no longer issuing certificates, even though it has valid, unexpired certificates. > > In my spot checks, not all of these ICAs are [technically constrained or] > listed on the new audit report. For example, "Polbank EFG CA" and "ADACOM > Qualified Services CA" are not technically constrained and are not listed on > the audit report for the "VeriSign Class 2 Public Primary Certification > Authority - G3". The ICA these chain to is listed, but I don't believe that > is sufficient. For instance, the ADACOM Qualified Services CA stopped issuing end-user client certificates (I'm not sure whether they were S/MIME) over a year ago. The Polbank EFG CA expired on 5/28/2017. > > If you agree with my analysis, then what is the plan for these non-compliant > subordinate CA certificates? Third parties are already advised that audits need to include all CA certificates up until the time that the SubCA has been revoked. We advise them that any CA certificate that is not listed with its SHA2 hash in its most recent audit report is subject to revocation, even if the SubCA has ceased issuance or has not issued any certificates in the audit period and that this will likely affect still-valid certificates issued by that SubCA. When we identify that this has occurred (an existing valid CA certificate has not been listed), we contact the third party and advise them that they need to obtain an updated audit report and that the unlisted CA certificate is subject to revocation.
Ben and Brenda: thanks for the explanation. I see that the examples I provided are expired or revoked, and the remaining issues are being worked in bug 1455150.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.