RSS

Setting up Microsoft Certification Authorities

14 Aug

More of Microsoft’s great products are moving towards using certificates for general security and authentication. If you don’t have an internal Certificate Authority with all the bells and whistles you should start that project as soon as possible. Move away from self-signed certs and manually using OpenSSL to create a CA. Hop on the MS bandwagon because its a good one to be on.

For websites to secure traffic using SSL/TLS the web server needs to have a key pair installed, one public and one private. IIS7 has the option of generating self signed certificates which is very convenient. Self-Signed indicates the same machine or person who is using the certificate also issued it. So if someone walked up to you and said, “Hi, I’m Bob” you might take a look at their appearance and accept this as a fact. Just like a website, if it looks ok at a glance you will entrust it with your information. Browsers today are much more paranoid. If a webserver uses a self signed cert, they will warn you and beg you not to hand over your information.

Within your organization you can give Bob a friend that will verify his identity. So when Jim says, “Yup, thats Bob”, you can be relatively certain its really Bob. What you have now is a hierarchy. In the public internet there is a short list of “Trusted Root Certificate Athorities”. These are the Jim’s of the world that have been identified as trustworthy. Being a Jim is a lot of work so they delegate their work to an intermediate certificate athority. Chrome and IE will trust Jim’s delagates because they have that list built in, however Firefox is the most paranoid and does not have the list of intermediates.

To setup webserver TLS properly you need to have a a chain installed. If you install just the bottom cert, Firefox users will get errors. All of these certificates need to be trusted by all of your users. If your users are internal to your organization, Group Policy can be used to force the Root and Intermediate certificates into their certificate stores. To look at your local certificate store, run the certmgr.msc snapin. To check a webserver, you can use OpenSSL and the -showcerts option.

If you don’t want to purchase Jim’s(godaddy, entrust, verisign, etc…) services, and you don’t have any public users to your application you can setup your own CA. There is an excellent checklist on TechNet here: http://technet.microsoft.com/en-us/library/cc737834(WS.10).aspx

The first thing to work on is the Root. This is the very top level CA and should be the most secure server. Not so secure that you lock yourself out because you may need to get in and revoke certificates. What Microsoft recommends is having an offline root CA. So if you install 2008 R2, patch it, set secure local passwords and then unplug the NIC. Now you can install the Role for Active Directory Certificate Services. This creates the private key and is the thing you need to protect most out of anything in the whole scheme. If someone asks you for your private key they do not know what they are talking about, or are trying to steal something. Using the Web interface makes things a bit easier so IIS7 would also be installed.

My advice is to be willing and ready to scrap your solution and start over from scratch. This process has a bunch of gotachas. It very much reminds me of a “some assembly required” desk I put together that I had to take apart multiple times to finally get it right. Its so easy to miss a step that you won’t find out about until months later. I missed a couple steps myself so hopefully I can help you out.

What you will setup is the Root and Intermediate servers. Pick good names for the servers that are not very close to each other CAOfflineRoot and CAInt might be good names. Setting up the root is easy, then you have the challenge of setting up the intermediate. Create a signing request, send that to the root, get the cert back and install it as the intermediate CA certificate. This cert signing is similar to what you do when you install a cert in a web server.

To reduce the administrative overhead you can extend life of certs your CA issues. In 2003 this is a registry entry, and in 2008 I believe its in the properties. The certs you have already issued are now fairly useless because they will expire too soon. This is the first gotcha because you will then have a list of issued certs on your offline root that is growing. You should revoke certs you are not using/replaced… or start over.

Also, another suggestion for the offline root only, increase the length of your CRL publish. By default CRLs expire once a week but you don’t want to manually publish your root CRL every week, so if you raced ahead… fix that and start over.

To use the web interface in 2008, you will need to setup SSL for the certserv website. This isn’t a requirement in 2003 but is recommended. If you used the offline root to sign the web cert… you may want to start over.

The last gotcha I ran into the with the CRL and AiA. The Certificate Revocation List is something every CA has to publish. Its a file that is hosted via IIS or the CertEnroll share. The problem with setting up an offline root CA is you have to publish the CRL manually. Removable media is the suggested route. This gotcha didn’t bite until Exchange2010. Before Exchange, the web certs I installed didn’t verify the entire chains CRLs. I had to renew the intermediate CA because I had to make changes in the root CA’s settings. These settings are in the Certificate Athority Snapin -> Root -> Properties -> Extensions. By default the CA will issue the certs and tells viewers to look on the local hostname. You have to replace the hostname variable with the intermediate server hostname. Then you have to restart the root CA, and manually publish the .crl to active directory specifying the name of the Root. This is the gotcha that made be decide to blog.

Now that everything is working perfectly, you need to modify group policy so that all your network computers trust your root and intermediate. Go to the intermediate CA website and download the chain. Don’t publish anything until you’ve cleared up all the gotchas. Happy securing!

Advertisements
 
Leave a comment

Posted by on August 14, 2011 in Network Admin

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: