Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: unexpected name mismatch error #31440

sneis opened this Issue Apr 12, 2019 · 3 comments


None yet
2 participants
Copy link

sneis commented Apr 12, 2019

What version of Go are you using (go version)?

Sorry, I'm not actually using Go itself, but I'm using etcd (; apparently written in go) and got an error about subject and issuer names not matching in my certificate chain, which I believe can be tracked down to go's crypto/x509 implementation.

What did you do?

I tried to verify a certificate chain, where the Issuer DN of sub-CA certificate was specified using the ASN.1 type UTF8String, while the subject DN of the (renewed) CA certificate used PRINTABLESTRING.

What did you expect to see?

RFC 5280 (dated May 2008), section 7.1 says:
RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however, this specification requires a more comprehensive handling of comparison.
And then it goes on to give details on how to compare DN's and then refers to RFC 4518 on how to compare strings of different ASN.1 types. To me, this sounds like at least comparing the exact same ASCII string when encoded as PRINTABLESTRING in one instance and as UTF8STRING in the other still should result in recognizing the two string as equal and thus the certificate chain should be validated successfully (as is the case e.g. for OpenSSL).

What did you see instead?

I got a name mismatch, just as if the ASN.1 encoding of the DN's would be "blindly" compared byte by byte as described by the outdated RFC 3280 (crypto/x509/verify.go:570 seems to indicate that this actually is the case). Of course, for now, there's the obvious workaround of ensuring the ASN.1 encodings of DN's are identical, but in the long run, that shouldn't be necessary (and if you're switching to a different software (version) for generating certificates, ensuring continuing compatibility might not be trivial).


This comment has been minimized.

Copy link

bcmills commented Apr 12, 2019


This comment has been minimized.

Copy link

bcmills commented Apr 12, 2019

Could you give some concrete examples of certificate chains that exhibit this problem? (Are the certificates in question published publicly?)


This comment has been minimized.

Copy link

sneis commented Apr 13, 2019

I did a quick attempt at creating a set of suitable dummy certfificates (Basically create a dummy Root with openSSL, create a certificate signed by that root, change the string type defined in openssl.cnf from "utf8only" to "default", refresh the root certificate with one with longer validity). If you unzip the attached, using OpenSSl, both
openssl verify -verbose -CAfile cacert.pem subcacert.pem
openssl verify -verbose -CAfile cacert-new.pem subcacert.pem
successfully verify the certificate in subcacert.pem, while I claim that with the routines from crypto/x509 subcacert.pem can only be validated against cacert.pem while validation against cacert-new.pem is going to fail.

@bcmills bcmills removed the WaitingForInfo label Apr 13, 2019

@bcmills bcmills added this to the Go1.13 milestone Apr 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.