11-15-2018 01:58 AM - edited 03-19-2019 01:36 PM
I have hit somewhat of a wall...
More and more, Google Chrome (or rather Chromium, but Chrome behaves the same) is used internally to administer our systems.
But, for some stupid reason, Chrome does not accept the certificates that are installed on our various Callmanager and Unity Clusters, with the error message NET::ERR_CERT_COMMON_NAME_INVALID
Internet Explorer accepts those certificates just fine.
I found a couple of issues that Chrome has:
Chrome always converts entered URLs to lower case, but with certificates, capitalization seems to matter.
According to some info I found, Chrome supposedly ignores the CN and looks at the SANs instead. Our certificate guy was successfully able to add SANs to the requests that CUCM generates.
The capitalization seems to really matter, since our Hostnames are capitalized (HOSTNAME) and the Domain is CamelCase (DomainName.net)
I was able to get certificates for single server systems to get to work, by adding the lower-case FQDN and hostname as SANs:
DNS Name=HOSTNAME.DomainName.net
DNS Name=hostname.domainname.net
DNS Name=HOSTNAME
DNS Name=hostname
Common Name of that certificate is HOSTNAME.DomainName.net
Without the lower case SANs, i get Common Name Invalid in Chrome. *grumble*
But for Multi-SAN certificates that alone does not work.
Example:
CN: PUBLISHER.DomainName.net-ms
SANs, all DNS Name:
PUBLISHER.DomainName.net-ms
DomainName.net
PUBLISHER.DomainName.net
publisher.domainname.net
SUBSCRIBER1.DomainName.net
subscriber1.domainname.net
SUBSCRIBER2.DomainName.net
subscriber2.domainname.net
PUBLISHER
SUBSCRIBER1
SUBSCRIBER2
publisher
subscriber1
subscriber2
That certificate is not accepted by Chrome regardless of whether i use just the hostname or the FQDN to access the server.
If it is relevant, some general Information:
Callmanager/Unity Versions: 10.5.2.x
Chromium Version: 68.0.3440.134
All certificates are SHA256
Certificates are signed by our own internal CA, Root and Intermediate certificates are properly installed on the servers and clients.
Internet Explorer accepts all these certificates without problems.
12-03-2018 06:20 AM
Hmm, no one has this issue, or no one cares about certificate warnings?
I would like to have proper certificates for the user facing site...
12-03-2018 09:20 PM
12-04-2018 02:18 AM
That is how the certificates have been created, except for the in-between step where our certificate guy added the SANs.
The SANs are added for these reasons:
- So that we do not always have to type the FQDN
- Chrome always converts entered URLs to lower-case. Our hostnames, and therefore the pre-populated CN and SANs are uppercase. This should not matter, but tests I did confirm that it really does.
- CSRs for standalone server do not contain any SANs
I have gotten this to work on one of our single server systems, but not on any of our clusters.
The working certificate for a single server looks as follows:
CN: HOSTNAME.DomainName.net
SANs, all DNS Name:
HOSTNAME.DomainName.net
DomainName.net
hostname
HOSTNAME
hostname.domainname.net
This certificate works for just the hostname, and also for the FQDN.
The CA structure itself works, it is used for essentially everything certificate based in our company. If that would not work, nothing would work here ;)
Also, all these certificates that chrome rejects are accepted by Internet Explorer just fine. Not in Firefox, but that is because it does not use the Windows certificate store by default.
I hope there is a way to get a working cluster certificate, i do not really want to issue single server certificates for all nodes separately.
12-04-2018 07:27 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide