Closed Bug 1605653 Opened 5 years ago Closed 5 years ago

NSS rejects a certificate when the issuer of the certificate and the subject of the CA certificate is caseIgnoreMatch

Categories

(NSS :: Tools, defect)

3.48
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: 13132239506, Unassigned)

Details

Attachments

(1 file)

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.

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.

Ok, can you tell me the standards you follow?

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.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: