Valid cert fails to verify due to different DN encodings
In "lib/x509/verify.c" is_issuer()
uses _gnutls_x509_compare_raw_dn()
but that doesn't account for different text encodings of the DN. We have a CA that has a Subject that looks like this when dumped with openssl asn1parse -i
:
159:d=2 hl=2 l= 91 cons: SEQUENCE
161:d=3 hl=2 l= 33 cons: SET
163:d=4 hl=2 l= 31 cons: SEQUENCE
165:d=5 hl=2 l= 3 prim: OBJECT :organizationName
170:d=5 hl=2 l= 24 prim: PRINTABLESTRING :<censored org>
196:d=3 hl=2 l= 22 cons: SET
198:d=4 hl=2 l= 20 cons: SEQUENCE
200:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
205:d=5 hl=2 l= 13 prim: PRINTABLESTRING :<censored unit>
220:d=3 hl=2 l= 30 cons: SET
222:d=4 hl=2 l= 28 cons: SEQUENCE
224:d=5 hl=2 l= 3 prim: OBJECT :commonName
229:d=5 hl=2 l= 21 prim: PRINTABLESTRING :Certificate Authority
252:d=2 hl=4 l= 338 cons: SEQUENCE
We have a cert that is signed by the CA. It has an Issuer section that looks like this when dumped:
36:d=2 hl=2 l= 91 cons: SEQUENCE
38:d=3 hl=2 l= 33 cons: SET
40:d=4 hl=2 l= 31 cons: SEQUENCE
42:d=5 hl=2 l= 3 prim: OBJECT :organizationName
47:d=5 hl=2 l= 24 prim: UTF8STRING :<censored org>
73:d=3 hl=2 l= 22 cons: SET
75:d=4 hl=2 l= 20 cons: SEQUENCE
77:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
82:d=5 hl=2 l= 13 prim: UTF8STRING :<censored unit>
97:d=3 hl=2 l= 30 cons: SET
99:d=4 hl=2 l= 28 cons: SEQUENCE
101:d=5 hl=2 l= 3 prim: OBJECT :commonName
106:d=5 hl=2 l= 21 prim: UTF8STRING :Certificate Authority
The strings match, but the CA is encoded as PRINTABLESTRING
and the cert uses UTF8STRING
and so the binary DN comparison fails, and the cert doesn't verify. I believe this is incorrect behavior.