Certificate mismatch. How to avoid using the certificate from the domain registration company?
-
Samstag, 2. März 2013 04:14
Problem Overview:
When I attempted to connect to a virtual desktop (VD) using Window’s Remote Desktop (RD) Connection application from an external network, I encountered a certificate subject mismatch error.
“Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address requested and the certificate subject name do not match. Contact your network administrator for assistance.”
Is there a way to get RD Gateway to just avoid certificate authentication in general? (for Windows Server 2012)? If not, below is a more detailed description of the problem (I think it said somewhere “RDS requires certificates for server authentication”).
Network Setup:
Below is a simplified version of my setup.
- Domain Info:
- ~Internal Domain Name: misoit.edu
- ~External Domain Name (from JustHost): outside.net
- ~“outside.net” (from JustHost) is configured to re-direct itself to http://10.10.10.2
- Router Info:
- ~Gateway Router External IP Address (from ISP): 10.10.10.2 [fake]
- ~Router forwards port 3389, 443, and 80 to internal server.
- Server and Client Info:
- ~Same server has the RD services installed (RD Web Access, RD Gateway, RD Virtualization Host).
- ~Same server hosts the VDs.
- ~Server hostname: vd-host
- ~Virtual Desktop (VD) name: Win8VD-0 (I picked one out of a couple).
Background:
I’m currently setting up a VDI environment and have forgone the option of accessing the VDs using a web browser, for I believe the web service did not configure the .rdp files correctly.
Error Re-creation Steps:
Step1: When I first installed RD gateway, I made self-signed certificates using “outside.net” and applied it to all RD services.
Step2: I imported the created certificate, via USB flash drive, to the external client and made sure it got inserted into the “Trusted Root Certification Authorities”.
Step 3: I attempted to use RD Connection in two ways. The first way inserts “outside.net” as the “Server name:” and the second way inserts “10.10.10.2” as the “Server name:” so I essentially tried connecting twice, but changing just one field each time. Both attempts ended up with the error. So visually, when I load RD Connection app, the fields would be
Under General tab
- Computer: Win8VD-0 (Virtual Desktop Name)
- User name: misoitedu\mis.student (Domain\Domain User Name)
Under Advanced tab in Settings
- Server name: outside.net [I used 10.10.10.2 for the second attempt]
- “Bypass RD Gateway server for local addresses” is checked.
- “Use my RD Gateway credentials for the remote computer” is checked.
Step 4: When I clicked connect, a window asks me for the password so I entered it. I also noticed some details on the same window.
“These credentials will be used to connect to the following computers:
1.) Outside.net (RD Gateway server) [10.10.10.2 was shown for the second attempt]
2.) Win8VD-0 (remote computer)”
I continued and it tries to connect “Initiating remote connection…” but the error I mentioned at the beginning of this post pops up each time I connected with the different field. When I clicked on the “View certificate…” which was on the error window, I noticed each attempt has different certificate information. If I use “outside.net” then I see the certificate info
- Issued to: *.JustHost.com
- Issued by: PositiveSSL CA
If I use “10.10.10.2” then I believe I see the certificated I imported.
- Issued to: outside.net
- Issued by: outside.net
Deduction:
I could be wrong, but I’m thinking when I used “outside.net” the external client was using the wrong certificate (not the one I imported). When I used “10.10.10.2” it used the right certificate, but maybe putting an actual IP address in the “Server name:” section threw it off? I was also thinking about using a different FQDN like vd-host.outside.net or Win8VD-0.outside.net but I think I'm getting a bit wild here.
Question:
So, how would I make the external client used the certificate I imported when I use “outside.net” to connect? If I’m way off in my deduction then where should I begin to troubleshoot?
Alle Antworten
-
Freitag, 3. Mai 2013 21:36Moderator
This is a very confusing set of questions. Let me try to clarify a bit how things should work and then you can go from there:
1. On the "outside" of a private network you will not get any results by using a Private IP space 10.x.x.x routers on the Internet by default block this because it is a private only range. I think you probably know that, but I just have to start there because I don't follow the story perfectly.
2. You have to own the name of the outside network. You've got to control the DNS records for a real Internet name. If you don't then your client is going to contact whoever owns the actual domain name and go to their server.
3. The certificate has to be trusted by the client computer. That is usually done by trusting the Root CA of the certificate issuer. If you issued your own self-signed certificate or something from an internal CA, then you need to ensure the client can trust that certificate.
4. Finally, the client computer has to be able to check to ensure that the certificate that was issued to the server is still good. This is a certificate revocation check. This is the extra part that usually trips people up. You should be publishing a certificate revocation list (CRL) to an external CRL Distribution Point (CDP), so that your client can verify that your CA has not revoked the server certificate that you want it to trust.
Do all these concepts make sense? If not, you should search on those terms and ask more questions. A basic hands-on lab for PKI for Windows Server 2012 is at http://technet.microsoft.com/en-us/library/hh831348.aspx.
Kurt Hudson, Sr. Technical Writer AD DS, AD CS, PKI, Azure AD
-
Samstag, 4. Mai 2013 02:00I wish Microsoft’s tech forums didn’t restrict posting of images because it would come in handy right about now.
To reply to your posting Kurt (thanks for being organized).
1.) I’m just using 10.X.X.X as an example because I didn’t want to give out the actual unique public IP Address I got from my ISP.
2.) I bought a real domain name from JustHost hosting service. Outside.net is just another example because I didn’t want to give out the real one either. There’s a plethora of configurations that JustHost provides, but at this point, all I configured is to forward outside.net to the unique IP address from my ISP (the example 10.X.X.X).
3.) This gets a bit iffy concerning the certificates. I got to the point where I had to manually transfer the certificate from the server to a flash drive, then transport it to the client and manually insert it into the root CA. I’ll get back to you on the exact steps because I got domain names flying everywhere.
4.) Now this is a new concept that I have not heard of yet since I’m still new to certificates in general. I shall try this out after I have confirmed that #3 didn’t work. I have a question about publishing a CRL to an external CRL CDP though. Are there fees involved to do that? I ask because I was looking at SSL certificates at one point, but those are costly for what I’m doing.
I’m currently messing with Window’s Active Directory Certificate Services to have an internal Certificate Authority to see how that works. I’m also changing my internal domain name to match my bought domain name from JustHost to see if that will simplify things. -
Samstag, 4. Mai 2013 03:01Moderator
That is strange, because you should be able to share an image. I see the button there, you just cannot copy and paste it. You have to save the image (use .png format if you can) and then click the little picture of the mountain and sun icon and load your image.
1. Okay, so you have your own domain name and you own it. Good.
2. Let's pretend your domain name is company.com and you have an external site named www.company.com. You could post your CRL right there in the www directory if you wanted, but some will use a sub-directory or different computer, web-farm, or whatever. No, it does not cost anything extra to publish the CRL, you just post it to your http:// accessible location and ensure that your certificate clients can get to it. Ideally, this is a location accessible from both the internal and external network. The CRL and CDP is not a secret or protected location. Instead, you want everyone to be able to check it because those are the certificates that you say "may still be valid, but should not be trusted"
3. Further, you can place your public key .crt file (no private key) to a share for your clients to Trust. They put it in their Trusted Root CA location. This you can do using Group Policy. That keeps you from having to actually buy a certificate from a Trusted Root CA. However, you will want to buy one if you are trying to communicate with a global audience over which you don't have control. Does not sound like that is your case.
4. Now, I am giving you the mechanics of how to do it, but I didn't mention the design or legal parts. I wrote a TechNet Wiki article to help point out the resources: http://social.technet.microsoft.com/wiki/contents/articles/2901.pki-design-guidance.aspx
5. The AIA and CDP on the CA need to be configured to point to the correct locations before you start issuing certificates, because the certificates you issue are the items that will be used for these verifications. In the labs that we've created on the TechNet Wiki and the TechNet Library, we explain how to publish the CRL and AIA. Honestly, it is just a matter of copying the files from the %windir%\system32\certsrv\certenroll directory to the appropriate location. And modifying the settings of the CRL and AIA, which can be done through the Registry, using certutil, or in Windows Server 2012 Windows PowerShell. All of them ultimately modify the registry and then the certificate service (certsvc) needs to be restarted.
As for simplifying things by coordinating the names, yes, that will probably help. However, there is the concept of using a subject alternative name http://technet.microsoft.com/en-us/library/ff625722(v=WS.10).aspx that allows you to include the name that you own in the certificate. This allows the client to verify that the certificate was indeed issued to the appropriate host. For example, your web server might be www.company.com, server1.company.com, and web.company.com and all those names might be used by different client computers. Those computers will try to verify one of the names using DNS. If they get a match, and the client trusts the root certificate (and that certificate is still valid), then the client assumes that it was okay with the Root CA that the computer has three different names. When you trust a Root CA (as a client), then you trust all the certificates issued by that Root CA and any of its Issuing CAs, so long as the certificates do not appear in a CRL published at the CDP.
I hope this verbose answer allows you to review the resources I have pointed out and make sense of them. The biggest issues that people run into when setting up their first PKI (we typically recommend the two-tier, unless you know better) is that they miss the following:
1. Issuing certificates they don't mean to issue because without first adding a CAPolicy.inf, as soon as you setup a CA, the domain controllers will start requesting certificates. That is why in the labs we have you create a CAPolicy.inf before you install.
2. Issuing Delta CRLs from their Root CA - not needed. A Delta CRL is not needed for many environments at all, even on the issuing CAs, but in the labs we have you turn them off on the Root CA and keep them on for the Enterprise CA. If you plans are relatively small, then you can just turn off Delta CRLs altogether.
3. Not setting their AIA and CDP locations correctly. That is what I just spent time explaining.
4. Not ensuring their client computers trust the Root CA certificate (published in the AIA).
5. Publishing to an LDAP location, when they mostly need an HTTP location. Your external client computers won't typically be verifying your certificate using LDAP access, right? They are outside the firewall. Give them a publically accessible web location to verify access. Realize that you have to put that location into the CA properly before you start issuing certificates to the client computers.
Okay, I must feel like typing a lot. Sorry about that, but I hope it is all useful information. I think our labs will help you through the steps, but you will have to be sure to substitute your own internal and external names as needed.
You can, of course, post questions here and really should be able to show screen captures or diagrams as well.
Kurt Hudson, Sr. Technical Writer AD DS, AD CS, PKI, Azure AD
- Als Antwort markiert Kurt L Hudson MSFTMicrosoft Employee, Moderator Dienstag, 7. Mai 2013 17:21
.png)
.png)
