RWPT + PKI Hints - BAD TROUBLESHOOTING 101 (part 2 of many) Certification Authorities on a Domain Controller
I blogged last week on User Profile troubleshooting and that was one of my biggest pet peeves. Now it is time for my BIGGEST pet peeve. I almost feel bad that I am on entry number 4 of this blog and I can't save this one for later, but I need to hopefully spread the word and stop the bleeding.
This really isn't much of a blog entry on troubleshooting, but often times I have seen people stand up a temporary CA to get things like Live Communications Server or Outlook Web Access to work, so I guess technically you could look at it that way. I don't know where it started or who first said it was OK, but I am going to say it now... DO NOT INSTALL AN ENTERPRISE ROOT CA ON A DOMAIN CONTROLLER. This is a bad idea. A really bad idea. First of all, if I was a hacker and I wanted to target a server, I would target a DC. If I was a mean hacker and I wanted to send e-mail that was digitally signed by the CEO saying that everyone is fired, I would be happy to know that the DC I just attacked also had the private key of the root CA on it. That only touches the surface of what you could do if you had the private key. And there would be no means of revocation. Second of all, the biggest dependency of the Certificate Service is the computer name. There are hooks in DCPromo.exe to check to see if the computer is a CA. You would have to backup the CA using the CA snap-in, demote the DC or decommission the DC and move the CA backup to a server with the same name (How to move a certification authority to another server - https://support.microsoft.com/default.aspx?scid=kb;en-us;298138). Now, what if the DC goes down? I hope you have a backup (https://blogs.technet.com/shawnrab/archive/2006/05/10/427905.aspx) because if we go into Directory Services Restore mode, we can't take a backup of the CA's private key. With no backup of the CA, if the computer is toast, so are the certificates you issued.
The Microsoft Best Practice of a three-tier CA with an offline root is the way to go. And with support for Certificate Services on Windows Server 2003 SP1 on Virtual Server 2005 R2, there's really no excuse. If you have an enterprise subordinate CA that issued 100,000 certificates that is compromised, all you have to do is revoke one single certificate to deem the CA and the certificates it issued inoperable. If you add a Hardware Storage Module (HSM) for the private keys, you're in better shape. You'll thank me. Your auditor will thank me. Your CEO will thank me. OK, maybe not - you've likely made any potential problem go away.
Certificate Services and PKI is 95% planning and 5% doing. If you stand up a temporary CA for one or two certificates as a short-term solution, I am *almost* OK with that as long as you come in behind that CA with a full-blown PKI and you don't install the CA on a DC. With the guidance of the Best Practices for Implementing Windows Server 2003 PKI (https://technet2.microsoft.com/WindowsServer/en/Library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx?mfr=true) and my two three-tier webcasts (https://support.microsoft.com/default.aspx?kbid=896733 and https://support.microsoft.com/default.aspx?kbid=896737), you could set up a temporary three-tier PKI using Virtual Server 2005 R2 and Windows Server 2003 SP1 and have quick and cheap practice for a full-blown PKI.
You can install a parallel PKI to the temporary PKI and have it work almost independant to the existing PKI. The only thing they will share is the Certificate Templates, which are in the Configuration NC in Active Directory.
Once you are ready to decommission the temporary PKI, you can use a quick command to remove the remnants of the temporary PKI from Active Directory. For a CA with friendly name Temp-CA-1, you can run this command: certutil.exe -dsdel Temp-CA-1
So all in all, just say NO to a CA on a DC.
This posting is provided "AS IS" with no warranties, and confers no rights.