1262971 - e-Szigno SSL CA 2014 issuing certificates with improper or missing subject alternative name extensions

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Dana Keeler (she/her) [:keeler]]

e-Szigno SSL CA 2014 (sub-CA of Microsec e-Szigno Root CA 2009) is issuing certificates that either do not have a subject alternative name extension or where the subject common name does not correspond to a dNSName or iPAddress entry in the subject alternative name extension.

https://crt.sh/?id=16145440&opt=cablint
https://crt.sh/?id=15642758&opt=cablint
https://crt.sh/?id=16176922&opt=cablint

Comment 1

[Dana Keeler (she/her) [:keeler]]

Here's a more recent one: https://crt.sh/?id=26286155&opt=cablint

Comment 2

[Kathleen Wilson]

Sándor, Please look into this continued issuance of certs that do not have the proper entries in the SAN. 

In Bug #1245280 we disabled CN fallback for all certificates with a notBefore date later than 23 August 2016. This shipped in Firefox 48, which is the current release. As a result, all newly-issued certificates that do not have a subject alternative name extension with the appropriate DNS name entries will not validate successfully in Firefox.

Comment 3

[dr. Sándor SZŐKE]

Dear Kathleen,

 we checked our system. We could find that our CP and CPS defines proper content for the SAN extension, but in some special cases it was possible to issue certificates with false content with missing fields.

We developed and installed further automatic checks in our CA program. We automatically check the fields of the certificates after each data entry, data modification and before the issuance of the certificate.

Comment 4

[Kathleen Wilson]

(In reply to dr. Sándor SZŐKE from comment #3)
> Dear Kathleen,
> 
>  we checked our system. We could find that our CP and CPS defines proper
> content for the SAN extension, but in some special cases it was possible to
> issue certificates with false content with missing fields.

Do any of those certificate pose a security issue?
Do any of them need to be revoked and added to OneCRL?

> 
> We developed and installed further automatic checks in our CA program. We
> automatically check the fields of the certificates after each data entry,
> data modification and before the issuance of the certificate.


Does this mean that all future TLS/SSL certificates issued in this CA hierarchy will have a subject alternative name extension and the subject common name will correspond to a dNSName or iPAddress entry in the subject alternative name extension?

Comment 5

[dr. Sándor SZŐKE]

(In reply to Kathleen Wilson from comment #4)
> (In reply to dr. Sándor SZŐKE from comment #3)
> > Dear Kathleen,
> > 
> >  we checked our system. We could find that our CP and CPS defines proper
> > content for the SAN extension, but in some special cases it was possible to
> > issue certificates with false content with missing fields.
> 
> Do any of those certificate pose a security issue?
> Do any of them need to be revoked and added to OneCRL?
> 

None of those certificates has security issues, so none of them need to be revoked.

> > 
> > We developed and installed further automatic checks in our CA program. We
> > automatically check the fields of the certificates after each data entry,
> > data modification and before the issuance of the certificate.
> 
> 
> Does this mean that all future TLS/SSL certificates issued in this CA
> hierarchy will have a subject alternative name extension and the subject
> common name will correspond to a dNSName or iPAddress entry in the subject
> alternative name extension?

Yes, all future TLS/SSL certificates will contain SAN extension which will correspond to a dNSName or iPAddress.

Comment 6

[Ryan Sleevi]

Kathleen: Under the BRs, these are required to be revoked if the CA determines it does not meet their CP/CPS. As such, in line with the answer to Comment 3, they should all be revoked as misissued, separate as to whether or not they end up on OneCRL.

Comment 7

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #6)
> Kathleen: Under the BRs, these are required to be revoked if the CA
> determines it does not meet their CP/CPS. As such, in line with the answer
> to Comment 3, they should all be revoked as misissued, separate as to
> whether or not they end up on OneCRL.

Ooops. Thanks for pointing that out. Re-opening bug...

Comment 8

[dr. Sándor SZŐKE]

You are right, we revoke and replace these certificates.

Comment 9

[dr. Sándor SZŐKE]

Dear Kathleen,
I inform you, that we have revoked all of the misissued SSL certificates and we have issued new certificates to our customers with proper SAN extension.

Comment 10

[Kathleen Wilson]

Is it OK to close this bug now?

Comment 11

[dr. Sándor SZŐKE]

For me it is OK

Comment 12

[Kathleen Wilson]

I confirmed that these certs were revoked. So, I believe this bug has been resolved.