IIS 7 and IIS 7.5 – How to renew a self-signed certificate and bind to your website.
Almost one year ago I built an Act server for a client. Act includes a web interface which can be reached by a secured SSL website on port 443. When I setup the site, I used a self-signed certificate as the client is budget conscious and is ok with using a non-third-party trusted certificate.
We monitor all of the servers for certificates that will expire and we received an alert that the SSL Certificate on server ***, port 443, is going to expire in 7 days. I browsed to the website, accepted the certificate warning and then opened the certificate itself. Sure enough, the clock is ticking and the cert was to expire on 3/26/13.
To replace the certificate with a new self-signed certificate, hop on to the server’s console that hosts the IIS site and open Internet Information Services (IIS) Manager.
Select the server (name) under the Connections Pane on the far left of the application.
Under the middle pane, double-click on the Server Certificates icon.
3. Here you will see all of the listed self-signed certificates including the one that will expire. On the right-hand pane under Actions, click on Create Self-Signed Certificate…
4. Specify a friendly name for the cert. I used companynameservername2014. Click OK. You should now see your new self-signed cert available in your list of certificates.
5. Now that the certificate has been created we need to bind it to our website. Under the Connections pane, right-click on the Default Web Site and click on Edit Bindings. Find https, click on it to select it and then click Edit…
5. Inside the Edit Site Bindings, change the Drop-down combo box to the SSL certificate you want to use. Click ok – you’re done!
6. To test, browse to the site you host with https:// and look at the certificate, you should see it is now set to expire 1 year from now.
Exchange/Outlook 2010 autodiscover certificate error name mismatch
Recently some users have been receiving the following autodiscover certificate error when opening outlook:
Security Alert: autodiscover.domainname.org
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.
√ The security certificate is from a trusted party
√ The security certificate date is valid
X The name on the security certificate is invalid or does not match the name of the site
Firstly, we host exchange at a different hostedexchange.com, and our autodiscover uses a wildcard certificate “*.hostedexchange.com”. So starting with the client I made sure to view the certificate. The correct name on the certificate listed was “*hostedexchange.com.”
1. I installed the certificate on to the client PC into the trusted store. Closed outlook/opened again and still the same error.
2. I looked at the proxy settings in the account setup and found that the ‘server name’ and msstd: were correct, they were.
3. We used nslookup externally and found that there are no valid dns records pointing to autodiscover.domainname.org
4. We used https://www.testexchangeconnectivity.com/ and found that while it does automatically check for autodiscover.domainname.org, dns did not return a value; it failed
5. From the client we were able to ping autodiscover.domainname.com, the ping returned an internal ip address of our mail server.
6. So from the results above it appears as though the client (or citrix server’s hosted desktop in this instance) had an incorrect dns entry.
7. From a (run as administrator) command prompt I issued an “ipconfig /flushdns” command on the client server but the error persisted, and pings still replied from autodiscover.domainname.org
8. We checked the hosts file on the server (c:\windows\system32\drivers\etc), and sure enough there was an old entry for autodiscover.domainname.org
9. In order to edit the hosts file, did a “Run as administrator” to open notepad, edited the file and saved successfully.
10. Issued another ipconfig /flushdns
Now when the client opens, the request to get autodiscover.domainname.org fails, and there is no mismatch of certificate names.
Client Access Server Security and Secure Socket Layer Certificates
In this post we will review:
– CAS security through digital certificates and how these vary.
– We’ll also review the different SSL certificate types.
– Lastly, we’ll work through the following:
Create a Certificate Signing Request (CSR)
Obtain a certificate from a Certification Authority (CA)
Install the SSL Certificate on the Client Access Server
Up until this point in your Exchange deployment, you may have configured access with the default self-signed certificate. This may be problematic because it doesn’t support all of the access methods (Outlook Anywhere) and isn’t the most secure method of authentication. You may decide to obtain a trusted certificate from a third-party commercial Certification Authority (CA) and install that certificate on the Client Access Server. You do also have the ability to use a PKI certificate through Microsoft Certificate Services which you can setup internally, however, the infrastructure costs and labor may not be worth the trouble.
Managing Authentication
A digital certificate will authenticate to the client that the server with the certificate is trust-worthy. The server can prove, they are who they say they are.
In addition, a digital certificate will ensure the data that is exchanged is protected.
By default, with Exchange 2010, client communications are encrypted using SSL with Outlook Web App, Exchange ActiveSync, and Outlook Anywhere (SSL will not use the Self-Signed Certificates). By default, POP and IMAP aren’t configured to communicate over SSL. You will use the IIS Manager to ensure SSL is enabled on the virtual directory.
Go to the IIS Manager on your mailbox server. Select the server itself, scroll down to Server Certificates. Here you’ll find the Microsoft Exchange Certificate (Issued to itself by itself).
Click Image to Enlarge
You can double-click on the certificate and check out the properties and see that it’s not trusted.
In IIS, expand Sites and then Default Web Site. If we look at the different sites in IIS, as far as SSL turned on, click on OWA, and then Secure Socket Layer settings, and see if it says “Require SSL”. We can test to see if that works by browsing to localhost in the web browser. An easy way to do this is to click on the “Browse: 443 (https)” link in the Actions pane:
Click Image to Enlarge
This will open the browser and we’ll be brought to our Outlook Web App. We will have a certificate error. Users will have to install the certificate if they want to get rid of the Red Security Trust Bar in their browser. In this case we will want to install the certificate into the Trusted Certificate Store. Windows cannot validate the certificate, but since we know where the certificate is from we can install it and accept the warning.
Three types of Certificates:
Self-signed: Signed by the application itself (in our case Exchange 2010) and will allow for OWA and/or ActiveSync functionality but not Outlook Anywhere. *For these to work you have to manually copy them over to the trusted root certificate store of the client computer or mobile device.
Public Key Infrastructure (PKI): Requires setting up certificate servers and establishing the certificates for communication.
Trusted Third-Party Certificates: Provided by a CA, these are automatically trusted by clients (unlike the two options above), so the deployment is simplified.
Certificate Types
When you go to purchase a certificate from a CA you’re going to find that different types to purchase.
Wildcard Certificates: Can represent multiple domain names (for example *.jasoncoltrin.com), however these types of certs provide a less secure method because the wildcard can be used for any sub-domain. Microsoft does not recommend wildcard certs, but to use SAN’s.
Subject Alternative Name (SAN) or Unified Communications Certificates (UCC) certificates are considered better in this regard because you specifically list out each of the trusted domain names. *It is considered best practice to use as few host names as possible (perhaps as few as three).
The CA Process for Obtaining and Installing Certs
Take a look at the GoDaddy website for SSL Certificates
Begin the process of managing a purchased certificate
We will return to our Exchange Server and use the Exchange Certificate Wizard to obtain a Certificate Signing Request (CSR)
Use the CSR to complete the GoDaddy certificate process
Once that certificate is provided (up to 72 hours), we will install it on our Client Access Server
On our Mailbox Server, open the EMC, browse to Server Configuration.
Under the Server Config Node, beneath the servers, we will have our Exchange Certificates.
What we really want is an SSL certificate from a CA.
In the GoDaddy website, we’ll purchase our cert, manage our Products -> manage my certificates, and then in the SSL management, we will click “Request Certificate”. It will ask where the cert will be hosted. We will want to choose Third Party or dedicated server. Now we will need to Enter your Certificate Signing Request (CSR). Use at least a 2048 bit key.
Go back to the EMC, under server configuration, in the Actions Pane, click on New Exchange Certificate. For Starters, enter a friendly name for the certificate.
If we want to Enable Wildcard Certificate we can do that here. But we don’t want that at this time, we want a literal domain name so leave unchecked and click next.
Now depending on the cert purchased, our options here will be different. For example we have 5 certs purchased and can only use 5 names.
For Federated Sharing, we will place a checkmark in the Public Certificate because in the future we may want to Federate with a different site.
For Client Access Server (Outlook Web App), for the Intranet – you may want to use a local name like mail.jasoncoltrin.local and for the Internet – use mail.jasoncoltrin.com
Click Image to Enlarge
We want Exchange ActiveSync, so perhaps sync.jasoncoltrin.com is the name we’ll want to use. Most use mail.domainname.com.
Go down the list and have Exchange Web services enabled; Outlook Anywhere enabled.
Autodiscover used on the internet: Autodiscover URL to use: autodiscover.jasoncoltrin.com.
The use of sync.jasoncoltrin.com differentiates and relates to mobile devices. When you set up the cert, that’s when it (the name) counts. For the dropping of POP and IMAP support, in all honesty is probably a good thing, and we prefer a more secure protocol and have everyone come in through ActiveSync. With ActiveSync we have the ability to wipe devices.
At this time we don’t need a cert that supports POP or IMAP.
For Unified Messaging, you can go with a self-signed cert.
At this time we are going to skip Hub Transport server mutual TLS and Hub Transport server for POP/IMAP.
At this time we are not going to use Legacy Exchange Server.
Clicking next will give us a review of our cert (request). In our case we have 6 names. To bring this down to 5, we can change intranet/internet mail.jasoncoltrin.local to mail.jasoncoltrin.com and save a name.
Click next, and the wizard will ask for some information. The full legal organization name, Org unit (none), Country, City, State, Certificate Request File Path – name the file something like “SSLRequest”, then New and Finish. Make sure the CSR generated is 2048 bit. Once finished, browse to where the file was placed, open the Certificate request with notepad, and copy and paste the entire string including –Begin new cert — to —End New Cert..— into the GoDaddy.com CSR text box.
Click Image to Enlarge
After submitting the encrypted data to GoDaddy, you will see the Subject Alt Names and Primary Domain Name. Your cert will be issued shortly (72hrs), and at that time we will be able to import it. Once the cert is issued, you can download it from GoDaddy. The cert will come down zipped, so unzip it.
Go back to the EMC, You will still see your requests and your self signed cert. Right-click on the SSL Cert and choose Complete Pending Request.
Click Image to Enlarge
Browse to the downloaded cert (domain.com – not the intermediate cert), click complete, and that’s all there is to it. So we’ve installed it but don’t have any services using it. Right-click on the cert and choose Assign Services to Certificate.
Click Image to Enlarge
Use SMTP, IIS, click Next, and then Assign.
Click Image to Enlarge
Do we want to override? Yes.
When we downloaded and unzipped the SSL Certificate, we also received an Intermediate Certificate. The intermediate certificate is used to enhance the security of the root certificate. These are also called a Chained Root Certificates. There are instructions on the GoDaddy site for installing the Intermediate Certificate. It is optional, but you should install the Intermediate certificate if the CA provides you with one, but we will forego that for now. Your CA may or may not issue Intermediate certificates.
In conclusion, in this lesson we discussed the benefits of SSL digital certificates, encouraged SAN certificates, worked through the process of requesting a certificate from the GoDaddy Certificate Authority, and installed and enabled services using that cert on our Exchange Client Access Server.
A large majority of the content provided in my Blog’s Exchange series is derived from J. Peter Bruzzese’ excellent Train Signals Exchange Server 2010 Video Disk Series, as well as my own Exchange 2010 lab. Trainsignal.com is an invaluable source for accurate, easy to understand, IT information and training. http://www.trainsignal.com
