UniCredit Subordinate External issuing certificates without subject alternative name extension

RESOLVED FIXED

Status

task
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: keeler, Assigned: rick_andrews, NeedInfo)

Tracking

trunk
Dependency tree / graph

Firefox Tracking Flags

(firefox48 affected)

Details

UniCredit Subordinate External (a sub-CA of GeoTrust Global CA) is issuing certificates without a subject alternative name extension:

https://crt.sh/?id=8398352&opt=cablint (this one also doesn't have an HTTP OCSP URI)
https://crt.sh/?id=16074141&opt=cablint
https://crt.sh/?id=15837511&opt=cablint
https://crt.sh/?id=15651742&opt=cablint
Website(s): https://www.unicredit.it/it/privati.html

Certs chain up to: GeoTrust Global CA
Assignee: nobody → rick_andrews
Also https://www.unicreditgroup.eu/ and https://www.unicredit.com fail, not sure how to verify if the underlying issue is the same (I'd guess so).
Hi,

please correct me if i am wrong, but i can't find any RFC that declares the SAN (subject alternative names) extension as required in a X509 certificate.
Only BR compliance states that it is required, but on what basis?
RC 2459 is obsoletetd by RFC 5280 which is updated by RFC 6818
But there is not a single word, that SAN is required.
On the other hand the RFC's clearly say:
   If the CA issues certificates with an empty sequence for the subject
   field, the CA MUST support the subject alternative name extension
   (Section 4.2.1.6)
Or:
   At a minimum, applications conforming to this profile MUST recognize
   the following extensions: key usage (Section 4.2.1.3), certificate
   policies (Section 4.2.1.4), subject alternative name
Or:
   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.

To me this all boils down to one thing.
SAN can be present, but a certificate without a SAN is perfectly allright as long as the CN is present.
Browsers and CA's must honor the SAN, if present.
Openssl does not complain on csr's that do not contain a SAN

Please correct me if i am wrong.
1) The Baseline Requirements require it. That should be the end of the story. If you have an issue with the Baseline Requirements, communicating them to the CA/B Forum is useful. But please note, the Baseline Requirements explicitly exist to set the reasonable profile of RFC 5280 (which itself is a profile of X.509) to be appropriate for Internet security.

2) RFC 2818 deprecated the CN. This was in 2000. There's no defensible excuse for only including the common name - you're including something that's been deprecated for 16 years, that's well in the target of "irresponsible action".
1) I have no reason to put a CA/B Forum over a RFC. 

2) Although RFC 2818 names the Cn as deprecated it is still allowed but "discouraged". I can't see how useing a CN poses any security risk or any misbehaviour or any worries. Calling the usage of CN a "irresponsible action" is  way too much. And still the newer RFC's allow using the CN (mostly, I think, for backward compatibility or bad clients). Anyway all clients that follow the RFC's should ignore the CN, if SAN is present.
You've misunderstood the purpose of the Baseline Requirements, then, and why it and Mozilla's Program Requirements exist. They exist to restrict what is permissible in the RFC. For example, RFC 5280 says nothing about key policy - a 256-bit RSA key is permissible according to RFC5280, but clearly unacceptable for security. Regardless, just because RFC5280 says something is permissible does not mean that RFC5280-profiling clients (such as every root store) needs to allow it. Just like RFC5280 limits what is permissible in X.509, the BRs limit what is permissible in RFC5280.

There's been plenty of discussion about how using a CN poses risk. The obvious example is that it's not subject to dNSName nameConstraints according to the RFC (which is why, independent, and thus by your inaccurate definition, contrary to, Mozilla enforces dNSName nameConstraints on the CN).

In any event, this isn't the bug to justify the BRs to you. This is clearly a violation of the BRs. Mozilla requires conformance to the BRs. Therefore, this is not conforming to Mozilla's requirements.
Forgive me for not having the time to follow all those discussions about CN risks but still wanting to understand the topic. Which I do understand better now.

Understanding that you are an expert in certs and security, what is your opinion on CN than, when doing a certificate signing request:
a) leave out the CN completely and fill in only the SAN, with the potential risk of loosing clients or client applications that, and I agree, might be a security nightmare?
b) set the CN in addition to the SAN, following the nameConstraints?

Your opinion is highly apreciated
As specified in the baseline requirements, a) is acceptable (but can cause compatibility issues with clients which failed to follow RFC 2818, despite it being 16 years old). If b) is followed, the CA MUST set the CN to a name that appears in the subjectAltName (that is, whatever is present in the CN MUST ALSO be in the sAN).

This protects clients that properly implemented 2818 (aka the vast majority of browsers - spottier support for command-line tools), in that clients will ignore the CN when the sAN is present, thus eliminating the risk. For clients that don't support the sAN, and only support the CN, it protects them by ensuring that the CN is validated to the same appropriate naming standards.

So if you had a certificate for "example.com", you could have a CN of "example.com" and a sAN:dNSName of "example.com". If you had an IP address of 8.8.8.8, you could have a CN for "8.8.8.8" and a sAN:iPADdress of 8.8.8.8. But you could NOT have (according to the BRs, which itself is providing an overlay for RFC 5280 and 2818) a certificate with a CN of "good.example.com" and a sAN:dNSName of *.example.com. That's because the CN would not be an exact value of the sAN. You COULD have a certificate with a CN of "good.example.com" and two sAN:dNSNames of "*.example.com" and "good.example.com"

Again, this is all covered in the Baseline Requirements, but also RFC 6125 (which updates RFC 2818) and RFC 5280.
Duplicate of this bug: 1261680
Is this still an issue for current versions?  Is this even actually a bug in NSS or Firefox? I'm not sure release management needs to track this.
Flags: needinfo?(ryan.sleevi)
Flags: needinfo?(dkeeler)
Yes, it's an issue in all versions of NSS, because it's an externally operated CA.

No, it's not a bug in NSS/Firefox, but it's a violation of the policies of the Mozilla CA Certificate Policy, which requires a decision about appropriate next steps, which may include distrusting the sub-CA or the root CA, as outlined at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Release Management doesn't need to track this until such a time a decision is made about the scope of concern, the impact to Firefox users, and the appropriate next steps. At such a time, it will be decided whether or not code changes (such as distrusting) are necessary, or whether this matter can be addressed solely via policy.
Flags: needinfo?(ryan.sleevi)
Flags: needinfo?(dkeeler)
We have been informed by UniCredit that the following certificates have been revoked:

1. www.unicredit.it (https://crt.sh/?id=8398352&opt=cablint)
2. ilupload.hvbis.com (https://crt.sh/?id=16074141&opt=cablint)
3. ideasharing.unicredit.eu (https://crt.sh/?id=15837511&opt=cablint)
4. extranet.quercia.it (https://crt.sh/?id=15651742&opt=cablint)
5. www.unicreditgroup.eu (from comment 2)
6. www.unicredit.com (from comment 2)

It seems that crt.sh is down at the moment so I don't have links for 5 and 6.
Rick: It's worth noting that, based on https://mozillacaprogram.secure.force.com/CA/PublicIntermediateCerts?CAOwnerName=Symantec%20/%20GeoTrust , Symantec has still not disclosed the audit status of UniCredit, despite claiming in https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 to have completed this on 18 April 2016.

The CPS provided by Symantec, http://ca.unicredit.eu/CPS/cps.html , was last updated on 03/12/2012 and has not incorporated the Baseline Requirements into it (beyond Section 3.1.1). It does indicate, in Section 7.1.2.3, that the subjectAltName field is not always used, which would be a violation.

(It's also missing disclosures for "AlwaysOnSSL CA - G2", "Hostpoint DV SSL CA - G2", "Intermediate Certificate DV SSL CA", "Intermediate Certificate DV SSL CA - G2", "Secure Site Starter DV SSL CA - G3", "STRATO SSL", "STRATO SSL - G2", "STRATO SSL - G4", "Trust Provider B.V. DV SSL CA - G2", "Volusion, Inc. DV SSL CA", "Volusion, Inc. DV SSL CA - G2", "Volusion, Inc. DV SSL CA - G4", "TC TrustCenter Class 4 Extended Validation CA III", "GeoTrust ECC EV SSL CA", "AlwaysOnSSL CA - G1", "GeoTrust DV SSL SHA256 CA - G2", "GeoTrust Secure Site Starter DV SSL CA - G1", "Hostpoint DV SSL CA - G1", "Intermediate Certificate DV SSL CA - G3", "RapidSSL SHA256 CA - G4", "STRATO SSL - G3", "STRATO SSL - G5", "Trust Provider B.V. DV SSL CA - G1", "TrustAsia Technologies, Inc. DV SSL CA - G1", "Volusion, Inc. DV SSL CA - G3", and "Volusion, Inc. DV SSL CA - G5")
UniCredit have revoked the reported certificates and implemented technical and administrative controls that enforce inclusion of SANs.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Not sure if this bug is the right place to ask, but certificate issues are still pretty much there. 

Try loading https://www.unicredit.it in Nightly. They recently redesigned the websites: main site loads (good certificate), all assets don't (bad certificate on https://content.unicredit.it). Also Client area doesn't load for the same issue https://online-retail.unicredit.it
:flod - Right now nightly/aurora are configured to be a bit more strict by default so we can identify potential problems. These sites should work just fine on beta/release (although they really should have their certificates revoked and replaced, but that's a job for the CA/site operators).
Hi Steve, it looks like there are at least two certificates that were issued in June that have this issue and don't appear to be revoked (well, the OCSP responder doesn't seem to be working at the moment, but the cached data at https://certificate.revocationcheck.com says they're not revoked and they're also not in the crl they point to) :

https://crt.sh/?id=28013556&opt=cablint
https://crt.sh/?id=21122647&opt=cablint
Flags: needinfo?(steve_medin)
Davld, thanks for the links. We recently required UniCredit to review all issued certificates for this issue and replace and revoke. That is work in progress that we are pressing for completion.  In response to this comment, I have additionally asked for an explanation for the OCSP response outage.
David, given that UniCredit does not have a WebTrust or WebTrust for BRs audit, and their first awareness of these was earlier this year, I'm not sure if we should be surprised if we keep finding non-compliance.

Symantec still hasn't disclosed the audit statements, but Google has confirmed with UniCredit that they lack audits and were not informed of the necessity for them until after the deadline for disclosure had passed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Steven, Firefox 48 will start enforcing that all new certificates as of August 23rd have a subject alternative name extension, meaning that if they continue to issue certs like this, those certs won't work.

This was communicated to CAs in https://wiki.mozilla.org/CA:Communications#March_2016
Action 4: (d) Subject CN name information (if present) does not have a corresponding iPAddress or dNSName entry in the subjectAltName extension. Workaround to be removed in Bug #1245280.
Symantec has not received an audit from UniCredit that supports continued operation of a subordinate CA within UniCredit. Therefore, as of September 30th, we require UniCredit to stop issuing new certificates from this CA. We will allow the CA to operate until November 30th only for validation purposes. As soon as practical after November 30th, the sub CA certificate will be revoked by Symantec.
"Therefore, as of September 30th, we require UniCredit to stop issuing new certificates from this CA."

https://censys.io/certificates/52a884c3a5153d5c432e7ec66ddd6cf4f17958f3af9548727e494e62afc06523

Validity
2016-03-15 08:30:41 to 2017-03-15 08:30:41
(In reply to GP from comment #22)
> "Therefore, as of September 30th, we require UniCredit to stop issuing new
> certificates from this CA."
> 
> https://censys.io/certificates/
> 52a884c3a5153d5c432e7ec66ddd6cf4f17958f3af9548727e494e62afc06523
> 
> Validity
> 2016-03-15 08:30:41 to 2017-03-15 08:30:41

This was issued in March. We did not state that UniCredit would have zero certificates valid after September 30. @21 said UniCredit are allowed to use existing certificates until their subordinate CA is revoked in early December.
Sorry, I mean to send:

https://crt.sh/?id=40445775

Issued on Oct 3, after you state
"Therefore, as of September 30th, we require UniCredit to stop issuing new certificates from this CA."
As a result of the inability of Symantec to maintain suitable audits or controls, and the inability of UniCredit to ensure contractual compliance, Google will be adding the UniCredit intermediate to its CRLSets tomorrow by EOD, to propagate to Chrome clients over the following days.
Symantec has determined that UniCredit violated the terms of a transition agreement that ended certificate issuance rights effective 30 September and permitted temporary continued certificate trust supported by OCSP/CRL services until 30 November.  While the violating issuance was presented to us as a misunderstanding and the offending certificate was revoked, our terms for continued trust were clear and we take them seriously.
 
At end of business Tuesday, 25 October, we will revoke the UniCredit subordinate CA.
(In reply to Steven Medin from comment #26)
> At end of business Tuesday, 25 October, we will revoke the UniCredit
> subordinate CA.

At the end of business Tuesday, 18 October, we will revoke the UniCredit subordinate CA.
As disclosed @27, today we revoked subordinate CAs issued to UniCredit under the GeoTrust Global CA. The revoked CAs are posted to our public CRL at http://g.symcb.com/crls/gtglobal.crl. Four entries were added to the CRL for this event.

These revocations have been marked on the subject certiifcates at Mozilla Salesforce.

Here are references to the subordinate CAs:
https://crt.sh/?sha256=8c31013d19f8eea618c95fda6d21f5777c6e930c7413031559ee863d78dfe809
https://crt.sh/?sha256=fdadfc959cbeeecbdb60711a7143bf9922f3e7c232ff59cb59d076fef6637610
https://crt.sh/?sha256=adb034413ad16b538c57f5a0bd103b3504736f99b0c762a53e72fa7a2b5eca46
https://crt.sh/?sha256=77057825b10ea26292e56cde58ee92a1a27baf536b7ad383971b2ae5912227bb
These are marked as "Ready to Add" to OneCRL in the CA Community in Salesforce.
Blocks: onecrl-meta
Added to OneCRL.
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.