Closed Bug 1386891 Opened 7 years ago Closed 7 years ago

Certinomis: Cross-signing of StartCom intermediate certs, and delay in reporting it in CCADB

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: franck.leroy)

References

Details

(Whiteboard: [ca-compliance] [disclosure-failure])

This bug is to determine what should be done about Certinomis in regards to their cross-signing of StartCom intermediate certs and not reporting it in CCADB for 111 days after issuance. https://groups.google.com/d/msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ ~~ Two certificates were disclosed by Certinomis in the CCADB today: - https://crt.sh/?q=F6044A7B147C26BABAB17C5189A09BE781919E95E26F8014D6A8B9880A6BABED - https://crt.sh/?q=6D9A258172F5CD1BDFF447EF64F9A9593070F4ACCBFD07465E4A7CBD205A5CFC These certificates are cross-signs of StartCom’s "StartCom BR SSL ICA” and "StartCom EV SSL ICA” intermediates. The two intermediates have issued many certificates that do not comply with the Baseline Requirements. I’ve included links to 46 of these misissued certificates at the end of this email. Additionally, the intermediates issued by Certinomis have a notBefore date of 2017-04-13, six days after the notBefore dates on the corresponding intermediates issued by "StartCom Certification Authority G3”. It is deeply concerning that these intermediates were not disclosed until 111 days after issuance, as the Mozilla policy is very clear that intermediate certificates must be disclosed within one week of creation and before any leaf or subordinate certificates are issued from the intermediate. ~~
Hello, the 2 CA certificates signed by Certinomis has been retained till a full successful webtrust audit. On end of June the audit report form PwC was available but with still some minor issues. I asked StartCom to correct them. On July 14th the audit report and the policy were updated and published on StartCom website. The first of August I received the agreement from my management to send the CA certificates to StartCom. So I disclose them in the CCADB, with the corresponding policy documents and audit reports before sending them to Inigo. So StartCom was not able to use the path our Root before yesterday. If there are some previous issued TLS certificates that does not comply with BR, then theses TLS certificates has to be revoked. Best regards Franck Leroy
Kathleen: Bug 1386894 tracks the StartCom side, and this tracks the Certinomis side. I realize there's active discussion on m.d.s.p. ( https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ ) as to StartCom's next steps, but it's unclear what, if anything, is necessary from Certinomis regarding this. I think the information shared in Comment #1 in this, in https://bugzilla.mozilla.org/show_bug.cgi?id=1386894#c2 and and https://bugzilla.mozilla.org/show_bug.cgi?id=1386894#c8 , and https://groups.google.com/d/msg/mozilla.dev.security.policy/hNOJJrN6WfE/DlXtXwHHAQAJ are probably the extent of relevant information. 1) What information is desired from Certinomis 2) What remediation steps (if any) is desired from Certinomis 3) Are there any follow-up bugs to create (e.g. clarification in Mozilla PKI policy)
Flags: needinfo?(kwilson)
Flags: needinfo?(gerv)
The current plan is to add these certificates to OneCRL. The question here is to what degree do we hold Certnomis accountable for the misissuances by StartCom? By creating this cross-sign, Certnomis enabled for public trust a number of certificates which were not BR-compliant. I would want to check which these certs existed at the time the cross-sign was made, and which existed at the time it was released. Re 3): The fact that intermediates need to be disclosed within a week of creation is now policy (as of 2.5), although it was not at the time of this incident. I also filed https://github.com/mozilla/pkipolicy/issues/102 ("Ban cross-signing when a CA is under sanction") as a result of this issue. Gerv
Flags: needinfo?(gerv)
(In reply to Gervase Markham [:gerv] from comment #3) > The current plan is to add these certificates to OneCRL. I filed Bug #1402158 to add these two certs to OneCRL.
Depends on: 1402158
Flags: needinfo?(kwilson)
(In reply to Gervase Markham [:gerv] from comment #3) > The current plan is to add these certificates to OneCRL. These certs have been added to OneCRL per Bug #1402158. > > The question here is to what degree do we hold Certnomis accountable for the > misissuances by StartCom? > > By creating this cross-sign, Certnomis enabled for public trust a number of > certificates which were not BR-compliant. I would want to check which these > certs existed at the time the cross-sign was made, and which existed at the > time it was released. > Franck, Please... 1) Provide an incident report in this bug, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report 2) Update the 'Revocation Status' for the corresponding records in the Common CA Database after you have revoked them and added them to the appropriate CRL.
Incident Report 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the time and date. On August 2nd 2017 (14:35 GMT+2), Certinomis disclosed 2 cross-signed ICAs for StartCom in CCADB. On August 3rd 2017 (00:39 GMT+2), Jonathan Rudenberg starts a discussion in mozilla.dev.security.policy about non BR compliant certificates issued by StartCom ICAs. https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RJHPWUd93xE/6yhrL4nXAAAJ 2. 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. On August 3rd 2017 (09:59 GMT+2), Certinomis answered to mdsp to explain that as StartCom has provided a full webtrust audit for theses ICAs, then the 2 certificates has been disclosed both to StartCom and to the community through CCADB. Certinomis also explains that all non BR compliant certificates issued during the setup process has to be revoked by StartCom. On August 3rd 2017 (10:44 GMT+2), StartCom replies that majority of these invalid test certificates are already revoked, and that the other ones are about to be. On August 7th 2017 (11:21 GMT+2), as the discussions in mdsp were going into many directions, Certinomis explained the list of actions that have been done since the beginning of the cross-signing project in order to support StartCom to “back in the business”. The conclusion of all the discussions is that the cross-signed ICAs validity covers a period where some invalid BR (test) certificates has been issued, so Mozilla asked to put these ICAs into the OneCRL. https://bugzilla.mozilla.org/show_bug.cgi?id=1386894 Then Certinomis has decided to revoke theses ICAs; there is no impact on the public has no TLS certificates has been disseminated through these trust paths. The ARL signing operation is planned to October 18th 2017. 3. Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL 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. StartCom has not issued TLS certificates to the public, only test certificates in order to setup its new PKI system. It was planned to issue TLS certificates after the disclosure, but in regards with the mdsp discussions, StartCom decided not to issue any certificates under these trust paths. 4. 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. Some test certificates has been issued between the creation of the ICAs (April 7th 2017) and the cross-signing public disclosure (August 3rd 2017). On August 4rd 2017 (19:09 GMT+2), StartCom gives a detailed explanations about invalid certificates issuance, in summary: a.- test certificates during CT log implementation b.- pre-certificates: there were 4 pre-certificates that were logged in the CTs that finally weren´t issued. c.- mis-issuances related to the use of curves that are allowed by the BRs but not in Mozilla. d.- one mis-issuance certificate with the country code wrong. e.- mis-issuances related to Unicode. There were some certs with DNS not valid due to the use of their own language, cyrilic, chinese, etc. 5. 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/?opt=cablint&id=135182815 https://crt.sh/?opt=cablint&id=134843670 https://crt.sh/?opt=cablint&id=134843674 https://crt.sh/?opt=cablint&id=134843685 https://crt.sh/?opt=cablint&id=134869886 https://crt.sh/?opt=cablint&id=134843694 https://crt.sh/?opt=cablint&id=134843703 https://crt.sh/?opt=cablint&id=134843707 https://crt.sh/?opt=cablint&id=138327705 https://crt.sh/?opt=cablint&id=140047773 https://crt.sh/?opt=cablint&id=137248474 https://crt.sh/?opt=cablint&id=140623429 https://crt.sh/?opt=cablint&id=139640371 https://crt.sh/?opt=cablint&id=139701126 https://crt.sh/?opt=cablint&id=140087378 https://crt.sh/?opt=cablint&id=140087671 https://crt.sh/?opt=cablint&id=146517428 https://crt.sh/?opt=cablint&id=134843674 https://crt.sh/?opt=cablint&id=157917796 https://crt.sh/?opt=cablint&id=134869886 https://crt.sh/?opt=cablint&id=179453898 https://crt.sh/?opt=cablint&id=156959581 https://crt.sh/?opt=cablint&id=139640371 https://crt.sh/?opt=cablint&id=137248474 https://crt.sh/?opt=cablint&id=153410888 https://crt.sh/?opt=cablint&id=155895466 https://crt.sh/?opt=cablint&id=155066805 https://crt.sh/?opt=cablint&id=155035575 https://crt.sh/?opt=cablint&id=134843670 https://crt.sh/?opt=cablint&id=146484676 https://crt.sh/?opt=cablint&id=153370547 https://crt.sh/?opt=cablint&id=150133570 https://crt.sh/?opt=cablint&id=155077521 https://crt.sh/?opt=cablint&id=155358674 https://crt.sh/?opt=cablint&id=134843703 https://crt.sh/?opt=cablint&id=154267215 https://crt.sh/?opt=cablint&id=179437157 https://crt.sh/?opt=cablint&id=149445010 https://crt.sh/?opt=cablint&id=134843694 https://crt.sh/?opt=cablint&id=160150786 https://crt.sh/?opt=cablint&id=146437172 https://crt.sh/?opt=cablint&id=146437565 https://crt.sh/?opt=cablint&id=153404034 https://crt.sh/?opt=cablint&id=179425684 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The main mistake is that StartCom should have performed all the testing on a staging environment in order to avoid that all invalid BR certificates generated during the system initialisation had impact on the public ICAs. The second point is that Certinomis should not have cross-signed StartCom ICAs before StartCom provided a the full webtrust audit. 7. 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. The 2 cross-signed StartCom ICAs are planned to be revoked during the next key-ceremony operation (October 18th 2017). The Certinomis Root Policy will be updated to add more requirements on cross-signing operations, in particular that the ICA shall not be signed before having a full successful audit (webtrust/ETSI). Best Regards Franck Leroy Certinomis CTO
Assignee: kwilson → franck.leroy
Hello The CCADB has been updated with 'Revocation Status'. Best regards Franck Leroy
I believe this bug may be closed now. Gerv, do you agree?
Flags: needinfo?(gerv)
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(gerv)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [disclosure-failure]
You need to log in before you can comment on or make changes to this bug.