1386894 - StartCom: Non-BR-Compliant Certificate Issuance -- adding Certnomis intermediates to OneCRL

Status: RESOLVED DUPLICATE of bug 1402158

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Many non-BR-compliant SSL certs have been issued from the StartCom intermediate certs, and the list provided demonstrates some very sloppy issuance practices. I think we should add the two StartCom intermediate certs to OneCRL.

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.

I think the correct response is to add both intermediates to OneCRL immediately, especially given the historic issues with StartCom.

Jonathan

—

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

Comment 1

[Kathleen Wilson]

Mark, Please create the OneCRL entries for the following two certs, and the revocations.txt file so Matt can run compat testing.


cert: https://crt.sh/?id=182884215
Issuer commonName: Certinomis - Root CA
Subject commonName: StartCom BR SSL ICA
Certificate Serial Number: 5aed253a6e64ca53f9b8ebba99de319960b702d4

cert: https://crt.sh/?id=182884216
Issuer commonName: Certinomis - Root CA
Subject commonName: StartCom EV SSL ICA
Certificate Serial Number: 67b9b0973e0d036b3ef1d9f04734ff46f2bd6594

Comment 2

[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 3

[Iñigo]

Hi all,

what Fanck is saying is true and we haven´t started to issue any cert using this new path. 

Regarding the info that is in this bug I´m really shocked because the majority of them are revoked and don´t understand why have been included here. 


For those which are not revoked are due to use different curves (P-384, P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB Forum and there´s no conclusion yet, but in any case we´re not allowing to use them anymore. There´re curves allowed in the BRs that Mozilla does not include. 

1. The un-revoked test certificates are those pre-sign ones with uncompleted ctlog. So they are not completed certificates.
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=139640371

2. Other un-revoked certificates have the same error “ ERROR: Unallowed key usage for EC public key (Key Encipherment) ”
https://crt.sh/?opt=cablint&id=153404034
https://crt.sh/?opt=cablint&id=160150786
https://crt.sh/?opt=cablint&id=149445010
https://crt.sh/?opt=cablint&id=150133570


And what I don´t understand are those comments of "very sloppy isuance practices" , "many non-BR compliants", "specially given the historic issues with StartCom" and consider them very unfair. These are subjective opinions which are very dangerous and not fair. 
This is a totally new system that is not related with "the historic issues" at all, so whatever happened in the past is not related (and we could talk a lot of why StartCom was distrusted in the past), only the name is the same.
Some of the issues are also related what has been discussing in the CABF related to the Unicode and punnycode in domanins, etc. and even there´s no conclussion as the ballot failed, we decided to revoke those to avoid issues but you include them here as non BR compliants and very sloppy issuance practices.

Finally I´d like to understand also why has been asked to create OneCRL entries for these subCAs.

I may think this post and some other comments in the m.d.s.p are malicious and don´t know why.

Regards

Comment 4

[Mark Goodwin [:mgoodwin]]

(In reply to Kathleen Wilson from comment #1)
> Mark, Please create the OneCRL entries for the following two certs, and the
> revocations.txt file so Matt can run compat testing.

Certainly.

It will make things easier if we approve the pending changes in bug 1385914 before I stage this - might you or JC be able to do this?

Comment 5

[Iñigo]

Hi,

We´ve revoked the pre-certificates and also those related to the use of different curves to avoid further issues.

But still don´t understand why these certs, signed by Certinomis, have to be put into OneCRL if they have been under Certinomis control and have been disclosed when all the requirements set have been met. What´s the posible damage? According to some comments not all it´s about webPKI but I think not in this case, because these are only to issue TLS certs.

Regards

Comment 6

[Peter Bowen]

Iñigo,

The CCADB policy, which is incorporated by reference in the Mozilla CA policy, says:

"Intermediate certificates that chain up to root certificate(s) in the CCADB and that are not exempt must be entered into the database. This includes certificates that are revoked. For newly-created intermediate certificates, this must happen before the certificate begins issuing publicly-trusted certificates."

The Mozilla policy also says:

"The CA with a certificate included in Mozilla’s root program MUST disclose this information within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates"

Based on previous comments, the time from certificate creation to disclosure was well longer than one week.  I believe that this is the rationale for requesting it to be added to OneCRL.

Thanks,
Peter

Comment 7

[J.C. Jones [:jcj] (he/they)]

I've finalized bug 1385914, so this should be a clean state to add to OneCRL for you, Mark.

Comment 8

[Franck Leroy]

Hello

"For newly-created intermediate certificates, this must happen before the certificate begins issuing publicly-trusted certificates."

In my understanding as the intermediate CA certificates were not available to StartCom, no TLS certificates issued can be installed using these "cross signed" certificates that chains up to our root. So till end of July no certificates issued are chained to a publicly trusted root.

The idea was that we did not wanted to give the CA certificates to StartCom before a successful webtrust audit (like Mozilla did not put a cert in the NSS till the inclusion process has not ended).

As the audit has passed, I disclosed the certificates in the CCADB with the corresponding policies and audit reports and after I retrieve the intermediate CA certificates from my safe and sent them to Inigo.

I see no differences with a CA certificates that is not trusted, that issues TLS certs, then becomes trusted by Mozilla (let’s say on 08/01/2017). It is not required to recreate a CA certificate with a start date on 08/01/2017 ??

So what is your goal? To revoke these intermediate certs and we have to resign them to have a starting date in august 2017?

For example for our SHA2 root created on 10/21/2013, I filled the mozilla bug on 11/12/2013, and the end of discussions where on 08/24/2016.

What about certs issued from November 2013 to August 2016?
May be some of them where finally not compliant with BR so we revoked them.
But we did not issue new intermediate CA certificate when added in the NSS in 2016.

I dont understand what are the risks in that particular case, how they are different from a new NSS application and a cross signing operation.

Regards
Franck