Closed
Bug 988633
Opened 10 years ago
Closed 7 years ago
GoDaddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: keeler, Assigned: kwilson)
References
(Blocks 1 open bug)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Attachments
(1 file)
2.09 KB,
application/octet-stream
|
Details |
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.
Reporter | ||
Updated•10 years ago
|
Blocks: mozilla::pkix-beta
Comment 1•10 years ago
|
||
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
Comment 2•10 years ago
|
||
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.
Comment 3•10 years ago
|
||
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?
Reporter | ||
Comment 4•10 years ago
|
||
Right - this will be a considerable compatibility issue. We'll have to do something like with bug 985021 / bug 985025.
Reporter | ||
Comment 5•10 years ago
|
||
See bug 989516 and bug 989518 for the mozilla::pkix work. This bug will track communications and decisions with Go Daddy.
Assignee | ||
Comment 6•10 years ago
|
||
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
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
(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.
Reporter | ||
Updated•10 years ago
|
Blocks: mozilla::pkix-CAs
Reporter | ||
Updated•10 years ago
|
No longer blocks: mozilla::pkix-beta
Assignee | ||
Updated•7 years ago
|
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
Whiteboard: [ca-compliance]
Version: trunk → other
Assignee | ||
Updated•7 years ago
|
Component: CA Certificates → CA Certificate Mis-Issuance
Updated•7 years ago
|
Summary: Go Daddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority → GoDaddy: improperly encoded certificate issued by Go Daddy Secure Certification Authority
Updated•7 years ago
|
Product: mozilla.org → NSS
Comment 9•7 years ago
|
||
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: 7 years ago
QA Contact: gerv
Resolution: --- → FIXED
Updated•1 year ago
|
Product: NSS → CA Program
Updated•1 year ago
|
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in
before you can comment on or make changes to this bug.
Description
•