Menu
I'm using the ClientCAs and ClientAuth options in tls.Config to do cert-based client authentication in my Go HTTP application. Is it possible to also verify the client certs against a provided CRL? I see in the x509 package there are some functions around CRLs, but I'm not sure how to configure the HTTP server to use them (ie. there doesn't seem to be any options in tls.Config that would cause a CRL to also be used).
939
Unfortunately, even though Golang has native support for TLS, it has extremely limited support for OCSP and CRL. OCSP and CRL provide a way to verify whether the TLS certificate was revoked by CA before the application establishes secure communication with a service that uses this certificate.
Open a certificate you want to check against and go to the Details tab and scroll down to the CRL Distribution Points. Here you will see the URL of the web server hosting the CRL. You can copy out the full URL including the .crl file details. If you paste the URL into a broswer, this will download the CRL file.
We have two whitepapers about CRL troubleshooting: Certutil.exe is the command-line tool to verify certificates and CRLs. To get reliable verification results, you must use certutil.exe because the Certificate MMC Snap-In does not verify the CRL of certificates.
CRL stands for Certificate Revocation List and is one way to validate a certificate status. It is an alternative to the OCSP, Online Certificate Status Protocol. You can read more about CRL's on Wikipedia. If you want to validate a certificate against an OCSP, see my article on that here.
Is it possible to also verify the client certs against a provided CRL?
Yes, it is possible, by means of the functionality provided in the crypto/x509 package (as you correctly stated in your question). However, higher-level interfaces such as crypto/tls.Config (consumed by net/http) do not offer that. A good chance to implement a check against a CRL probably is by inspecting net/http.Request.TLS.PeerCertificates.
A little bit of background: crypto/tls is maintained by security expert Adam Langley who has an opinion on revocation checking (original source is his blog). Though I have no evidence, one might assume that this was a deliberate design decision.
71
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
