Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 437
  • Last Modified:

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

Hi.

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 "Server-Name.Mydomain.com", it is using a self signed SSL certificate (Signed by itself a.k.a. "Sever-Name.Mydomain.com").

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

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 "Sever-Name.Mydomain.com". 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
sslerror.PNG
0
leshad82
Asked:
leshad82
  • 5
  • 2
  • 2
3 Solutions
 
David Johnson, CD, MVPOwnerCommented:
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
1
 
DrDave242Commented:
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 https://server-name.mydomain.com 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.
1
 
leshad82Author Commented:
David,

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

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 "Servername.mydomain.com" 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 = "Servername.mydomain.com"   x1 Cert = "SITEALIAS"


P.s. IIS 8.5 has the proper HTTPS bindings setup so that https://SITEALIAS and https://servername.mydomain.com both work currently just thought would be helpful to mention.
0
New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

 
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 "servername.mydomain.com". 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 https://servername.mydomain.com 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!
0
 
David Johnson, CD, MVPOwnerCommented:
if you use cname alias app.server.domain.com and have the certificate for server.domain.com it will fail with a missmatch because http://alias does not equal app.server.domain.com
you could create an A or a CNAME record app.server.domain.com
0
 
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
0
 
DrDave242Commented:
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 "servername.mydomain.com". 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 https://servername.mydomain.com 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.
0
 
leshad82Author Commented:
Agreed.

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"

DONE!
0
 
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
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 5
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now