Certificates are truly certifiable

2012-11-15T15:50:00Z

Making certificate generation a bit easier for us Lync folks…

Ever notice that sometimes the one-liner in the documentation turns out to be the thing that takes the longest? I am going to try and address one of those scenarios with my latest (admittedly way belated) post.

Back in the old days (read: “the OCS era”), if you had to generate a certificate for another server like a reverse proxy (ISA/TMG), the approach most people seemed to take was “I will request and import the certificate in Windows Server 2003 (IIS 6.x), then export the results to the server that needs it”. That worked. Really well. Unfortunately that little piece of magic disappeared in Windows Server 2008 (IIS 7) – or at least it got well enough hidden that many of my customers (and me) could no longer find it.

Needless to say, a bit of enhanced stress usually bubbled up the first time one came across this scenario in Windows 2008 (and then you went ahead and found an IIS 6 box). Lately however, many customers are getting rid of the last IIS 6 box because Windows 2003 left mainstream support in the middle of 2010. That means the stress comes back to visit. This results in the “Help” phone call / email / IM. To avoid that next call if possible, I put together this little cookbook to allow you to obtain a certificate quickly and easily from within a Windows Server 2008 / R2 box.

My customers have typically used this approach to request / import and assign certificates for reverse proxy (TMG) servers in Lync 2010/2013 as well as the new Office Web Apps server used with Lync / Exchange and SharePoint 2013.

In my example I am assuming you are running Windows Server 2008 or 2008 R2. I haven’t had to try it yet on 2012, but I think all should be okay. Famous last words (read: “Neville Chamberlain”).

Here is my approach:

1. First off, you will need to create an INF file containing the important details for your server (in my example I am using an Office Web Apps server called LitWebApps.litware.com). You will need to save the INF to a known path for use in the next step.

The template for the INF is the text below (the parts you will need to update for your server are BOLD:

[Version]

Signature="$Windows NT$

[NewRequest]

Subject = "CN=LitWebApps.litware.com" ; FQDN of server

Exportable = TRUE ; Private key is exportable

KeyLength = 2048 ;can be 512, 1024, 2048,4096

KeySpec = 1 ; Key Exchange

KeyUsage = 0xA0 ; Digital Signature, Key Encipherment

MachineKeySet = True ;must be true for computer accounts

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

ProviderType = 12

RequestType = CMC

[RequestAttributes]

CertificateTemplate = WebServer

SAN="dns=litwebapps.litware.com"

2. Once you have saved the INF, you create the certificate request by running certreq with the “–new” parameter as in the following screen shot. This will result in a REQ file being created in the path you choose (in my case, I just put both the INF and the resulting REQ on the desktop)

The REQ (request) file needs to be sent to a certificate authority.

3. If you are using a third party (i.e. non-Microsoft) CA, submit the request file to your CA and have them create the certificate. That certificate will get accepted with the procedure in the next step.

If you are using a Windows Enterprise CA, submit the REQ via certreq with the “–submit” parameter. You might be prompted to select the CA you want to issue the certificate:

When complete, you will see information on screen similar to below. This will tell you the Windows CA has issued the certificate, and it's ID. If this fails, you might want to see if you have autoenroll or support for SAN values enabled on the CA

4. At this point, whether you use a Microsoft CA or a third party CA, you have a certificate “in hand”, but you will need to accept it to get the private key association. You do that with certreq and the “–accept” parameter:

Once accepted, the certificate gets placed in the local computer store, ready for use. In other words, you are done!

Once you are set up to do this, the process is easier than the old IIS6 mechanism (in my mind anyway).

As an added plus your security team will probably like this as approach as the private key is only on the server that needs it, instead of being on the requestor and the actual target.

Hopefully this helps you to get through a certificate request scenario a bit quicker. In any case, I plan to start putting up some more Lync fixated content in the near future, time permitting.

jlefort

Certificates are truly certifiable

Making certificate generation a bit easier for us Lync folks…