Bug 44312 - subjectAltName must be set as browsers remove support for CN fallback
subjectAltName must be set as browsers remove support for CN fallback
Product: UCS
Classification: Unclassified
Component: SSL
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.2
Assigned To: Philipp Hahn
UCS maintainers
: 44514 (view as bug list)
Depends on:
Blocks: 44515
  Show dependency treegraph
Reported: 2017-04-06 17:55 CEST by Moritz Bunkus
Modified: 2017-05-02 16:18 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 4: Will affect most installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Bunkus 2017-04-06 17:55:39 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:


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
Comment 1 Moritz Bunkus 2017-04-07 08:30:06 CEST
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."
Comment 2 Michael Grandjean univentionstaff 2017-04-07 09:54:25 CEST
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 ...)
Comment 3 Philipp Hahn univentionstaff 2017-04-07 10:22:59 CEST
# 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".
Comment 4 Moritz Bunkus 2017-04-07 12:04:04 CEST
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
Comment 5 Daniel Tröder univentionstaff 2017-05-02 16:12:12 CEST
*** Bug 44514 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Tröder univentionstaff 2017-05-02 16:18:10 CEST
More customers are hitting this problem, so I created an urgent documentation/SDB bug: Bug #44515.