If you’ve never had to install an SSL certificate on a webserver, it can be a daunting task the first time you do it.
It’s actually pretty easy, and this article will show you how, as well as share my experiences in dealing with SSL certs.
Scenario #1a: You need a Single Cert, for a Single Domain name, on a Single server.
This is the easiest so we’ll start with this one.
There are three types of SSL certificates:
- Single Domain Cert (cheapest – we’ll use this in our case study)
- Multi domain cert (each name must be known in advance (Mid priced)
- Wildcard cert (allows for *.yourdomain.com, for example: teams.yourdomain.com, mysites.yourdomain.com, and anythingyoucanthinkof.yourdomain.com, etc
In this Scenario, there are some things we’re going to “assume”:
- You have a single web server
- This server has a single IP address
- There is only one website on this server that needs SSL
- You are using IIS on Windows (Aka SharePoint)
- Log on to the webserver (either directly or via RDP)
- Start up IIS manager
- Click the server (top left)
- Double Click the “Server certificates” icon
- Click “Create Certificate Request” on the top right
- Fill out the form – the accuracy here may be important – different certificate issuers have different standards for what they will accept or not accept here. If you’re part of a company, you may want to ask the people who manage the certificates for the company to see if they have values they recommend filling out here. If you’re going to get the cert yourself from a company like Godaddy then it’s probably a good idea to match what you put in here, with what you have on your GoDaddy account
- Change the bit length – The default has been 1024, but these days, experts say that’s not enough, 2048 is considered the minimum today – in a few years it might be higher.
- Save the request file
Note that it’s not important to name it any specific way, nor to put it in any specific place. From a security perspective, you should not keep it in a publicly accessible place.
- open the text from the above file in your favorite editor, select all and copy
- This text will need to be copied into the request form of whatever certificate provider you use – Each one has a slightly different process. I don’t cover that here unfortunately, but each provider should be able to help you through the process.
- Once you’ve submitted the certificate, you’ll get a different file back from the Certificate provider.
- Once you have that file back, repeat steps 1-4 then click “Complete Certificate Request”
- Find the file you received from the certificate provider and answer the dialog.
- Once that’s done, it should show up in your certificate list:
Note that I cheated in the screenshot above – I used a self signed certificate – in reality, it would show it was issued to your domain name and the issued by would be the name of your certificate provider.
- Now you’ll need to tell IIS which website gets the SSL certificate. Right click on the site in IIS admin and choose Edit Bindings…
- Click Add, then change the binding settings to SSL, assign to an unused IP address and assign your certificate
A note about the IP address – when Using SSL certificates designed for a single website (what we did above), each SSL website needs a different IP address. This won’t be an issue in this scenario, because this is the “One website, one certificate” scenario, but it will come into play in other Scenarios, so its something to be aware of. (It’s also something that’s changing and has some exceptions which we’ll talk about later)
- You’re almost done. If your SharePoint site wasn’t originally created for https, you’ll want to go into central admin-> Application Management -> Configure Alternate Access Mappings -> Edit Public URLs -> then change the Alternate Access Mapping Collection on the top right and enter your SSL URL under one of the unused blanks
- That should be it, your SharePoint website should now work with SSL.
Scenario #1b: You need a Single Cert, for a Single Domain name, on Multiple Web servers.
This scenario is identical to 1a, except that you have more than one web server.
First some good news: You don’t need to purchase a second SSL certificate.
The process for this scenario is the same as the first (1a) with a few extra steps at the end.
- Start by identifying which web server will be your “first” web server – and go do all the steps from Scenario 1a on that server.
- Next you’ll export the certificate from IIS Admin (steps 3 and 4 from the 1a scenario are how you get to this screenshot):
- Enter a file name and a password – This file should be kept secure at all times – give it a good password.
- You now have a .pfx file – Copy this file to your “Second” Server
- On the “Second” web server, launch IIS manager, and make your way to the certificates area, like we did above.
- Choose “Import”
- Specify the path on the “Second” server where you copied the .pfx file to that you made in step 3 above.
Also enter the password you used in Step 3 above.
- That’s it for the import – Now just do steps 14-16 from Scenario 1a above.
- You can repeat steps 4-8 in this scenario for as many servers as you have.
- Also noteworthy with multiple servers, you only need to do the SharePoint alternate access mapping (step 17 from Scenario 1a) one time.
Scenario #2a/2b: Multiple Certs for Multiple Domain names on one server/multiple servers.
This scenario is really very similar to scenario 1a, expect that you have more than one website running on the box that you want secured with SSL. For example mydomain.com and yourdomain.com or teams.company.com and mysites.company.com – you get the idea.
This is where we start to have options when it comes to what kind of SSL certificate we use.
For this example, lets assume we’re going to purchase one cert per DNS name.
Everything from Scenario 1a/1b applies to us here – we’re going to go through the motions of requesting a certificate twice. We’re going assign the bindings twice – here’s where the IP addresses on the server become an issue – Each SSL site must have a different IP address, if you are using different certificates. (note that if you’re using Microsoft Network Load balancing, then it’s possible that you’ll have the same IP address assigned to multiple web servers – this is ok, so long as that IP is bound to the same SharePoint site in IIS on each web server.)
Now about those other certificate types we mentioned? Those are other scenarios.
Scenario #3a: MultiNamed Certificates
A MultiNamed certificate lets you assign more than one DNS name to a certificate. Each DNS name has to be specified, this is not a wildcard, anything goes cert. Security teams at large companies favor these over wildcards because they still have some control.
There is one small perk of using a MultiNamed certificate, you can share a single IP amongst all the Dns names the certificate supports.
This is both a blessing and a curse. On one had, you have fewer IP addresses to deal with. On the other, IIS 7 doesn’t like this configuration, not at all. You’ll need to light some candles, hum a few lullabies and dig into the command prompt to get this working.
The process for the MultiNamed cert is similar to Scenario 1, with a few changes:
- You will only create a certificate request in IIS for the first DNS name you want, you’ll give the other names to your certificate provider when you request the MultiNamed cert.
- You’ll only get one cert back from the provider and will install that like you did in Scenario 1
- Binding the SSL cert in IIS manager becomes a trial and error pursuit
Lets talk for a bit about that SSL binding issue.
Here’s what we’ve seen in IIS 7.5 running on Server 2008R2 (this may be a non-issue in future versions of IIS)
Sometimes when assigning an SSL binding, IIS will complain that other websites are using that binding and that changing it will break them. No worries here, just a nuisance.
More of a worry, say you have a multiNamed certificate with 3 names – you bind it successfully to the first IIS website, when you try to bind it to the second website while using the same IP and port number, you get an error. This seems to be a limit of IIS.
Here are some things that I’ve either found on my own, or with the help of a really Smart Colleague named Stevan that I work with.
Stevan found that if you can get the new certificate assigned to just ONE IIS site, then “deprovision” and “reprovision” the site from central admin, that it will often use that certificate for EVERY site it creates.
Let me explain that a bit…
All of the sharepoint sites that you see in IIS manager, are all put there by a “Service” you find in Central admin.
When I talk about deprovisioning and reprovisioning, here’s what I mean:
The screen above is a bit deceiving – That stop link doesn’t stop anything – IT BLOWS IT AWAY. This is true for ALL of the “Services” – you may have noticed I put “” around “Services” – because to me, these are NOT services – They are IIS websites, or IIS Virtual directories that get Created/Provisioned when you “Start” them, and they get unprovisioned/deleted when you “stop” them. What this means is, the folder where that stuff lived is gone. If you had any modifications to your web.config, those will be gone too.
So before you try this, have a backup of your web.config file, and preferably the whole folder structure. (note this is far less of a concern if you are doing this on a brand new farm, and far more of a concern if you’re adding SSL to a mature, existing SP farm.)
Ok now with all that out of the way, pick your webserver from the list and “Stop” the “Microsoft SharePoint Foundation Web Application” For some real fun, hop over to IIS manager and hit refresh a few times – you should see your SharePoint sites disappear right before your very eyes!
Now (Back in Central admin) Click Start and after a similar delay, these sites should now appear in IIS – if you’re lucky they will all be using your multinamed SSL cert and will all start, and will all work.
If they don’t here’s one more thing you can try:
appcmd set site /site.name:"Site1Name" /+bindings.[protocol='https',bindingInformation='*:443:URL1.Yourdomain.com']
appcmd set site /site.name:"Site2Name" /+bindings.[protocol='https',bindingInformation='*:443:URL2.YourDomain.com']
appcmd set site /site.name:"Site3Name" /+bindings.[protocol='https',bindingInformation='*:443:URL3.YourURL.com']
The above wasn’t mine – I found it on SSLShopper.com – I had tried to do the same with PowerShell, but could not get it to work. On one server, Stevan’s trick of stopping and starting the Microsoft SharePoint Foundation Web Application “Service” was enough to do the trick, yet on another farm, it didn’t work, and I needed to do BOTH the stop-start trick AND the above script – And it took a few different attempts for even that to work.
That said, you can still use MultiNamed certs with multiple IP addresses and IIS manager is reasonably happy to help you configure that, and you should be able to avoid most of the pain I just described above.
Scenario #3b: MultiNamed Certificates on multiple web servers.
Basically this is the same as Scenario 3a, but repeating parts on multiple web front ends, similar to what was mentioned for Scenarios 1b and 2b. Here are some highlights.
- For multiple servers, you still just request the SSL from the “First” server
- You still export/import the cert from the “First” to the “Second” and so on.
- You still need to set the bindings on EACH server.
- Backing up the Web.config from ONE server should be enough but why trust your career to a “should” go ahead and back up that folder on EACH server.
- If you need to the multinamed cert to share an IP you’ll need to run those workarounds described above on EACH server – for the Central admin piece – you can run that anywhere, but be sure to pick the intended server before “Stop” and “Start” are issued.
- If you need to run the appcmd commands above, you’ll likely need to run them on each server.
Scenario #4a: WildCard cert with 1 or more websites, on a Single server.
I have to confess, I’ve never laid my hands on a wildcard certificate, only heard rumors of their awesomeness when it comes to sharing an IP address with multiple DNS names. That said there are a few ground rules:
- Wildcard certificates are only good “one level down”
- You can’t get a wildcard certificate for *.com
What this means is your wildcard cert will be something like *.yourdomain.com. This means you can use it for names like:
You can NOT use it for names like:
ok if your domain names are all a good candidate for a wildcard, then you should be ok using a wildcard cert. Having never ordered one, I can only guess that the process is similar to ordering a multinamed cert- you probably need a cert request from Somewhere to create that initial bit of text needed, but honestly, it’s just a guess.
The rest would be similar – you’ll need the cert “restored” on each WFE you have, and you’ll have to do a similar trick to what we did with Multi named certs above, though I suspect it’s not so finicky.
Scenario #4b: WildCard cert with 1 or more websites, on a Multiple servers.
Same process as 4a, but you’ll copy the wildcard cert to multiple servers -(You’ll only need and pay for, one wildcard cert)
Scenario #5: Self Signed Certificates.
These can be handy in a pinch for testing, not of much use for public facing websites.
You can create these from IIS Manager – under the same screen that had all the SSL stuff we’ve been working with so far – on the right side, there’s a link to “Create Self-Signed Certificate” there’s just a small problem, the cert is issued for the name of your PC, not the name you want for your sharepoint site -there are some workarounds, one is talked about here: http://www.robbagby.com/iis/self-signed-certificates-on-iis-7-the-easy-way-and-the-most-effective-way/
Ok I think that’s an entire brain dump of everything I know about SSL certificates on IIS & SharePoint – hope this helps and let me know if I’ve missed anything.