Microsoft PKI Planning and Deploying Certificate Services

KB ID 0001309

Problem

“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!

Solution

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 tier 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.

Two and Three tier PKI

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.

001-root-ca-capolicy

Sample Offline Root CA CAPolicy.inf

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
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.

Add Role

Role Based >  Next > Select the local server > Next  > Select ‘Active Directory Certificate Services’ > Add Features  > Next.

Add Certificate Services

No other features are required > Next > Next > Certification Authority > Next.

Deploy Offline Root CA

Next > Next > Close.

Certificate Services Wizard

Configure Active Directory Certificate Services.

Configure Certificate Services

Accept the default (local administrator) > Next > Certification Authority > Next.

Certificate Services Offline Root

Stanalone CA > Next > Root CA > Next.

Stanalone CA

Create a new private key > Next > Make sure the hash algorithm is SHA 256 (NOT SHA1) > Next.

Offline Root CA Sha256

Give the CA a sensible name > Next > Set the validity period (as mentioned above I’m going for 20 years) > Next.

Offline Root CA Name

All the default can now be accepted > Next > Next > Close.

CA Database location

Launch the Certification Authority Management console and make sure we have a green tick.

Certificate Services Manager

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

Offline Root CA Settings

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.

Copy C:\Windows\System32\Certsrv\CertEnroll\*.* A:\

copy CRL and CA Cert to Floppy

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

Note: These command publish the CA Certificate, (and its CRL) into Active Directory. You can see where, if you open the path shown in the example in ADSIEdit.msc (CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain})

Publish Offline Root To AD

See Microsoft PKI Planning and Deploying Certificate Services Part 2

Related Articles, References, Credits, or External Links

NA

Author: PeteLong

Share This Post On

26 Comments

  1. jajaja very funny intro, but very true I fall in it :D,
    Thanks for this serie about CA and congrats awesome site.

    Post a Reply
  2. Can you elaborate a little on what the last set of commands that we run on the domain joined server are doing?

    Thanks!

    Post a Reply
  3. Can you confirm if in your capolicy.inf for offline RootCA the OID needs to be specified? Or is yhis only specified on the issuing CA (online subCA in a 2 tier pki setup).

    Thank you!

    Post a Reply
    • You specify it on ANY CA where you want to manipulate how it is installed 🙂

      Pete

      Post a Reply
  4. Pete,
    Great documentation! Just have a question in regards to the OID for the RootCA as well. Do I need to get a registered Public OID or use the pre-assigned OID built into AD CS?

    The purpose of our deployment is to leverage 802.1x authentication for wireless and wired networking. So, at this time, we’re not needing anything external to our network. But, there’s always a possibility that something could change in the future. If we go with the private OID, is this something that can be altered in the future if we were to get a Registered Public OID?

    Post a Reply
    • Hi, Thanks for the feedback!
      Great Question: The only practical use I’ve ever had for an OID, is when specifying a particular certificate for something like 802.1x or for selecting the correct Certificate for things like Cisco AnyConnect certificate selection. So I’m guessing that’s why you are asking? Practically unless you are ever going to purchase a SubCA signing cert from a public CA this will never really be a problem, as your RootCA will always be you internal one. The only time you would ever need to worry about OIDs is is you had multiple certificate chains and your auto authentication method didn’t know which one to pick, (so it would probably either pick the first one, or (as in Cisco’s case) would prompt the users which one to present. Unless checking the OID was built into the authentication process.

      I hope that makes sense :

      Pete

      Post a Reply
  5. Hello Pete,

    thanks for the great article.

    We want to configure Two – Tier PKI in our Enviroment first to enable the LDAPS on Domain Controllers.
    I have checked your CAPolicy.inf here, where is the OID= 1.2.3.4.1455.67.89.5.

    On some another articles, I have found that the Server Authentication / Kerberos Authentication OID= 1.3.6.1.5.5.7.3.1.

    Do I also need to put the 1.3.6.1.5.5.7.3.1 to the CAPolicy.inf also or it is not necessary. Can you explain it a little bit more?

    Thanks in advance and best regards!

    Post a Reply
    • Firstly Search my site theres some considerations you need for LDAPS and if you get them wrong toy have to COMPLETELY remove and reinstall certificate services!

      Post a Reply
    • As for the OID, that’s the Microsoft OID, you can “if you wish” register you own.

      Post a Reply
  6. Hi! I WAS a ‘Next > Next > Next > Job Done Person’ and now want to do it right. I already have a CA server in the domain. What issues would arise building the offline root and adding it to the existing setup?

    Post a Reply
    • It would be a completely separate chain, so you will need to maintain both, or remove the existing one (if you are 100% sure nothing is using it)

      Post a Reply
      • Hello Pete,

        I’ve read a few of your articles here. They’ve all been very helpful. Thanks.

        I’m in the same boat as Paul. I have a single CA in my domain but would like to implement a 2 tier system. Im guessing the proper steps would be to

        1) setup the 2 tier system as you describe in parts 1 – 3
        2) issue new certificates to those computers in need from the new system
        3) revoke the older existing certificates from the single CA setup
        4) remove CA services from the single CA
        5) have a good cup of coffee to celebrate

        Did I miss anything?

        Post a Reply
        • If you want to switch to ‘two tier’ simply issue the new CA server with a SubCA Cert – then use that when you setup Certificate Services?

          Post a Reply
          • So basically just make my existing server the defacto root server in the new 2-tiered setup, which I will use to install a cert on a new SubCA and then ultimately take my existing server offline until and unless needed again? That sounds like an easier approach. Do I understand that correctly?

          • Spot on!

  7. “The main advantage of three their PKI is,”
    I thought that was a Yoda joke, then I realised it was just an auto-correct typo.

    As always, great article.

    Post a Reply
    • Ha! Well spotted buddy – fixed.

      Post a Reply
  8. Hi, great tutorial.
    One question, since this server will be put offline, shouldn’t we increase the CRL publication interval to 20 year too?
    Thanx

    Post a Reply
    • Good Q!
      Typically (unless you need to create a new Sub CA after 26 weeks) the CRL for the Root CA is ignored.

      Post a Reply
  9. When you say take the last files (Root Cert and CRL) to a domain joined machine. In your case you are referring to your WebServer, correct?

    Post a Reply
    • No any domain joined machine, you are just publishing those file into AD

      Post a Reply
  10. I’m guessing you have to setup an IIS site on something to host the CRL right?

    Post a Reply
  11. Hi Pete. I have an inherited PKI solution on the next next next finish solution. We are looking to add a Sub CA into the mix now but wondering what consequences if any it will have on existing assigned Certs? we are going to use this CA for 1 or 2 Cert authentication methods and don’t want everything on the root CA (inherited)
    Thanks

    Post a Reply
    • Adding a SubCA should be OK – just check what the subCA certificate template is set to (lifetime wise) because I think it will be quite short by default.

      Post a Reply

Leave a Reply to PeteLong Cancel reply

Your email address will not be published. Required fields are marked *