Fellow #VFD3 Delegate and Chicago-area vExpert Eric Shanks has recently posted two great pieces on how to setup an Active Directory Certificate Authority in your home lab environment.
Say what? Why would you want the pain of standing up some certificate & security infrastructure in your home lab?
Eric explains:
Home Lab SSL Certificates aren’t exactly a high priority for most people, but they are something you might want to play with before you get into a production environment.
Exactly.
Security & Certificate infrastructure are a weak spot in my portfolio so I’ve been practicing/learning in the Daisetta Lab so that I don’t fail at work. Here’s how:
As I was building out my lab, I knew three things: I wanted a routable Fully Qualified Domain Name for my home lab, I was focused on virtualization but should also practice for the cloud and things like ADFS, and I wanted my lab to be as secure as possible (death to port 80 & NTLM!)
With those loose goals in mind, I decided I wanted Daisetta Labs.net to be legit. To have some Certificate Authority bonafides…to get some respect in the strangely federated yet authoritarian world of certificate authorities, browser and OS certificate revocations, and yellow Chrome browser warning screens.
So I purchased a real wildcard SSL certificate from a real Certificate Authority back in March. It cost about $96 for one year, and I don’t regret it at all because I’m using it now to secure all manner of things in Active Directory, and I’ll soon be using it as Daisetta Labs.net on-prem begins interfacing with DaisettaLabs.net in Azure (it already is, via Office 365 DirSync, but I need to get to the next level and the clock is ticking on the cert).
Building on Eric’s excellent posts, I suggest to any Microsoft-focused IT Pros that you consider doing what I did. I know it sucks to shell out money for an SSL certificate, but labwork is hard so that work-work isn’t so hard.
So, go follow Eric’s outline, buy a cert, wildcard or otherwise (got mine at Comodo, there’s also an Israeli CA that gives SSL certs for free, but it’s a drawn-out process) and stand up a subordinate CA (as opposed to a on-prem only Root CA) and get your 443 on!
Man it sucks to get something so fundamentally wrong. Reader Chris pointed out a few inaccuracies and mistakes about my post in the comments below.
At first I was indignant, then thoughtful & reflective, and finally resigned. He’s right. I built an AD Root -not a subortinate as that’s absurd- Certificate Authority in the lab.
Admittedly, I’m not strong in this area. Thanks to Chris for his coaching and I regret if I mislead anyone.
Wilson.tech 
Yes, you’re correct. I built a root CA for the Active Directory domain, not a subordinate. Thankfully it wouldn’t let me as you pointed out. Just checked.I’ll correct the post and cite you.
“My basic point is a wildcard certificate is not a subordinate CA. It’s an end user/device certificate.”
I grant that and wish I had been more clear. I did this back in March/April and I remember being a bit confused; I had dlab.net as an AD domain in the lab, but I had a longer-term goal of establishing various CNames.daisettalabs.net on the web, or into Azure etc. So I bought a wildcard ssl for that purpose.
LikeLike
No, I didn’t miss your point. They both may have the same name from a DNS point of view, but you cannot build a subordinate CA from an externally purchased certificate such as your wildcard cert. The process of building a sub CA in the Windows server 2012 wizard requires a root certificate in AD or the local cert store in Trusted Certificate Authorities. Once you set the sub up, you then have to get it’s CSR signed by the root in order to enable the sub to work, otherwise the certificate services won’t start (and you can’t issue certificates to your domain).
My basic point is a wildcard certificate is not a subordinate CA. It’s an end user/device certificate.
LikeLike
Thanks for the comment.
Not confused at all. I think you missed the point that my Windows Active Directory domain is daisettalabs.net.
And the domain I purchased is also named daisettalabs.net.
That’s why I built a subordinate CA, not a root.
I’m using each piece of infrastructure in its appropriate role/place. May have not been clear on that.
LikeLike
You are confusing several aspects of certificates and CAs in your blog post. First, you purchased a wildcard cert, which is fine for lab use (although generally frowned upon see http://www.eweek.com/c/a/Security/The-Risks-In-Wildcard-Certificates/ ). This is not a subordinate CA, it is a certificate that allows external third parties to trust your SSL/TLS site by verifying the certificate against a public trusted CA. Eric’s article describes how to build an internal CA using Win Server 2012. He sets up both a root and subordinate CA. The subordinate CA is used to issue certificates to end users or servers. Due to it being only trusted by machines on Eric’s network, it’s not suitable for public use generally. More critically from a security point of view (and good on Eric for pointing this out) the private keys used to setup the CAs are not secured by an offline root or HSM. This leaves the systems vulnerable to attack and the whole CA to compromise.
An excellent blog series on setting up the Win Server 2012 CA is here http://blogs.technet.com/b/yungchou/archive/2013/10/21/enterprise-pki-with-windows-server-2012-r2-active-directory-certificate-services-part-1-of-2.aspx
The more general PKI blog is here http://blogs.technet.com/b/pki/
I also highly recommend Andrzej’s blog on the do’s and don’t of PKI http://kazmierczak.eu/itblog/2012/08/22/the-dos-and-donts-of-pki-microsoft-adcs/
LikeLike