0

I generate TLS certificates and sign them using a self-signed CA.

There are numerous small errors that can happen in this process and cause the certificate to get rejected. Browser seem to serve very opaque errors, which give some generic TLS error code (or worse, just "this site is under attack!") with no explanation of what exactly is wrong with the certificate chain.

Also, TLS has evolved over time, and many features that are supported by TLS software and were commonplace a few years ago are now considered insecure and not used. It is hard to keep track of these.

In a Unix/Linux environment, is there a way to test a TLS certificate to quickly figure out if it's generally in agreement with modern standards and if not, see where exactly the problem is?

Bagalaw
  • 945
  • I would use something like this "openssl x509 -in cert.cer -noout -text -CA ca.cer" – admstg Nov 13 '23 at 18:09
  • How about testssl.sh? – garethTheRed Nov 13 '23 at 18:11
  • 2
    All CAs have root certificates that are self-signed. – Andrew Henle Nov 13 '23 at 18:13
  • 1
    @admstg: that doesn't do any checking at all. openssl verify -CAfile ca.cer child.cer does check the signature, BC and KU (if present), and if you add options revocation (CRL only), 'purpose' (EKU), policy and identity, but not all the rules browsers use; for example both Chrome/Edge and Firefox now require SAN, but openssl still allows subject.CN. – dave_thompson_085 Nov 14 '23 at 02:42

1 Answers1

0

zlint and cablint seem to be popular tools for checking certificate consistency with the CA/Browser Forum baseline requirements. (I haven't used them personally.)

Keep in mind that internally managed CAs are not subject to the same requirements as WebPKI CAs are – browsers know the difference and do not enforce e.g. the SAN requirement (at least as far as I know).

I wouldn't start with the various browser-specific policy until I have verified that the underlying TLS library accepts the certificate. That is, given a configured TLS server, I'd first try to gnutls-cli <host>:<port> and see what GnuTLS says about it and the entire chain; then the same with openssl s_client (the -servername and -verify_hostname … options are needed).

u1686_grawity
  • 5,858
  • Thank you for the response. This is enough to get me going - I'll mark accepted once I have a chance to test it on my end. But for less technical people who will read this in the future, would you like to add some example commands that they can copy/paste? – Bagalaw Nov 15 '23 at 23:24
  • And speaking of future readers, there's also https://wiki.mozilla.org/CA:TestErrors – Bagalaw Nov 15 '23 at 23:25
  • Chrome/ium and FF do require SAN on DIY CAs -- there are numerous Qs on several Stacks "why my self-made web certs fail? no SAN" -- but not transparency, revocation info, and (at least sometimes?) keysize and hashalg. And no brower uses either OpenSSL or GnuTLS, unless you count lynx. But openssl s_client only needed explicit -servername below 1.1.1 (released 2018, EOL upstream 2 months ago) -- except if you need to override name resolution a la -connect $ipaddr:$port -servername $dnsname – dave_thompson_085 Nov 16 '23 at 01:25