Friday, December 16, 2011

SSL for SSRS Using a CNAME

Recently, I've been working on creating a basic reporting infrastructure.  For simplicity's sake, we're leveraging Log Shipping on a relatively small application database using SQL Server 2008 R2.  (Note: since this second instance is in active use, a second SQL Server license is required.)

Since we have a server naming convention that states if the server's role is replaced, the new host must have a different name, I want to make that transition transparent in the future.  I thought, let's leverage CNAMEs.  I created a new CNAME record in our internal DNS and aliased the actual host name.

Now, we wanted to force clients to only use HTTPS when connecting to SSRS, so I needed to get a certificate issued and installed and setup bindings.  Since this is for internal use and we have an Enterprise CA deployed, it was just a matter of requesting a certificate, except that I couldn't request a certificate based on the Web Server properties via the Computer certificate store.

Certificate Templates on my Enterprise Certificate Authority
A quick hop over the the CA to adjust the security permissions to add Domain Computers for enrollment and I could request what I needed.

Adjusting security permissions for enrollment

And now I can finally get what I need:
Initiate a certificate request from the local Computer certificate store

Selecting a Web Server certificate
This is the catch, I need to add my internal single-part CNAME DNS record and then add Subject Alternate Names for my current server which is hidden behind that CNAME.  Currently, SSRS will bind the site to the primary name on the certificate by default.  If I simply requested a computer certificate, my subject name would be the internal FQDN of my server, which would render my CNAME setup useless.

Adding my CNAME and SANs
Practical applications for doing this are for manually performed failover, or if you're really doing things right, you'll need this certificate (or a certificate like it) applied to every node in your NLB farm.  Additionally, consider the use of aliases for the convenience of client application deployments.

No comments:

Post a Comment