Windows 2008 PKI implementation

Going to implement PKI in 2008. Therefore I'm looking for a "best practise" guide.
We want an offline Root CA.
Who is Participating?
stebysheAuthor Commented:
Yes, I have seen that article. But isn't that just a solution for the case "Hosted Messaging and Collaboration" ?

The say that:
"In a full production environment, we recommend that you deploy a rooted trust model with an offline Root Certificate Authority. In a rooted trust model, the root certificate authority (CA) is the trust anchor and has a self-signed certificate. If needed, the root CA issues a certificate to all direct subordinate CAs, which in turn issue certificates to their subordinate CAs. A subordinate CA is trusted cryptographically, based on the signature of its parent."

...and this is what I'm looking for ...
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

stebysheAuthor Commented:
...not the article I'm looking for.
ParanormasticCryptographic EngineerCommented:
Hopefully my article and this post fits the bill.  This one covers the subordinate:

For the root, I haven't made up an article yet, so I'll type this up and this will become the root article I've been meaning to write...

- Don't join to the domain, or to the network at all for that matter.
- For the offline root, Standard edition OS is fine unless you need to do Role Separation, then you need Enterprise Edition OS.  Enterprise Ed. is recommended for the online issuing subordinate.
- For activation, you will need to call it into Microsoft and they will give you the activation code.  If you have a license server for a volume license, they may be able to assist you with that also.
- Make a capolicy.inf file and store it in %systemroot% (e.g. c:\windows).  Filename must be exact (i.e. capolicy_root.inf is not valid).  See the following post for example.
- With 2008, don't trust that the capolicy got everything.  Double check your CA cert before moving forward.  If you need to manually edit the registry, you may do so at:
Registry values are named the same as in capolicy.inf.
- If you need to reissue your root CA cert, you can do so with the following cmd:
certutil -renewCert reusekeys
This will use the same keyset, so if anything was signed those signatures will still be valid.  If you need to change the key strength, then omit the 'reusekeys' portion, which a new keyset will be made and you will need to re-sign all certs issued to all lower tiers.

Ok, for the actual install:
- Install OS and secure that according to your company standards for high security.
- Create a backup local admin account in case your main account gets corrupt.
- If you are using an HSM, follow manufacturer directions to create the keyset and issue the smartcards to protect the keyset.  If not, omit this for now.  If so, read this:
- Install AD CS role - this should already populate values based on the capolicy.inf file, but please do validate that they are what you want!
Start page 23:
- Select - Standalone CA - Root CA - Create new private key (unless using HSM) - default CSP, key length 2048, signing - SHA1 (if all systems are XP SP3 or later or vista+ then can do SHA-256), it is recommended to checkmark the "use strong private key protection" box so it prompts for a PIN every time private key is accessed (to start certsvc and reissue keyset) just note you need to log in after rebooting to start certsvc... - Common name = whatever you want, be descriptive e.g. "Company XYZ Root CA" - the DN should be the DN for your AD - for an example take a normal server and view it in dsa.msc for its full distinguished name - log file default locations are fine, if you have a D: drive you may want to put them there but not a big deal - finish the wizard.

-I would recommend staying away from higher than 2048 certs unless you are running all Vista/2008/Win7  or non-MS OS that support ECC (aka Suite B algorithms, CNG, Discrete Algorithms, ECDH, ECDSA).  Generally I would recommend 2048 bit RSA keyset.  If you can run ECC then do so, it cuts down on CPU - ECDH with a 256 bit key is good and well supported.
- Open the CA MMC - properties of CAName and validate settings, check against the capolicy.inf file to make sure those got applied.  You may want/need to change the CDP and AIA locations on the Extensions tab.  If you need more info on this, let me know.
- Once everything is they way you want then issue a CRL - CA MMC - expand CAName - rightclick Revoked Certificates - All Tasks - Publish.  Copy the CRL & server cert to a flash drive (both are normally in %systemroot%\system32\certsrv\certenroll directory).  Copy these to the issuing subordinate and install them - manually select - browse - checkmark 'show physical stores' expand Trusted Root Certificaton Authorities - Local Computer (for both crl and cert files).  Then follow my article on the sub CA - options should be similar to above.

As an alternative, you can also view this for a non-MS CA option by using XCA - this is a little bit more techincal tho, but you can do it on a linux box or any random OS.  Just do this for the root...
ParanormasticCryptographic EngineerCommented:

Signature="Windows NT$"
; Configuration for Root CA
; This file belongs in: %systemroot% directory named capolicy.inf
; Usage is defined at
; 2008 R2 at
; ProviderName="RSA#nCipher Security World Key Storage Provider" use only with HSM
DiscreteSignatureAlgorithm=1      ; use 0 if supporting win2k or pre xp sp3 OS
HashAlgorithm=RSASHA256            ; omit and configure in wizard if above is 0
Policies="Certificate Policy"
[Certificate Policy]
; OID=1.2.3  Do not use unless you actually have a a valid OID otherwise remove this line.
pathlength=1            ; this is the number of subordinate CA tiers you will have below this root - multiple subordinates may exist in the same tier with this set to 1, but if a 3rd tier is needed (rare) then set to 2.
ParanormasticCryptographic EngineerCommented:
Personally I also recommend turning on all CA auditing features within the CA properties as well, having an auditor, and writing a Certificate Policy (CP) and Certificate Practices Statement (CPS).  RFC 3647 ( is the proper formatting for writing CP and CPS (may want to get a tech writer to do this, its a pain and lengthy... also run it by legal when you're done to make them happy).

Side note I sort of missed above but is in my article - make sure to have an externally available CDP and AIA for both root & sub CA so users can validate them from anywhere (they will need to trust your root to the same area as described above).  This can also be handy so business partner companies that trust your root cert will be able to validate them against the CRL (and OCSP if you set that up).
if you want offline Root CA then you should install standaed certificate non joined domain that will be self signed then you can use CApolicy.inf file to install a CA to multi sub CA the will get a certificate before turn off a root CA  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.