We run an internal Certificate Authority powered by an Ubuntu 16.04 server and an OpenSSL backend for internal resources, on a mixed Windows / Linux environment.

This CA is used with some internal websites in an attempt to provide valid, trusted site certificates for internal websites, software deployments, etc. We have one problem.

The CA Root certificate is pushed to all our Windows systems by GPO, or were manually installed. However, every certificate signed by that CA ends up giving some problems - Chrome and Firefox both indicate that the certificate has an invalid common name, while other utilities such as an XMPP server here can't validate the certificate even if the CA cert is in the trust stores.

Only Internet Explorer respects the certificate. Unfortunately, we are a Chrome and Firefox house, so using IE for everything is going to be a problem.

Has anyone figured out a solution to make an OpenSSL CA cert and its signed certificates for issued certs not have an "Invalid Common Name" error on Chrome and Firefox, and thus permit internal certificates to be seen as 'valid'?

What happens when you open the certificates mmc snap-in on the computer and view the installed certificates. Does it show a valid chain? Have you looked at the details of the certificate presented in the browser? A single screenshot would’ve said a million words here, but you’ve left us guessing. It’s quite simple to find out why a certificate is treated as invalid or not. Firefox won’t honor the Windows certificate store, so they have to be trusted manually just in case that comes up too. Firefox pretty much doesn’t belong in an enterprise because of this.
– AppleoddityDec 22 '17 at 15:09

@Appleoddity I actually solved the issue, thanks to an SO post, and me dissecting the certificate in OpenSSL (unlike the rest of the company, I am almost 100% a Linux guy, so I use OpenSSL command line to dissect certs). Turns out OpenSSL wasn't respecting the requested v3 extensions, and therefore wasn't adding the SANs to the cert. Solved it though, and posted an answer below.
– Thomas WardDec 22 '17 at 15:25

@Appleoddity to answer your question, though, the root CA cert and the certificate in question both show as "Valid" according to Windows, and IExplore showing everything also seems to show everything as "valid" and trusted, so it started me thinking about what was actually going on from the CA side - this led me to my own discoveries and my answer.
– Thomas WardDec 22 '17 at 15:31

1 Answer
1

I actually figured out the core problem, and it took a ton of searching. Finally found an answer over on StackOverflow, which combined with my investigation into the actual data on the certificate itself with openssl req -text -noout -verify -in CSR.csr to read the data in the CSR, and openssl x509 -in certificate.crt -text -noout to dissect the generated certificate and comparing these two, pointed at the core problem.

Apparently, OpenSSL was ignoring the section of our conrfiguration file relating to the V3 extensions, and doesn't do the v3 extensions unless you tell it to properly in the actual CA signature step...

This was the configuration file data being passed into the openssl req command:

... and when signing the certificate with the CA, we had to use something like this, executing this from where we had all the site certs stored (including the CSR and key, for generating the cert in the first place - the CA certificates and keys are in a separate /certauthority/... section on our system):

This command properly put the v3 extensions into the certificate, and somehow ignored the actual extensions in the file otherwise. This in turn solved the CN and SAN issues, and now the system returns the certificate as "valid" for internal sites and (most) internal services.