Univention Bugzilla – Bug 44312
subjectAltName must be set as browsers remove support for CN fallback
Last modified: 2022-03-30 19:56:57 CEST
Currently univention-ssl creates certificates without an "subject alternative name" extension. The server's name is only stored in the "common name" attribute. Unfortunately browsers seem to start to remove support for matching the requested host name against the certificate's "common name" attribute. See this Chrome/Chromium bug discussion: https://bugs.chromium.org/p/chromium/issues/detail?id=700595&desc=2 The result is that Chrome treats connections to a site secured by such a certificate without the "subject alternative name" extension as insecure — the same as if the requested host name doesn't match the name stored in the certificate. I've just run into this with Google Chrome 58.0.3029.54 beta (64-bit) when connecting to our internal UCS servers. Therefore univention-ssl should add the "subject alternative name" extension for all newly created certificates. Should be easy enough to adjust openssl.cnf for each certificate, e.g. [ ucsCA_ext ] basicConstraints = CA:FALSE # keyUsage = cRLSign, keyCertSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always subjectAltName = DNS:proxima-imm.bs.linet-services.de
Just to be clear: this happens in situations where earlier versions of Google Chrome show a green lock, "evertying's secure" situation: - The host name in the URL is the same one as the "common name" in the certificate. - The UCS CA certificate's been imported into the browser's "trusted authorities" store (or similarly named stores in the browser or the OS) According to the discussion[1] the motivation is that RFC 2818[2] "HTTP over TLS" deprecated checking against the "common name" over ten years ago. Certificates should _really_ include a SAN nowadays. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=308330 [2] https://tools.ietf.org/html/rfc2818 ; see section 3.1: "If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."
This is still true for 4.2, so I'm going to adjust the "Version" tag of this bug. We do have an extension script for "univention-certificate" that does add a SAN: > /usr/share/doc/univention-ssl/extensions-example.sh This script is not used by default and must be activated via > ucr set ssl/host/extensions="/usr/share/doc/univention-ssl/extensions-example.sh" However, this is only a workaround (and not very well documented). I also strongly recommend to add subjectAltName to the default "openssl.cnf". Chrome is usually just the forerunner and other Browser will likely follow. AFAICS the affected Chromium Version 58 will become stable by Apr 25th, 2017 → https://www.chromium.org/developers/calendar Of course this will affect also all Browsers based on Chromium (Google Chrome, Vivaldi, Brave, Iridium ...)
# grep "$HOSTNAME" "/etc/univention/ssl/$HOSTNAME/openssl.cnf" CN = master42.phahn.qa subjectAltName = DNS:master42.phahn.qa, DNS:master42 # openssl x509 -noout -in /etc/univention/ssl/$HOSTNAME/cert.pem -text -certopt no_header,no_version,no_serial,no_signame,no_validity,no_issuer,no_pubkey,no_sigdump | grep -A1 'X509v3 Subject Alternative Name:' X509v3 Subject Alternative Name: DNS:master42.phahn.qa, DNS:master42 UCS is using "X509v3 Subject Alternative Name" since Bug #38859 (UCS-4.1-0). The problem might be that you initially creates your certificates with an older UCS system: The "openssl.cnf" file plus the public/private keys are generated the first time a certificate for the host is requested; they never get updates afterwards is you use "univention-ssl renew", so you don't get the benefit from UCS-4.1. (it also re-uses the once creates public and private keys.) If you use "univention-ssl new" instead, you will get a new public/private key plus a new certificate with updated settings, especially the "subjectAltName".
That's good to know, thanks. And you're right. Recently created certificates on our DC Master do contain both subjectAltName entries. You've said that renewing existing certificates won't add the SANs as the openssl.cnf isn't recreated in that case. This also means that the SDB articles about certificate renewal (both for single ones and for the whole chain[1]) won't help either. Univention should provide an SDB entry for people who actually want to fix their existing certificates. Personally I do know how to script adding SANs to all existing openssl.cnf files and renewing them afterwards, but an SDB entry would be nice for those who aren't as comfortable with scripting. [1] http://sdb.univention.de/1183
*** Bug 44514 has been marked as a duplicate of this bug. ***
More customers are hitting this problem, so I created an urgent documentation/SDB bug: Bug #44515.