NSS rejects a certificate when the issuer of the certificate and the subject of the CA certificate is caseIgnoreMatch
Categories
(NSS :: Tools, defect)
Tracking
(Not tracked)
People
(Reporter: 13132239506, Unassigned)
Details
Attachments
(1 file)
20.00 KB,
application/x-tar
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79 Safari/537.36
Steps to reproduce:
I recently created a certificate chain [rootca, intermediate certificate,leaf certificate], the issuer of leaf certificate is "Issuer: ....,, OU = beiyangyuAn, ... ". the subject of intermediate certificate is " ....,,OU = beiyangyuan,.....".
1.Create folder by “mkdir nssdb”
2.Creating NSS database through "certutil - N - d dbm:nssdb"
3.Add certificates (powerca.cert.pem and rootca.cert.pem) to nssdb database by the command "certutil - A - n powerca.cert.pem - t ", , " - i powerca.cert.pem - d nssdb" and the command "certutil - A - n rootca.cert.pem - t "C, C, C" - i rootca.cert.pem - d nssdb"
4. verify the certificate ("leaf.pem") by "vfychain -a -d nssdb leaf.pem"
Actual results:
Chain is bad!
PROBLEM WITH THE CERT CHAIN:
CERT 0. CN=www.qq.com,OU=R&D,O=Shenzhen Tencent Computer Systems Company Limited,L=Shenzhen,ST=Guangdong Sheng,C=CN :
ERROR -8179: Peer's Certificate issuer is not recognized.
E=li1@163.com,CN=b326,OU=beiyangyuAn,O=TJU,ST=TJ5,C=CN
Expected results:
Chain is good!
According to Section7.1, RFC5280: "Conforming implementations MUST support name comparisons using caseIgnoreMatch". The powerca.cert.pem(intermediate certificate) should be the issuer certificate of leaf certificate. But Nss can not find issuer. Clearly, Nss violates Section 7.1.
Comment 1•5 years ago
|
||
Pretty sure this is WontFix/WAI.
NSS doesn’t assert compliance with RFC 5280, and the CA issuing such certificates is also violating 5280.
https://tools.ietf.org/html/rfc5280#section-8
CAs MUST encode the distinguished name in the subject field of a CA
certificate identically to the distinguished name in the issuer field
in certificates issued by that CA. If CAs use different encodings,
implementations might fail to recognize name chains for paths that
include this certificate. As a consequence, valid paths could be
rejected.
Reporter | ||
Comment 2•5 years ago
|
||
Ok, can you tell me the standards you follow?
Comment 3•5 years ago
|
||
To my knowledge there isn't a defined standard that covers all the corner cases of the Web with the thoroughness of a specification, but as Ryan said in Comment 1, this is as intended, and as 5280 specifies.
Description
•