Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services

After recently hitting the default two year expiration point with our SharePoint development environment’s AD CS-issued SSL certificates, I set about updating that environment with a new five year template. I took this opportunity to see if I could make it as good as possible without breaking compatibility with anything. I will discuss some of these compatibility issues along the way. I will also make the certificate exportable, make sure it’s using the SHA256 hash (SHA1 will be deprecated in the near future), change the Certificate Authority (CA) configuration so that HTTP Distribution Points will be contactable from “outside the network”, and set permissions on the template in a way that it will be generally usable.

Steve Peschka tackled some of these basics about 18 months ago, but as he notes, his posts covers the simplest updates you can make. I think a few other options are worth considering. I don’t pretend to know all that there is to know about Active Directory Certificate Services (AD CS), or PKI in general, but I do think we can advance considerably beyond the default with a few changes. This is not a well-documented subject, so I hope to pull a few disparate resources together and propose an improved template. If you think anything here can be improved further, please post in the comments and I’ll try to incorporate that feedback.

Continue reading “Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services”

Things that don’t update when changing an AD FS URL in Windows Server 2012 R2

Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.

Continue reading “Things that don’t update when changing an AD FS URL in Windows Server 2012 R2”

Editing the Host Name field for wildcard SSL certificate bindings in IIS 7

Not only is this the thing that I always forget, it’s the thing that I’ve just learned I didn’t really understand. My colleague Ben just absolutely pwned me about an SSL certificate’s “Friendly Name” field and how it’s used when editing SSL binding in IIS. I was certain that Friendly Name couldn’t possibly be related to getting an editable host name field when you bind multiple Web Applications on the same IP address (assuming you have a wildcard certificate to handle this multiplicity). How it works with SAN certificates I don’t really know, but that’s a topic for another post. At any rate, in this case, I was bashing my head because I couldn’t get an editable Host Name field for my newly-extended Web Application:

Continue reading “Editing the Host Name field for wildcard SSL certificate bindings in IIS 7”