KB ID 0001309 Dtd 14/05/17
“I don’t know what it is about Certificates, I just don’t like them, I don’t understand them, and I don’t like working with them”
I hear this a lot, In fact I heard it this week, and as I’m usually the ‘go-to-guy’ for certificates and PKI, it winds me up! IT pros take the time to learn concepts like DNS, DHCP, Kerberos etc. But mention Certificate Services and heads disappear below monitors and silence decends.
OR WORSE: Someone adds the role, clicks Next > Next > Next > Job done! Lets have tea and medals!
So in typical PNL fashion lets simplify everything, get everyone on the same page. And most importantly, lay out how to do it so I don’t have to do it for you!
To design PKI well, you need to decide if you want a two or three tier PKI environment.
What can’t I just have one CA Server? (Hmm your the Next > Next > Next > Job Done Person Eh?) Well you can! But if that one server breaks, (or get compromised.) Then you are in trouble. Plan you deployment properly and save yourself a headache.
Two Tier Or Three Tier PKI? That’s your call, The main advantage of three their PKI is, if one of your issuing servers, is compromised, you don’t need to bring the offline Root CA back online to re-issue its certificate. I have a client who have an issuing server in their DMZ so this was a good fit for them. For most domains Two Tier is the best option.
So I can only have one issuing Server? No, I just put one on the diagram for simplicity, you can have 1, or 100, or 1000, it’s up to you.
Do I need CRL (Certificate Revocation List) and/or OCSP (Online Certificate Status Protocol) On a Separate Server? Strictly speaking No, but it’s considered good practice, and if you need to advertise a CRL externally, it is more secure.
PKI Terminology Differences
You will notice I’ve mentioned a Root CA, an Intermediate CA, and an Issuing CA. This is to better explain the architecture and define a difference between an Intermediate CA, and an Issuing CA. Microsoft does not care,.Both of those servers are SubCA servers in Microsoft speak.
Deploying an Offline Root CA
Whichever architecture you choose this will be your fist step. The offline Root CA is a non domain joined machine, its sole job is to issue SubCA certificates to your intermediate CAs (three tier PKI), or issuing CAs (two tier PKI). When you have finished you power off the Offline Root CA and keep it off.
Note: In my example I want my Root CA Cert to last 20 years
Before You Install Anything: Create a CAPolicy.inf file you can edit it with notepad. You may want to change the validity period, you certainly will need to change the legal notice URL (more on this later) to your own domain FQDN (Note: If you need people outside your organisation, (either at a partner, or just someone the public internet) to see that, ensure that URL is addressable.
Sample Offline Root CA CAPolicy.inf
[Version] Signature="$Windows NT$" [PolicyStatementExtension] Policies=InternalPolicy [InternalPolicy] OID= 184.108.40.206.14220.127.116.11 Notice="Legal Policy Statement" URL=http://pki.cabench.com/pki/cps.txt [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 CRLPeriod=weeks CRLPeriodUnits=26 CRLDeltaPeriod=Days CRLDeltaPeriodUnits=0 LoadDefaultTemplates=0
Save the CAPolicy.inf file to C:\Windows, Make sure it’s not called Capolicy.inf.txt, (or it wont work).
Launch Server Manager > Manage > Add Roles and Features.
Role Based > Next > Select the local server > Next > Select ‘Active Directory Certificate Services’ > Add Features > Next.
No other features are required > Next > Next > Certification Authority > Next.
Next > Next > Close.
Configure Active Directory Certificate Services.
Accept the default (local administrator) > Next > Certification Authority > Next.
Stanalone CA > Next > Root CA > Next.
Create a new private key > Next > Make sure the hash algorithm is SHA 256 (NOT SHA1) > Next.
Give the CA a sensible name > Next > Set the validity period (as mentioned above I’m going for 20 years) > Next.
All the default can now be accepted > Next > Next > Close.
Launch the Certification Authority Management console and make sure we have a green tick.
Now we need to ‘Stamp’ Certificates issued by this CA Server with some domain information, but we have no connection to the domain, so we need to do it manually. Open an administrative command window and execute the following commands;
Note: I want my SubCA certificate to be valid for 15 years, if you want longer/shorter then adjust the figures below
Certutil –setreg CA\DSConfigDN “CN=Configuration,DC=cabench,DC=com” Certutil –setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.cabench.com/pki/%1_%3%4.crt” Certutil –setreg CA\CRLPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.cabench.com/pki/%3%8%9.crl” Certutil –setreg CA\CRLPeriodUnits 52 Certutil –setreg CA\CRLPeriod “Weeks” Certutil –setreg CA\CRLOverlapPeriodUnits 12 Certutil –setreg CA\CRLOverlapPeriod “Hours” Certutil –setreg CA\ValidityPeriodUnits 15 Certutil –setreg CA\ValidityPeriod “Years” Certutil –setreg CA\AuditFilter 127 net stop certsvc net start certsvc Certutil –crl
Now my Offline Root server is not connected to a network, (because that’s best practice,) and as it’s a virtual machine the only way to get files from it is to use a virtual floppy drive, Im going to copy both my Root CA Certificate and CRL file to my floppy drive.
Now TAKE THESE FILES TO A DOMAIN JOINED MACHINE, and execute the following commands.
cd a:\ certutil -dspublish -f 01-Root-CA_ROOT-CA.crt RootCA certutil –addstore –f root 01-Root-CA_ROOT-CA.crt certutil –addstore –f root ROOT-CA.crl certutil -dspublish ROOT-CA.crl
Related Articles, References, Credits, or External Links