Java, I’m looking at you (though Chrome will get glared at as well).
The most tedious TLS rabbit holes are the ones that relate to inconsistencies between TLS clients. A certificate will work in most cases, and then one client will fail, and then down the rabbit hole you go, waving to a Cheshire cat along the way.
A quick diversion.
For example: Chrome/Chromium (since v58) does not support certificates without Subject Alternative Names (SANs). If your web server’s DNS record is in the Common Name, but you have no SAN as well, Chrome will generate
RFC6125 states clients ‘MAY as a last resort check’ the Common Name. It also states no client should check the common name if there are SANs present, so Chrome’s decision to do this had/has the effect of deprecating use of the Common Name. Other browsers, eg Firefox, are happy to use Common Name.
Version 3 extensions in version 1 certificates.
Another tedious thing in general is error messages that are almost entirely useless.
Error obtaining access token. Cannot access https://server.example.com from Jira.
I expected TLS issues, as it’s a private CA. The means, for Jira, adding the root CA to the JDK’s
cacerts trust store. In practice, I copied the original trust store, added the root to the copy, and directed the JDK to the modified one with
I proved with curl that there’s no basic connectivity issue, and then I upped my game to use the ‘right’ client:
$ /opt/java/openjdk/bin/java -Djavax.net.ssl.trustStore=./cacerts SSLPoke server.example.com 443 java.security.cert.CertificateParsingException: no more data allowed for version 1 certificate at java.base/sun.security.x509.X509CertInfo.parse(X509CertInfo.java:679) at java.base/sun.security.x509.X509CertInfo.(X509CertInfo.java:169) at java.base/sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1842) at java.base/sun.security.x509.X509CertImpl.(X509CertImpl.java:194) [snip]
(Atlassian have a copy of the class linked off their knowledge base)
The problem, thank $deity, is in the server certificate, and not the root.
$ openssl s_client -connect server.example.com:443 2>/dev/null | openssl x509 -noout -text Certificate: Data: Version: 1 (0x0) [snip] X509v3 extensions: X509v3 Subject Alternative Name:
SANs are not a version 1 feature. But Java is the first client I’ve encountered that cared.
My CA is Openssl based. I saw a comment on stack overflow or somewhere that the internet has instructions for how to do Openssl CAs wrong in this particular way.
I seem to have the fix already, somewhere ..
$ openssl x509 -noout -text -in root.cert.pem Certificate: Data: Version: 3 (0x2) [snip]
The theory states that if openssl is properly instructed to put v3 extensions in certificates, it’ll make v3 certificates.
My CA has an Openssl configuration, and the key parameter is:
[ ca ] default_ca = CA_default [ CA_default ] [snip] copy_extensions = copy
This is the same as putting
copy_extensions in the
ca section, and from the comments I know I added it specifically because SANs were not being added.
It seems that there was a bug for a while in openssl, and RHEL7’s openssl has it, still.
$ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017
The workaround is to make it explicit that V3 extensions are being added by adding an additional parameter and a dummy section.
copy_extensions = copy x509_extensions = cert_ext [ cert_ext ] [ policy_strict ]
$ openssl x509 -text -noout -in server.example.com.cert.pem Certificate: Data: Version: 3 (0x2) [snip]
Error! Failed adding the account: [Error retrieving list of repositories]
One rabbit hole down .. another to go.