cc @FiloSottile

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Generally this sounds good. What's the proposed API? An error wrapper type for certificate validation failure that includes the peer certificates? Should it also be raise on a failed VerifyPeerCertificates or VerifyConnection?

How is this different from #48151 and why does that issue say "it's done wrong for client certificates"? We could generally use a more detailed "what did you do" / "what did you expect" / "what did you see".

Ping @ptagrawal for answers to @FiloSottile's questions.

ping @ptagrawal

An error wrapper type for certificate validation failure that includes the peer certificates?
Yes, because, this would help debug what certs were presented while trying to make the connection.

Should it also be raise on a failed VerifyPeerCertificates or VerifyConnection?
Not sure about this, but I believe, if VerifyPeerCertificate is set, its upto up to parse and verify the certificate which I guess, we could anyways do in case of an error. So, maybe not required.

How is this different from #48151 and why does that issue say "it's done wrong for client certificates"?
So, I mentioned that because, looking at the logs I couldn't find the cert in the err.Error() where as the string preceeding that called out "failed to verify client certificate". I hoped the returned error would contain the certificate that was presented.

It sounds like the answer is to suggest a new error wrapper type that will hold the certificates and be returned on validation failure?

Alternately, is it possible to get this info using a custom VerifyPeerCertificates? Or is there no way to invoke the usual code in that case?

/cc @golang/security

You can do it with VerifyConnection/VerifyPeerCertificates, although you have to maintain some state at a higher lexical scope and it's kind of hard to associate a VerifyConnection/VerifyPeerCertificates invocation with an error returned by Handshake.

Assuming it's possible to unwrap the Handshake return value to get an error as returned by VerifyConnection/VerifyPeerCertificates, one can implement the certificate check there and return a wrapped error.

Still, setting InsecureSkipVerify to bypass the normal checks, then reimplementing them just to return an error wrapper to get access to the certificates is quite burdensome.

I wouldn't be opposed to a new error wrapper with an UnverifiedCertificates field, that can be accessed with errors.As.

It sounds like we need an API, then, specifically a name for the error.

type UnverifiedCertificatesError struct {
    UnverifiedCertificates []*x509.Certificate
}

func (e *UnverifiedCertificatesError) Error() string { ... }

Is this the API?

Maybe the error name is CertificateVerificationError?

OK, so it sounds like:

type CertificateVerificationError struct {
    UnverifiedCertificates []*x509.Certificate
}

func (e * CertificateVerificationError) Error() string { ... }

Does anyone object to that API?

Does anyone object to the API in the preceding comment?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

CC @golang/security

Looks like this didn't make 1.19. Moving to backlog. Please recategorize as appropriate. Thanks.

Change https://go.dev/cl/449336 mentions this issue: crypto/tls: add CertificateVerificationError to tls handshake

Hi there,

I realized that calls to net/http2.readFrameHeader may end up returning an error due to a bad certificate, that's modelled with a tls.permanentError, that holds a net.OpError that internally points to an alertBadCertificate.

So, I'm wondering whether or not, now that we have the CertificateVerificationError in place, would make sense to use it in such cases in order to let consumers know the reason why it failed. Or perhaps expose it through a similar but different error?

I'd be happy to open an issue with all the details, but first I wanted to know your opinion, as I see it very tight to this issue, as it just looks as the same/very similar situation may arise from different code locations.

cc/ @FiloSottile

Thanks!