Setting UP PKI and Certificate servers on a Windows Server 2008 R2 domain

My company has asked our team to implement a PKI solution so we can encrypt and digitally sign emails, files, authenticate users for web-based applications that are on DMZ servers (bounce authentication againts internal AD servers from the DMZ).

Ourt current environment is: Active Directory with DOmain controllers as Windows Server 2008 R2.
Multiple member servers in 2008 and some in 2003. Applications in our internal domain and some are located at the DMZ.

What is required to start this implementation? PKI server, Certificate signing (Microsoft-local vs Third-Party).

LVL 2

itsecalertAsked: 2010-09-03

Who is Participating?

LVL 44

Adam BrownSr Solutions ArchitectCommented: 2010-09-06

You won't need to get a third party certificate for your DCs if you are only doing internal certificate generation. You will, however, need to set up the AD Certificate Services Role on a server in your network and configure it as an Enterprise Root CA. Once that's done, the certificate for that server will be distributed to all computers on the domain via GPO and they will then trust any certificate generated by that Root CA. Third party certificates are meant to be used for generating SSL certificates and a number of other types of certificates when a CA hierarchy doesn't exist already. Once you have a Root CA in your network, you can configure it to autoenroll devices and computers with certificates. Here's a step-by-step article from Mickeysoft for managing AD CS: http://technet.microsoft.com/en-us/library/cc772393%28WS.10%29.aspx

The limitation of AD CS is that only computers that are members of the domain will automatically trust the certificates generated by the Root CA. Computers that are not part of the domain won't trust the CA until you import the Root CA's Root Certificate and set the computer to trust it.

The main limitation of any PKI system is in key distribution. There's some fascinating historical stories about key distribution issues (for instance, the German Enigma system during WWII). It is entirely possible to handle email signing and encryption outside of your network with Active Directory. The problem is that your users will have to send a key to people that the email in order for the email to be decrypted. The problem is that this very quickly becomes a logistical nightmare (not to mention the potential security issues of having your Root CA key plastered all over the internet). This is where the third party apps come in to play.

PGP's email system system provides email encryption by capturing email traffic that goes outside the network and storing it, encrypted, in a secure reception area that is accessible to the outside world. After the email is sent and stored by PGP a notification email is sent to the recipient, giving them instructions on how to log in to the secure repository and read the email. Recipients set up an account on the PGP mail repository server and read any encrypted mail without the mail actually leaving your network.

RSA's key distribution system does something different. I haven't actually used their solution before, so I don't know exact details. From their marketing materials, it looks like it provides secure key distribution through a web enrollment system similar to AD CS, but usable outside a domain. You'll probably need to contact RSA to get more specific information. Here's the website for more info: http://www.rsa.com/node.aspx?id=1224

LVL 44

Adam BrownSr Solutions ArchitectCommented: 2010-09-03

In windows 2k8, you'll want a Certificate Services server to handle most of the work. Certificate signing and encryption for email will only work internally for the most part. If you want an encryption system for email going outside your network, you'll want to look at third party solutions like PGP. Realistically, you'll need to determine how far reaching you want your encryption and authentication to be. AD CS is great internally, but it gets really troublesome when you go outside the LAN/WAN, because certificate distribution is limited to the domain. Same thing for web site authentication. It's a piece of cake and almost just works right out of the box if you're entirely internal. The second you break across that public/private line it gets troublesome. RSA makes a good key management system for distributing keys outside a private network, and I think there are a few other companies that do as well.

Just to sum up my recommendation on how to move forward, take a look at what you want to do. If you need to manage certificates outside your network, you should look into third party solutions. If it's going to be mostly internal, or if any part of the requirement is internal only, you'll want to allow AD CS to handle that portion because of the auto-enrollment features built in to Windows.

LVL 2

itsecalertAuthor Commented: 2010-09-04

I see, so I will probably need to obtain a CA for Each of my domain controllers from a third-party to begin issuing certificates at least for inside applications and services.

If we want to do email encryption or digital signatures then the RSA route is your recommendation or that of PGP, correct?

One of the key factors that triggered this reearch was the adding a few services to be reached from the DMZ and be able to authenticate domain users from home or where ever they they can be. We already have servicea with their own certificates (webmail, citrix access, etc) which are at the DMZ but get the users authentication bounced off AD.

Thanks for your input.

LVL 2

itsecalertAuthor Commented: 2010-09-07

Thanks for your detailed comment on this. I was looking at any other experts comments but I guess, even after the question was moved to another group, nobody else has an input for this.

Thanks much, I will focus my research on this and seek a direct target solution.

Definitely will do an in-house CA server for all our internal needs, per all my current readings online. R$A is out of the question, budget-wise.

Thanks a bunch.