SBS, Essentials, RWA and SSL
February 1, 2013 2 Comments
The countless hours we wasted trying to make the wizard work, troubleshooting certificates with GoDaddy, Enom, Microsoft and that’s before you worry about where your domain name is hosted. Thankfully, or should it be, mercifully, in Essentials 2012 the whole wizard process is a lot cleaner and dare i say more intuitive.
That is, however, unless you lack an understanding of what this stuff actually does and how it works.
Microsoft’s idea for the RWA or Anywhere Access wizard is that a total novice can sit down at a server, run the wizard, buy a domain name and associated SSL and let the server do the rest. A great if not bold idea.
A properly configured RWA will allow for access to Shared Folders, Remote Desktop to the Server and Internal Computers and on the SBS Standard OS, also the the internal SharePoint and Outlook Web Access.
It’s a great tool and one, i think, that plenty of larger organisations wish was available to them. Anyway that is not the reason for this post.
Over the last few weeks questions have been popping up in the forums regarding trouble getting the RWA to work, the most common of which seems to be the Certificate Name Mismatch.
You’ve probably all seen a warning similar to this, this signifies a problem with your SSL.
Unfortunately this type of warning does not block access to the RWA, which in turn leads to the issues outlined. If you see this before logging into your RWA, you should expect it to fail.
There seems to be some confusion over the role of SSL, how it works and why it is used – leading to all manner of attempted workarounds.
All of these issues can be avoided with a little bit of understanding, and perhaps better documentation from Microsoft.
It is one thing to want the wizard and tools to work so that a novice can set them up – expecting that same novice to know they are getting the wrong end of the stick and beating about the bush with it is another matter.
Rules of the RWA
1. You must always access the RWA by name, not IP Address.
This may seem obvious, but it is fundamental to the way SSL works. Your Certificate is going to be issued to a name, not an IP Address. This leads us nicely to rule 2.
2. The name you connect to, must match the name in the SSL Certificate.
If you try to connect to mail.server.com, and the SSL is issued to remote.server.com, you will fail.
3. The SSL Certificate must be date valid.
Again, perhaps obvious to some, SSL Certificates are issued for a period of time, if you SSL is outside that time period you need to renew it.
4. The SSL Certificate must be trusted by the device you are connecting from.
Certificate Issuing companies are called Certificate Authorities. There are several big names out there, VeriSign being the main one. You may have heard of others like RapidSSL, GeoTrust, GoDaddy etc. These companies are trusted. That is to say that your device (PC, MAC, Tablet) manufacturer has vetted that organisation and installed their Root Certificate on your device OS. That means that your system implicitly trusts any certificate issued by those companies (and there is a big long list of them). If your certificate is not issued by a Trusted CA, you will have extra work to do to make it trusted. It could be a self signed cert (from an Internal CA) or just a CA that is not well known, either way you must make your Device trust that SSL.
If you follow these 4 simple rules you are almost guaranteed to have success. I’m leaving myself some wiggle room on that because there is one instance where the above can be true, and you still have a problem. That problem is Remote Desktop Gateway.
Configure the RDP Gateway SSL
In almost all cases, modifying the SSL will automatically update the SSL for RDP Gateway. However, in some cases, it appears that this is not happening and may lead to this error.
How to confirm if that is the problem or not, is quite simple.
First you need to make sure you have the RDP Gateway Management tool installed, as it is hidden by default on SBS 2011 and Essentials 2012.
You need to run the following command:
dism /online /Enable-Feature:Gateway-UI
Load up RD Gateway Manager from Administrative Tools and select your Server.
If you have a Certificate Mismatch, you will most likely see this error.
Considering no clients will be connected given the name mismatch, it seems like a silly question to ask, but i click No.
You can then go to the properties of your server, and chose the correct SSL Certificate
From the SSL tab, click Import Certificate. In the next window we must find our correct Certificate.
Remember, it must be In Date, Trusted by remote clients (not just the server) and match the name you use to connect to RWA.
Once you have found the correct SSL click on Import and then Apply. The RD Gateway service will restart and all should well with the world, at least as far as logging in to your computers is concerned.
You can verify that by trying to login to a machine…
I hope this has been useful, and will point you in the right direction if you are getting stuck.