Certification Authority (CA) setup - tips and tricks

This presumes you already set up the root CA, which is usually pretty straighforward but I will write an article on full CA setup sometime in the future.  Setting up the root CA offline is best for additional security.  Never install a CA on your Domain Controller!  You will have problems down the line when you need to run dcpromo to demote it.

Typically you should select Standard Edition OS (2003 or 2008) for your root and install as a stand-alone CA.  It should not be joined to the domain.

This also presumes you have set up a Subordinate CA (Sub CA) and created the certificate signing request (CSR) file.  This is usually going to be an Enterprise CA, but many things will work similar as a Standalone CA, it just won't have AD integration features like autoenrollment.

The Sub CA should normally be an Enterprise Edition OS (2003 or 2008) and installed as an Enterprise Subordinate CA, unless you have specific reasons to not do so.

For high security, it is best to keep your CA private key on a FIPS-140-x level 3 device.  For lower cost solution for your root, a smartcard or smart USB token may be used, however for an online issuing subordinate CA this will likely be too slow to sign the many certificate request that come through.  An HSM (High Security Module) is expensive (thousands of dollars, typically), but will protect your CA private key like nothing else, so even if the CA box is compromised the private key is still safe.  An HSM is also much faster to do the crypto processes, so is appropriate for an issuing CA (and offline root).

For a cheaper method, Virtual Machines are nice so that you can store the CA images on a removable hard drive and physically remove the offline root CA when not in use to issue a CRL or renew certs.  This is adequate for most small to medium sized PKIs.  Making a copy of the image file to a second disk to offsite makes for a quick and easy disaster recovery plan.

Import root ca cert to sub CA:
1. Copy root CA cert to subordinate CA
2. Right click cert - Install Certificate
3. Follow the wizard using defaults.
4. Open Certificates MMC snapin
5. Open Trusted Root Certification Authorities store
6. Verify your root cert is listed here
7. If not in root store, install cert again, this time choosing to manually select the store, browse, checkmark box for 'Show physical stores' and select the Trusted Root Certification AUthorities" store and finish the wizard.  Check certs MMC again.

Determine CRL Distribution Points (CDP):
1. Doubleclick the Sub CA cert to open it up
2. Select Details tab
3. Highlight CRL Distribution Points
4. Take note of each listing in the white box in the bottom half of the window.
5. Open %systemroot%\system32\certsrv\certenroll directory on root
6. Copy *.crl to each of the CDP locations from #4 - you will need to figure out what servers/folders to copy to.
7. If there is an LDAP link, if the root is joined to domain do this from the root, otherwise copy the CRL to any domain joined box (workstation or server) that has certutil.exe installed (present in 2003/Vista/2008, need to install from 2003 adminpak for XP).  Run command 'certutil -dsPublish %filepath%\%CRLFile%'

Copy cert to Authority Information Access (AIA):
1. Doubleclick the Sub CA cert to open it up
2. Select Details tab
3. Highlight Authority Information Access
4. Take note of each listing in the white box in the bottom half of the window.
5. Open %systemroot%\system32\certsrv\certenroll directory on root
6. Copy *.crt to each of the AIA locations from #4 - you will need to figure out what servers/folders to copy to.
7. If there is an LDAP link, if the root is joined to domain do this from the root, otherwise copy the CRL to any domain joined box (workstation or server) that has certutil.exe installed (present in 2003/Vista/2008, need to install from 2003 adminpak for XP).  Run command 'certutil -dsPublish "%filepath%\%RootCertName%.crt" RootCA

*Note: if none of these locations are publicly accessible for the AIA and CDP, you may want to consider adding this now before you get too far.  If this applies, let me know and I can give instructions for that as well.

Install sub CA cert:
1. Copy issued certificate from root to sub.
2. Run command 'certutil -installcert %path%\%subcacertfile.crt%'
3. net start certsvc
4. Open Certificate Authorities MMC
5. If it opens up without warning, you're good.

Enable SAN:
SAN (Subject Alternative Name) allows for multiple names in the same cert.  This is nice so you can include the hostname, dns name, and ip address in the same cert so you can troubleshoot issues and still connect securely.  There are also some situations that using a SAN makes life a lot easier.
*Note: A quirk of SAN certs is that the subject name needs to be entered as one of the SAN values as well, otherwise it will usually not get recognized.  Also note that not all apps support SANs, but most do.  If you use RDP gateway, make sure you are running current version RDP 6.1 to support SAN - this was included in last SP for each OS.
On the sub CA:
1. Open cmd and enter following commands exactly:
2. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
3. net stop certsvc
4. net start certsvc

Repeat for sub CA to publish CRL and sub CA cert to CDP and AIA locations.
1. Open Issued Certificates folder
2. See if there are any certs that autoenrolled yet.  If not, issue a test cert to view its details to find the CDP and AIA.
3. Repeat above steps.

To issue a cert manually:
1. For direct request, skip to #4.  For an offline request (common for certs that you wish to authorize and process manually -common for web server certs, EFS DRA certs, code signing certs) - Create the Certificate Signing Request (CSR) file from the requesting server.  This is well documented for how to do this in IIS - note different between IIS6 and IIS7 so search your version.
2. Verify the CSR file isn't corrupt - 'cerutil -dump %CSRfile.csr% | more' - you should see the CN=servername.domain.local there.  If it comes out all looking like hex, then it is corrupt.  If it is nested fields then it is fine.
3. Open the CSR file in notepad

4. Go go http://CAServerName/certsrv web page - note you need ASP enabled for this
5. Choose first option to request, then either 1st option for a user to issue their own cert without a CSR, or 2nd option to use the CSR file.
5a. For direct request (1st option/1st option) fill out the form and issue cert, make sure to install at the end.
5b. For offline request (1st option / 2nd option) - copy entire text from CSR in Notepad (from ---begin cert-- to ---end cert--- including those lines) and paste into the first large box, select your template, if you wish to add a SAN use the attribute field.  SAN:DNS="server1.domain.com"&DNS="server1"&DNS="alias"&ipaddress="192.168.0.1"&email="I use the email field for notes for renewals - will show up in san as RFC822 and doesn't affect anything"


For publishing a CRL, I set up a script and run it as a sceduled task.
1. Open CA MMC
2. Expand CAName
3. Select Revoked Certificates
4. Take note of the CRL publication interval -adjust if desired.  Root can be longer up to a year for offline CAs - since this is online I suggest going for 3 months max, sub CA shouldn't be longer than a month - for higher volume CAs I suggest a week or less.

So you will want to publish your CRL ahead of time to give yourself some overlap in case you have problems you have extra time to troubleshoot instead of a few hours.  Some day you will thank me for this.  My two suggestions are either 1/2 the validity period or one month before publication.

So for the root, if configured for 3 month validity period, issue every 2 months.
For the sub CA, if configured for 1 month, issue every 2 weeks (or first and third Tuesday of each month).

1. Create a new .bat on root CA:
certutil -crl
net use z: /delete
net use z: \\share\to\subCA\certenroll
copy %systemroot%\system32\certsrv\certenroll\*.cr* z:
net use z: /delete
:If root and sub CA AIA & CDPs are the same location, done.  if different, map again to each CDP and AIA location and copy to each.

2. Create a new .bat file on sub CA:
certutil -crl
net use z: /delete
net use z: \\share\for\CDP
copy %systemroot%\system32\certsrv\certenroll\*.cr* z:
net use z: /delete

3. On the sub CA only create a 2nd .bat for issuing delta CRL:
certutil -crl delta
net use z: /delete
net use z: \\share\for\CDP
copy %systemroot%\system32\certsrv\certenroll\*.cr* z:
net use z: /delete

3. Configure scheduled task to run the first batch file according to the timeline determined above.

4. Configure another scheduled taks to run the delta batch file daily or every few hours.  The delta CRL is like a differential CRL - it includes all the updates since last base CRL and is much smaller - if it is not published your PKI will not fail like it will if base isn't published.

Note the *.cr* will copy the .crl files and .crt files - so someday when you reissue your CA certs in a few years you can just run that script and be set if the CDP and AIA are in the same base locations.  The root will copy to the sub CA, the sub CA will copy its own and the roots stuff out.


Lastly - backup your CA.

1. GUI method - do this first time on each CA.  Open CA MMC
2. Right click CAName - All Tasks - Backup CA
3. Follow the wizard, select boxes for include private key and Ca database, do not do incremental.
4. Copy the saved files to a flash drive and keep it in a static bad and locked up.  Whenever you reissue the CA certificates, update this flash drive.  Good idea to have 2 and have one offsited.

Now make a full system backup, including system state.  Do this regularly - the root you can do less frequently since all it issues is the sub CA cert.

For regular backup of the CA database on the sub CA, create another scheduled task:
certutil -backupdb %path%


Lastly, create an outlook calendar reminder to remind you to renew the CA certificates.  Open each cert to determine its validity period, renew the CA cert about a year before it expires.

You should be good to go with the basics now.

   
You will also want to deploy your root cert to your workstation and server boxes via GPO:
http://technet.microsoft.com/en-us/library/cc738131.aspx

For those that are not connected to AD (e.g. external partners, employees working from home) refer to the steps that you used to import the root cert into the sub CA.

In the same area of GPO, you can also set up various autoenrollment settings and such.  You will also need to configure autoenrollment on the templates too.

To create a new template:
1. Open Certificate Templates MMC
2. Locate a similar template - right click - duplicate
3. Configure as desired.
*note: you need to way for next AD replication cycle for template changes to occur

Issue a template to a CA:
*Note: requires Enterprise edition OS set up as an Enterprise CA (root or sub CA)
1. Open CA MMC
2. Expand CAName
3. Right click Certificate Templates - New - Certificate Template to Issue...
4. Select template
*note: you need to way for next AD replication cycle for template to become available on CA

To remove a template from a CA:
1. Open CA MMC
2. Expand CAName
3. Right click Certificate Templates
4. Select template and right click - Delete
*note: deleting a template in CA MMC will only remove it from being issued to the CA, it will still exist in AD to issue again.
*note: to delete a template from AD, remove from CA first, then open Cert Templates MMC and delete it there.

   
Tools to get familiar with over time:
1. Certutil.exe - native to OS after XP
2. Certreq.exe - native to OS after XP
3. MMC snap-ins: Certificates (certmgr.msc), Certification Authority (certsrv.msc), Certificate Templates (certtmpl.msc), PKI Health Tool (2003) / Enterprise PKI (2008) (pkiview.msc - for 2003 is in the resource kit, 2008 its native)
4. OpenSSL - free open source software that comes in very handy for a number of things when you can't figure out a good way to do it with Windows native tools.
Windows download version here:
http://gnuwin32.sourceforge.net/packages/openssl.htm
Documentation here:
http://www.openssl.org/docs/

If you ever plan to do EFS (encrypted file system) you must take time to really understand it. Period.  There are a lot of caveats.  You can search my previous posts for some help there, and read this:
http://technet.microsoft.com/en-us/library/cc162806.aspx
EFS is good for individual file encryption.  If you are looking for whole-disk encryption (e.g. for laptops), then consider something else like BitLocker (Vista) or some other products like WinMagic or TrueCrypt.  Again, read up on the product so you understand how to recover.

Also a side note for DC certs (Domain controller Authentication and Directory Email Replication) - these are normally good for 1 year and will renew 6 weeks ahead of time.  After a DC renews its cert, you must reboot the DC before the old one expires so it stops using the older cert from cache.  Domain Controller template is usually not used unless you are still running in 2000 native mode.

If you get event ID 13 from DC autorenewal, you may need to add the DC group for each domain to the CERTSRV_DCOM_ACCESS group - this is a local group on the sub CA box unless you installed the CA on a DC, then it is an AD group.  Again, hopefully you didn't install on a DC as that is a bad thing down the road.