crypto/x509: Other Names in x509 Certificate SAN causing certificate verification failure

[chrisbrowning]

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

$ go version
go version go1.13.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOOS="linux"

What did you do?

Attempted to bind to an LDAP Server over 636 w/ TLS

What did you expect to see?

Successful binding

What did you see instead?

LDAP Result Code 200 "Network Error": x509: certificate is not valid for any names, but wanted to match

By debugging I determine that the source of this error is that my LDAP host is serving a certificate without a DNSName in the SAN but with two Other Name elements. These two elements are related to OID 1.3.6.1.5.2.2 (Kerberos/Microsoft NT Principal Name). In this scenario, hasSANExtension() == true which makes commonNameAsHostName() == false. Because of this, the x509's verify function expects to find the hostname in the SAN but cannot, and throws an error. Interestingly, the hostname is parsable from the Microsoft NT Principal Name.

When I look at RFC 6125:

As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
URI-ID, or any application-specific identifier types supported by the
client.

My question is: is there a way to call my own custom middleware or function for hostname verification in support of the above-mentioned "application-specific identifier types" like my Kerberos application? Speaking to the issuer of my certificate, it sounds like I am unlikely to get them to modify the certificate anytime soon.

Any guidance is appreciated. Thank you!

[bcmills]

CC @agl @FiloSottile

[agl]

I think you would want to set InsecureSkipVerify on the tls.Config to disable all certificate checking and then verify it yourself. To do so, you would install a VerifyPeerCertificate callback on the tls.Config, setup a VerifyOptions with the second and subsequent rawCerts certificates as Intermediates, call Verify on the first peer certificate, and then dig around in the Extensions of the that first peer certificate to determine, in an LDAP-specific way, whether the certificate is for the correct host.

Seeing the default verification might be useful to crib from — the thing you need to avoid is configuring a DNSName in the VerifyOptions.

(If @FiloSottile suggests something different, listen to him.)

[gopherbot]

Change https://golang.org/cl/193620 mentions this issue: crypto/tls: add ExampleConfig_VerifyPeerCertificate

[FiloSottile]

Indeed, a custom verifier is your best bet. I just submitted an example to the docs that should help you. https://tip.golang.org/pkg/crypto/tls/#example_Config_verifyPeerCertificate

(The logic ignoring CN is more complex than just letting SAN take priority per RFC 6125, because it interacts with Name Constraints due to our VerifyHostname API only having access to the leaf. #24151)