1315035 - SHA-1 issuance by T-Systems root

Status: RESOLVED FIXED

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

Description

[Gervase Markham [:gerv]]

https://crt.sh/?cablint=211&iCAID=770&minNotBefore=2016-01-01&opt=cablint lists three certificates for the domain names "mawi.hilgmbh.de", "centest.mohnmedia.net" and "cendemo.mohnmedia.net", which use the SHA-1 hash algorithm and were issued in 2016. These certs was issued by the intermediate "Shared Business CA 3":
https://crt.sh/?caid=770&opt=cablint
which chains up to "Deutsche Telekom Root CA 2", a root certificate trusted by Mozilla to issue server certificates. These certificates do not have an Extended Key Usage extension and therefore AIUI would be recognised by Firefox as valid for servers.

We recognise these certs have been revoked. However, this issuance is in violation of the Baseline Requirements, which Mozilla policies require adherence to. Please can you explain what has happened, with particular reference to the following questions:

A) Does the CP/CPS of the relevant issuing CA forbid the use of SHA-1? If not, why not?

B) What is the audit status of the relevant issuing CAs?

C) What technical controls are in place within your CA to prevent SHA-1 issuance and how were they bypassed?

Gerv

Comment 1

[Kathleen Wilson]

Bernd, Please look into this and update this bug with the information listed above as soon as possible.

Comment 2

[Gervase Markham [:gerv]]

I notice one of these certs was discovered earlier this year and discussed in this thread:
https://groups.google.com/d/msg/mozilla.dev.security.policy/xKibg5sf5Oc/P0QAb728BAAJ 

However, there seem to be some open questions there which were not answered. Now might be a good moment for T-Systems to explain fully what happened in that case, and the other case.

Gerv

Comment 3

[Bernd]

Gerv, we also discussed these topics in January on “mozilla.dev.security.policy”, see:
https://groups.google.com/d/msg/mozilla.dev.security.policy/SoODejSKGv0/kk3UNaM1AQAJ

Bernd

Comment 4

[Gervase Markham [:gerv]]

Bernd: on 3rd Feb you said (in the thread that you link to) that "SHA-1 certs can no longer be issued.". However, this cert:
https://crt.sh/?id=15019496&opt=cablint
was issued on 9th March. How did that happen?

Gerv

Comment 5

[Bernd]

Hi Gerv, this certificate was issued by a customer (hilgmbh.de), to misuse an S/MIME certificate (SHA-1) as a gateway certificate, see:
https://groups.google.com/d/msg/mozilla.dev.security.policy/xKibg5sf5Oc/P0QAb728BAAJ.
Bernd

Comment 6

[Gervase Markham [:gerv]]

Bernd: in the conversation you link to, Nick Lamb had some very good questions. Please can you provide answers to them?

Thanks,

Gerv

Comment 7

[Bernd]

The T-Systems "Shared-Business-CA" (SBCA) is a managed corporate PKI. Depending on the scope, SBCA can issue different certificate types. These certificate types have different profiles and use different templates, in which the CP/CPS defines the usage and scope of the certificates.

For a short time, some fields were not checked properly while issuing SMIME certificates. This was caused by an error within the verification routine. Because of that, it was possible to fill the common name field (CN) with an FQDN instead of given name and surname. Although this is prohibited specifically in the CP/CPS, these circumstances were utilized. 

Promptly after we realized the problem, the corresponding option was deactivated. Therefore, no additional certificates could be issued in this form. The affected certificates were revoked immediately. 
Following, the error was fixed and the continuous monitoring as the internal reviews were enhanced.

Bernd

Comment 8

[Gervase Markham [:gerv]]

Thank you for the explanation, and the details of the steps you are taking to make sure this doesn't happen again.

Gerv