Internal Website - SSL Certificate and CNAME Record Issues (Problem with this website's security certificate)


I have an application server running Windows Server 2012 R2 with IIS ver. 8.5 installed. I have an internal website (Intranet) running and it is accessible by "", it is using a self signed SSL certificate (Signed by itself a.k.a. "").

I have setup a CNAME record on our DNS server to point to the web server: "Cool Website Name" ---> ""

The issue is I get an error when connecting to the website via the CNAME alias (Error attached below) -- Https://<cool website name>
-It states that the security certificate presented by this website was issued for a different websites address

My question is how can I secure this website with https while still accessing it via a CNAME record? There are requirements for the website to be renamed so that users do not need to navigate to "". However, when they do this they have to click 'accept' or 'continue to this website' when the error pops up.

Clearly it's not hard to click accept to that error message but in terms of user security I don't want to teach the thought that when this error message appears its ok to click.... because that would be false if they are on the internet. Management wants that error away.

Is there any way to achieve this maybe using an Enterprise CA (Active Directory Certificate Services) or some other method? Can any IIS/Intranet experts advise how to achieve this?

Any help is appreciated. Thanks!

-Admin in need
Who is Participating?

Improve company productivity with a Business Account.Sign Up

leshad82Connect With a Mentor Author Commented:

Thanks to the both of you for the suggestions and assistance! I ended up resolving this using powershell commands to create a self signed certificate with the DNS name I required.

•New-SelfSignedCertificate -DnsName <NAME> -CertStoreLocation cert:\LocalMachine\My

This created the self-signed certificate based on the CNAME record and appears in the 'Personal' cert store and within IIS 8.5 "Server Certificates". I then proceeded to create a binding using the new certificate.

The next steps were to export the certificate and private key and deploy this certificate to all domain workstations trusted root CA cert store via group policy object.

•mmc.exe --> Add/Remove snap-ins --> Add 'Certificates' --> Personal --> Right click <CERT NAME> --> Export --> Insert password, name the file and save it to a location to copy to domain controller.

•New GPO --> Computer Configuration --> Policies --> Windows Settings --> Security Settings --> Public Key Policies --> Trusted Root Certification Authorities --> "Import"

David Johnson, CD, MVPConnect With a Mentor OwnerCommented:
the certificate is probably issued to servername which does not equal servername.domain.ext

Setting up an internal CA can fix it as long as the subject name is correct, but you will have to distribute the root ca and any subordinate ca's certificate to the trusted root providers (usually done by group policy) to all computers or you will get the certificate was issued by a server that is not in your trusted root providers store.

Setting up a proper CA is not a click, click, next, finish operation.  read the technet documentation first or hire someone to setup your CA. Many people forget to create the capolicy.inf first
Even if there's not a name mismatch on the cert (which there apparently is at the moment), your users' machines still aren't going to trust it, because it's self-signed. So they're going to get a cert warning anyway; it'll just say that the cert wasn't issued by a trusted authority. Have a user browse to now, rather than the other name, and this is likely what you'll see.

As David says above, yes, installing an internal CA can fix this, but it's not a trivial task. If you don't have many users, you can manually import the cert on their machines, and you'll be good to go. If there are a lot of users, though, you may be better off springing for a cert from a trusted public CA.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

leshad82Author Commented:

You are correct the self-signed certificate is issued to "" and I created a CNAME record so that https://SITEALIAS points to "".

This alias does indeed work however the mismatch cert error comes up no matter if you install the cert to the trusted root CA folder.

So what your saying is that I need to do the below steps?

•Install Active Directory Certificate Services (ADCS)
•Install the Root CA certificate to the trusted root CA folder via GPO for all client workstations
•Generate a certficate for "" from the internal CA and put the alias on the "Subject name" area?

Is that correct or will I need to generate a certificate for both the server and the alias?

E.g. -->  x1 Cert = ""   x1 Cert = "SITEALIAS"

P.s. IIS 8.5 has the proper HTTPS bindings setup so that https://SITEALIAS and both work currently just thought would be helpful to mention.
leshad82Author Commented:
Dr Dave,

Thanks for the reply! I don't think your statement is entirely true however.... my server is currently using a 'self-signed' certificate registered to "". If I push this self signed cert out via a GPO to my clients and install it into the trusted root CA folder then accessing the website via will work WITHOUT errors.

I only see the error when I navigate to the site via the CNAME alias. So I guess the real question here is can I secure this CNAME alias with SSL somehow so that the intranet website is accesible without this certificate mismatch error?

I'm open to all options if they will fix the issue, e.g. Enterprise CA, Public CA (Komodo, Digicert, etc.). However, i'm uncertain if going to a public Root CA will be any benefit to a local only website.

Appreciate the help!
David Johnson, CD, MVPOwnerCommented:
if you use cname alias and have the certificate for it will fail with a missmatch because http://alias does not equal
you could create an A or a CNAME record
leshad82Author Commented:
Hi David.

I see what you're saying that still works however you get that error still because the alias name does not match the server that the certificate is registered to.

I think my next step will be to setup ADCS on one of our servers and try to hand out certificates to the server that hosts the intranet through that.

Thanks for the sugesstions
DrDave242Connect With a Mentor Commented:
Thanks for the reply! I don't think your statement is entirely true however.... my server is currently using a 'self-signed' certificate registered to "". If I push this self signed cert out via a GPO to my clients and install it into the trusted root CA folder then accessing the website via will work WITHOUT errors.
Sorry, you're right; I hadn't thought about distributing a self-signed cert via GPO. If you want to issue a cert with an alternate name on it, which appears to be necessary, you will need to install AD CS and issue it from there. There's no supported way to issue a self-signed cert with an alternate name, and the only unsupported way I've found looks pretty ugly and unreliable.
leshad82Author Commented:
After some further research I found the solution to be unrelated to what the contributors were suggesting. Instead of using ADCS I ran a commandlet from the 'PKI' module to create my own self-signed certificates with customizable DnsNames. So instead of being forced to use the server FQDN I was able to create a certificate using the CNAME alias which will be the exact site name/URL
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.