Client Side SSL with SharePoint
 |
| Photograph by 2happy (Attribution) |
In the words of many of the InfoSec gurus, "Implementing SSL is HARDDD!". No seriously, implementing Client Side SSL with IIS and SharePoint can be time consuming and frustrating.
Client Side SSL is for the server to validate you, not for you to validate it. (The later is called server side SSL).
Here's some great references and filler to cover the lack of detail on certain aspects.
Here's how I understand client side certificates, and understanding the relationships helped me work through the technical implementation. The explanation below is probably leaving me wide open to get pwned by a troll. But anyway:
- You need to create a server certificate (a.k.a an X.509 cert) and and a private key (a.k.a digital ID). This is pair is used to generate client cert key pairs. You never reveal the server private key to the client or the game is over.
- Add the certificate to your IIS7 server certificate store and bind it to an IIS website, in this case a SharePoint Web Application under https and a valid port. Set the site to accept certificates and require SSL.
- Create a client certificate (.cer) and a client key (.pvk) {This should be different from the server private key}
- Bind those together to make a PKCS #12 file (.pfx) which allows you to redistribute the certificate private key pair as one file, with a password preferably.
- Then you give the pfx and the server certificate (.cer) to the client user, telling them to add the .pfx to their personal certificate store and the server certificate to the Trusted Root Authority Store of the local machine.
Most of the technical details for implementing the above is covered in great detail in the following brilliant blog article: http://ondrej.wordpress.com/2010/01/24/iis-7-and-client-certificates/
The SharePoint extras:
- Alternate access (AAM) mapping hell - The certificate that I had generated was under the fully qualified name of my server e.g. myserver.domain.internal which is annoying as it means that https requests to that site must be on https://myserver.domain.internal:4444 (some arbitrary port). Its a bad looking url!
- The trick here is that you need to add an external url reference for the fully qualified name in the custom section. This can then be mapped to whatever internal url you need. (for SSL termination etc.)
That should do it if you browse to the site remotely with the pfx and cer in place then you should be ok. There may be issues with the name on the cert not matching the destination. But that seems par for the course.
Other noteworthy references: