Enterprise CA certs are untrusted

Question

Hello,

Windows 2012r2, single domain, new 2-tier PKI infrastructure, with sub-CA being Enterprise CA for the domain, just setup. PKIView and MMC Cert Auth both show a 'green board' (no alerts, issues, or errors). All services start and all logs are clear. SHA512 was used, no SHA1 anywhere. Offline Root cert is 4096 so it 'lasts longer' as it were.

Certificates are published in AD.

My host Windows 10 shows the root cert in "Trusted Root Certificate Authorities" and the sub-CA (cert issuing CA) certificate in "Intermediate Certificate Authorities". In fact, BOTH the offline root and the sub-CA certs are in the 'Intermediate Certificate Authority" containers (is that an issue? ....not sure how it occurred ..)

I have a CentOS based web server that runs my helpdesk software. I used openssl to generate a CSR, and used the certutil applet to issue the cert from the sub-CA using the WebServer template. Quick reconfig of Apache and now the cert is properly 'attached' to the website. All DNS has been checked, the site and the cert are properly setup as far as we can see. Also, time is correct on all servers and hosts.

The issue is that Edge and Firefox both show the cert as 'untrusted' and give the full 'They are stealing your face!' warnings. Strangely though, if you dig deeper in and display the certificate, it shows the proper chain with no red or alert markings and also claims 'This certificate is OK' for each. So the certificates are OK, but they are being refused anyway?

I am stumped as to why these "OK" certificates are not being trusted. Any help would be greatly appreciated!

FPChum

Answer 1

But it also 'seems' to say that, by default, my Windows 2012R2 CA won't use the SAN names in a CSR, that instead I have to add using the certutil command?

who said that? If SAN extension is included in CSR, CA will include this SAN extension into signed certificate.

The question now seems to be can I generate a CSR with SAN names, submit that via the MMC and get a 'proper' certificate back

here is my blog post on how to do this using MMC: https://www.sysadmins.lv/blog-en/web-server-certificate-enrollment-with-san-extension.aspx

even though they are in the CSR

it is unlikely that you have SAN extension in request, hence why you don't have SAN in issued certificate.

Answer 2

Crypt32,

Thanks again for your help. SAN was indeed the issue, I was too 'old skool' in my approach, unaware that the 'old rule' that the commonName must match the FQDN has been superseded by the SAN field needing to have the FQDN. I re-created the CSR and issued a 'proper' cert with both the IP and DNS in the SAN field and all is well.

I appreciate your efforts and answers!

FPChum