1313872 - SHA-1 issuance by DigiCert roots

Status: RESOLVED WONTFIX

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

Description

[Gervase Markham [:gerv]]

In mozilla.dev.security.policy, Patrick Figel writes:

<blockquote>
I found a number of SHA-1 certificates chaining up to CAs trusted by
Mozilla that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos
to censys for making this search incredibly easy.

#1
https://crt.sh/?id=32335005&opt=cablint
  Common Name: portalcsg.siemens.com
  Serial: 1518050245
  Not Before: Jul 12 14:01:45 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#2
https://crt.sh/?id=32335007&opt=cablint
  Common Name: downloada.industrysoftware.automation.siemens.com
  Serial: 2087556804
  Not Before: May 10 15:54:05 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Siemens Issuing CA Class Internet Server 2013
   - Siemens Internet CA V1.0

#3
https://crt.sh/?id=32331581&opt=cablint
  Common Name: VPN-PDC1.vodafone.com
  Serial: 77:00:1c:7f:f6:f8:7e:5d:d6:48:bf:72:4d:00:01:00:1c:7f:f6
  Not Before: Jun 23 09:39:53 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - Vodafone (Corporate Services 2009)
   - Vodafone (Corporate Domain 2009)

...

#5
https://crt.sh/?id=23099350&opt=cablint
  Common Name: enterprisevault.dnb.no
  Serial: 7e:c3:58:c6:d5:0a:4a:7f:c6:be:ea:19:f3:f4:98:e5:9d:cd:df:41
  Not Before: May 19 13:15:04 2016 GMT
  Chains to: "Baltimore CyberTrust Root" (DigiCert) via:
   - DnB NOR ASA PKI Class G
   - Eurida Primary CA
</blockquote>

These issuances are 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) Who has control of the issuing CA - is it DigiCert or the company named in the cert?

D) If the latter, what has DigiCert done in the past to ensure from a technical perspective that the issuance infrastructure of these issuing CAs mandates BR compliance in this and other aspects?

Gerv

Comment 1

[Kathleen Wilson]

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

Comment 2

[Jeremy Rowley]

Thanks Kathleen. Is it okay if we post a separate reply for each incident? These were all issued by CAs outside of our direct control. We're working with them to figure out what happened on their end and will post a reply when received.

Here's what we have from Vodafone:
In answer to your specific questions, please see below.

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

The existing policy documentation does not exhibit this level of detail and is being revised as part of the new SHA-2 PKI infrastructure deployment in line with Web Forum Baseline Requirements. However, DigiCert has communicated to each partner than SHA-1 use is strictly forbidden.
 
B) What is the audit status of the relevant issuing CAs?

The new replacement SHA-2 compliant infrastructure is being scheduled for a point in time audit by Don Sheehy, this will also encompass the legacy SHA-1 PKI infrastructure. Vodafone is migrating to new infrastructure, which will be audited at the end of 2016.
 
C) Who has control of the issuing CA - is it DigiCert or the company named in the cert?

Vodafone controls the issuing CA. The CA is migrating their cert to new infrastructure that includes more sophisticated issuance controls. The new infrastructure will be run by the Vodafone PKI Policy Management Authority.
 
D) If the latter, what has DigiCert done in the past to ensure from a technical perspective that the issuance infrastructure of these issuing CAs mandates BR compliance in this and other aspects?

DigiCert are working in tandem with the new Vodafone Policy Management Authority. The new Vodafone PKI Policy Management Authority are urgently working to enforce the baseline requirements across the legacy and new infrastructures. DigiCert expects all Sub CAs to undergo audits that include verification that the CA is operating in accordance with the BRs and network security guidelines.

Comment 3

[Jeremy Rowley]

Siemens: 

The Siemens issuing CA is under control of Siemens Europe. The CA is a legacy CA from the Verizon era that we are hoping to decommission near the end of the year (giving them time to transition to their new provider). We have communicated with Siemens about the seriousness of their breach of the BRs.

Comment 4

[Gervase Markham [:gerv]]

Separate replies for each incident are fine; let us know if you would prefer separate bugs for each incident.

Gerv

Comment 5

[Pat]

Are these incidents not on a par, perhaps worse, than the recent issue with Uni-Credit?
(https://bugzilla.mozilla.org/show_bug.cgi?id=1261919)

These seem to be a number of unconstrained, CAs which are operated by parties not capable of doing so - issuing SHA-1 certificates this late into 2016. More may be found, as only a few moments search:

At least one more SHA-1 for the .no CA: https://crt.sh/?id=41387818

It seems to me these CA should be revoked and added to browser revocation list asap.
Same for other bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1313874
https://bugzilla.mozilla.org/show_bug.cgi?id=1313873

Comment 6

[Jeremy Rowley]

We've decided to revoke the Nets Norway intermediate for failing to fix their issuance systems the first time this happened. We're working out a revocation schedule based on the public comments. Our current plan is Dec 1 to give them time to quickly find someone new. We're not tied to this date and will accelerate/decelerate it based on the discussion. 

A) Does the CP/CPS of the relevant issuing CA forbid the use of SHA-1? If not, why not?
Not sure. However, the sub CA received instructions  to cease issuance of SHA-1 certs well before Jan 1 and several times after Jan 1. 

B) What is the audit status of the relevant issuing CAs?
Valid, unqualified audit. 

C) Who has control of the issuing CA - is it DigiCert or the company named in the cert?
The company named in the cert

D) If the latter, what has DigiCert done in the past to ensure from a technical perspective that the issuance infrastructure of these issuing CAs mandates BR compliance in this and other aspects?
We haven't done anything technical yet.  So far we've relied solely on audits. We have told each sub CA we are revoking their issuing certs if they aren't compliant. Most of these old Verizon customers are running UniCert (the old Verizon software). We don't have control over the software. Going forward, we would like all sub CAs to submit monthly/quarterly statements about what they've issued so we can run the certs through cab-lint and make sure each cert is compliant. We've set up notifications to alert us if a new SHA1 cert is issued (presuming crt.sh catches the cert).

Comment 7

[Gervase Markham [:gerv]]

WONTFIX: see https://groups.google.com/d/msg/mozilla.dev.security.policy/tHUcqnWPt3o/YbwzHGbZBQAJ. As long as DigiCert continues with their plan and takes robust action about further SHA-1 issuance, no further action.

Gerv

Comment 8

[Ben Wilson]

Siemens' statement: 

------------------

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

The CP / CPS is not specified to such detail and does not explicitly forbid certain algorithms. To cover that topic the Root CA’s CPS states that: “The applicability of cryptographic algorithms and parameters is constantly supervised by the PMA. If an algorithm or the appropriate key length offers no sufficient security during validity period of the Certificate, the concerned Certificate will be revoked and new Certificate Application will be initiated.” 
http://www.siemens.com/corp/pool/pki/siemens_cps_rootcas_en.pdf , Chapter 6.3.2
In the next annual revision of the CP/CPS a detailed list of allowed algorithms will be included.

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

The Siemens CA is annually audited according to ETSI TS 102042 requirements by an external auditor. 
http://www.siemens.com/corp/pool/pki/siemens_etsi.pdf

C) Who has control of the issuing CA?

The issuing CA is under sole control of Siemens AG, as described in Chapter 1.5 of Siemens Certificate Policy 
(http://www.siemens.com/corp/pool/pki/siemens_cp_en.pdf)
 
D) What has been done from a technical perspective that the issuance infrastructure of these issuing CAs mandates BR compliance in this and other aspects?

Siemens CA is issuing certificates only for Siemens’ own purposes for ensuring secure electronic communication between Siemens‘ systems and its employees and business partners (compare Chapter 1.3, CP). Siemens CA has about 1.200 valid server certificates with a validity period of 12 months in the field.
Since 2014 Siemens’ is updating all IT systems to comply with the requirement to use only SHA-2. Since 1st of July 2015 Siemens Server RA (compare Chapter 1.3.2, CP) rejects all electronic certificate requests that request to be signed with SHA-1. This is technically enforced in the ‘Server RA software. On the 2nd of November 2016 Siemens’ new fully SHA-2 signed CA hierarchy became productive.
In accordance with CA BRG 9.4.2, paragraph 2, Siemens’ CA was issuing SHA-1 certificates for not modernized legacy systems until 31st of December 2015 with an exception process.
For these two specific certificates the exception process was erroneously applied in May and July 2016 and the SHA-1 certificates were issued. Both certificates were valid only until 31st of December 2016.
After being informed about this issue and asked to revoke Siemens CA undertook the following two steps:
1)	In accordance with its CP, chapter 4.9.1.3 and 4.9.5 the two certificates were revoked.
2)	The responsible employees were re-informed about this topic in order to assure no further execution of the respective exception process will occur.