This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(156.8, 43%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES%3C/text%3E%3C/svg%3E)
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
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.
It would be useful if you would show exact error message from web browser.
However, I suspect that the problem is with certificate name: missing Subject Alternative Names (SAN) extension. The certificate itself and its chain may be fully valid (according to RFC 5280 validation rules), however, web browsers perform additional checking: if any of "dnsName" names in SAN extension matches the host address entered in browser's address bar. If there is no matching entry or SAN extension is missing, then certificate is not valid for specified web address, hence the error. I guess that you have proper address in Subject field, but it is ignored by browsers completely.
Crypt32.
Thanks for your assistance.
The error is "SEC_ERROR_UNKOWN_ISSUER". The common name on the cert is 'helpdesk.mydomain.local" and the URL beingvisited is "helpdesk.mydomain.local/itop/pages/login.php",
Hope that helps.
Regards,
FPChum
Some more info now that I've turned errors for the site back on:
"This server couldn't prove that it's helpdesk.mydomain.local; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection."
The certificate request was created using openssl. I saw no area to define SAN entries. Additionally, the server is not know by any alternate names, nor is there more than the one site on the server....
This seems an area where the browsers are requiring something that isn't in my environment? The FQDN of the server matches the 'common name' on the certificate exactly but that's not good enough anymore, I MUST have a SAN entry for a SAN that doesn't exist? WTF, over? It seems like a need a SAN name that is the same as the FQDN of the server? The site isn't known by any other name....
I appreciate all input, thanks again!!
FPChum
"This server couldn't prove that it's helpdesk.mydomain.local; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection."
That's exactly what I said in my first response. You have missing SAN extension which is required. No matter what is set in Subject field.
This seems an area where the browsers are requiring something that isn't in my environment?
they require a Subject Alternative Names extension with DNS Name=helpdesk.mydomain.local value.
The site isn't known by any other name....
doesn't matter. Browser no longer even look at Subject field, it is deprecated like 20 years already. You need to update configuration file for OpenSSL and include your web site's host address into it.
So, my continued reading on this says I must indeed duplicate the common name in the SAN field, common names are no longer used at all and in fact can be anything including blank nowadays (which is way different from the last time I setup a web site with SSL!) .
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?
If someone can shed more/better light on this I would greatly appreciate it. I can certainly to the trial-and-error thing but that just leads to 37 revoked certificates, so hopefully someone can assist me here before i have to go that route.
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 or do I have to use the certutil command and 'force' the server to add the SAN values even though they are in the CSR? If I have to force the values, I don't need them in the CSR then do I?
Thanks again!
FPChum