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

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

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

Comment 1

[Franck Leroy]

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

Comment 2

[Ryan Sleevi]

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)

Comment 3

[Gervase Markham [: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

Comment 4

[Kathleen Wilson]

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

Comment 5

[Kathleen Wilson]

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

Comment 6

[Franck Leroy]

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

Comment 7

[Franck Leroy]

Hello

The CCADB has been updated with 'Revocation Status'.

Best regards
Franck Leroy

Comment 8

[Kathleen Wilson]

I believe this bug may be closed now. 

Gerv, do you agree?