Closed Bug 988633 Opened 6 years ago Closed 2 years ago
Daddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority
The attached certificate was presented by www.digitalocean.com and issued by Go Daddy Secure Certification Authority. The encoding of the basic constraints extension includes the value of the bool cA. Since that value is the default value false, it should not be included in the encoding. As an aside, this causes mozilla::pkix to terminate the connection. Using classic/libpkix verification, the certificate is presented as an EV certificate.
Can you provide clarification why you think this is an invalid encoding? Per https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_61.pdf , basicConstraints is optional, but if present, MUST be set to false. Using X.690 (2002), at http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf , Section 8.11.3, states "The encoding of a data value may, but need not, be present for a type which was referenced with the keyword OPTIONAL or the keyword DEFAULT." Sounds like a bug in mozilla::pkix
Bah, was citing SET, not SEQUENCE. 11.5 of X.690 - "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value." Yes, bad cert.
I agree that this is invalid encoding, based on that X.690 clause and the default that is set in RFC5280. Go Daddy will change its issuing profile to omit the CA basic constraint boolean when False on future certificates, as soon as prudent. Unfortunately, this issue exists for nearly all existing Go Daddy issued certificates. Perhaps mozilla::pkix could be updated to parse such encoding as libpkix (and openssl and others) do today?
Right - this will be a considerable compatibility issue. We'll have to do something like with bug 985021 / bug 985025.
See bug 989516 and bug 989518 for the mozilla::pkix work. This bug will track communications and decisions with Go Daddy.
I agree with this approach. I will add this to my list of things we've found with mozilla::pkix that CAs should stop doing. I'll need to communicate these things to CAs and allow for transition time. Thanks, Kathleen
Kathleen: The Baseline Requirements are already supposed to cover this. The Baseline Requirements 1.1.6, Appendix B sets the normative requirements. Section 4 ("All Certificates") states that the fields MUST be set in accordance with RFC 5280. This is equally consistent with the definition of a "Valid Certificate", which is "A certificate that passes the validation procedure specified in RFC 5280". The *only* exception to RFC 5280 is explicitly called out as such, namely Appendix B, Section 2, Item F "nameConstraints". While I appreciate calling it out - much as, unfortunately, it's necessary to call out many of the other requirements specified in the BRs and the Mozilla policy (such as OCSP requirements) - I would suggest this is not a "hole that should be closed" but a "hole that has been closed for a long time". Even before Mozilla required the Baseline Requirements, this was included in previous versions of the Program Requirements. eg: https://wiki.mozilla.org/CA:CertInclusionPolicyV2.0 calls out "ASN.1 DER encoding errors" (as did Version 1.2) Perhaps there should be a broader discussion on .policy.
(In reply to Ryan Sleevi from comment #7) > While I appreciate calling it out - much as, unfortunately, it's necessary > to call out many of the other requirements specified in the BRs and the > Mozilla policy (such as OCSP requirements) - I would suggest this is not a > "hole that should be closed" but a "hole that has been closed for a long > time". > > Perhaps there should be a broader discussion on .policy. Unless I understand you, I think we're all violently agreeing. This isn't the only issue like this we've found and worked around in the mozilla::pkix project--not even the first one regarding basic constraints. Fortunately, this is a rather benign issue and also fortunately the relevant CAs (so far) have been willing and eager to change their cert encoding practices once notified of the problems. We'll try to minimize the number and duration of such workarounds, which is evident by the fact that we always file a follow-up bug for undoing the workaround at the same time we implement the workaround. Even after we've implemented all these workarounds, we should have a decoder that is still stricter than NSS and other implementations.
No longer blocks: mozilla::pkix-beta
Assignee: nobody → kwilson
Product: NSS → mozilla.org
Summary: improperly encoded certificate issued by Go Daddy Secure Certification Authority → Go Daddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority
Version: trunk → other
Component: CA Certificates → CA Certificate Mis-Issuance
Summary: Go Daddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority → GoDaddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority
I'm going to mark this as Resolved/Fixed. The underlying issue - GoDaddy's encoding - has been reported as fixed. The choice of whether or not to deprecate the mozilla::pkix workaround may want to be tracked in a separate bug, but I defer that to keeler.
Status: NEW → RESOLVED
Closed: 2 years ago
QA Contact: gerv
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.