Is it safe to verify client certificate in ServeHTTP and ignore bad client certificate?

Question

In my app based on Go HTTPS server, I set ClientAuth to RequestClientCert in tls.Config, then in the first call to my ServeHTTP function I call Verify on a client certificate chain taking it from PeerCertificates and save result in the structure created in ConnContext and passed as a context value to the ServeHTTP handler, so that further calls to ServeHTTP reuse the result without reverification.

For me as a newbie in Go, it seems to be an easiest way to implement mTLS. Besides, instead of just dropping connection, I can make an error response to a client saying what's wrong with its certificate, or that its access rights have been revoked. I can write a log message containing both certificate info, client IP and URL it tried to access. I can also give some basic access to clients that have no certificate or whose certificates are not good any more. I also would like to limit some certificates to specific IP ranges. Since VerifyPeerCertificates and VerifyConnection seem to give not much tools for guessing client IP and saving access rights, and spreading authentication code over severeal function does not look like a good idea to me, I decided to do everything in ServeHTTP handler.

Am I doing everything right? Are there any security issues in such an approach?

Answer 1

While proper validation of the server certificate is needed to protect the TLS connection against man in the middle attacks, the client certificate is not used in protecting the TLS connection and transferred data.

Therefore it is fine to not verify the client certificate during the TLS handshake, but complete the TLS handshake no matter if the client certificate is valid. As correctly proposed in the question - this way it is possible to provide more informative responses to the client instead of just breaking the TLS connection.

Of course the certificate should be properly validated before using it to identify the client.