Win2003 PKI offline root CA
Hi, I'm trying to design and implement a new PKI for an organisation. We will be using an offline root CA (win2003 ent ed. non domain member) and 2 other issuing Enterprise CA's (win2003 ent ed.). Both of these Enterprise CA's will reside and two separate AD's (test and production, no trust relationship), they will be DC's within their respective domains (we may end up implementing 2 x Ent CA's in each AD but lets just say 1 each for now). Each domain is network segregated from one another via a firewall. I've designed it like this so far: root CA: offline 20 year cert validity 20 year CRL validity CDP and AIA uses http only and will sit on simple IIS. URL= http://cdp.prod.company.com & http://cdp.test.company.com. 'cdp' will be an alias in each domain pointing to local IIS server. Ent CA: online 5 yr cert default methods for publishing CDP & AIA My questions are: Do I need to publish a CDP/AIA location for the root CA? Instead, can I just copy the CRL file (valid for 20yrs) and import it into the Ent CA's computer store under trusted root or file copy it to %systemroot%\system32\certsrv\certenroll\? Or, can I place it into the AD group policy of each DC so clients receive the new CA cert plus the CRL at the same time? - I guess this would pose problems for non-windows clients trying to access a CRL Do I need to create a capolicy.inf when creating my root CA so that the first self-signed cert doesn't have CDP/AIA URL's in it? ([CRLDistributionPoint][AuthorityInformationAccess]Empty=True) Essentially, I've seen certs with CDP/AIA URL's in them and others without. Realistically we won't be revoking the Ent CA certs anytime soon (probably 'never') so the CRL information will not change (thus the 20yr validation period I chose). If there's a way I can get away without having to publish them that would be better but if I need it then how come some certs don't have it and what's the best way to publish it? Thanks
June 27th, 2011 8:08pm

1) yes, you must publish CRL/CRT files for root CA at the specified in the corresponding extension settings locations. 2) no, other options are not good. If you import CRL to a Sub CA server only, clients will still unable to check Sub CA certificate revocation status. And if you publish it to AD (and no corresponding LDAP URLs are defined on Root CA) clients will not automatically download it from AD. 3) if you already have Root CA with default CDP extension you can leave it as is and you may consider to remove this extension during root CA certificate renewal.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com
Free Windows Admin Tool Kit Click here and download it now
June 28th, 2011 1:35am

Thanks for the reply. We've decided to use a http location for our CDP. Now the question of CRL validity period has been raised. We plan on having a 20yr validity for the root CA cert so can't find a reason not to keep the CRL the same (20yr CRL validity). If for some reason we want to revoke a cert we can power-on the root CA, revoke, run 'certutil -CRL' and copy the .CRL files to the web servers hosting the CDP. That being the case why are there so many examples of people using a 10-20yr root cert validity but a CRL of 6-12months? Why wouldn't you just save the yearly manual operation of generating a new CRL and just keep the CRL valid for the duration of the cert. Thanks in advance.
June 29th, 2011 10:10pm

Clients will cache the CRL until it expires. Publishing a new updated CRL at one year intervals does not guarantee that the updated CRL is downloaded. The cached CRL will not be updated since the previous CRL has not expired. If there is a revocation, then you would not recognize it Your design is flawed. I would never recommend what you are proposing. I think that one year CRL updates would be fine Brian
Free Windows Admin Tool Kit Click here and download it now
June 30th, 2011 12:25am

OK point taken thanks. A one year CRL it is. Thanks Brian. Next question: In this PKI guide (http://www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part3.html) there's a script to modify the issuing CA. In this script it appears that he's moving the issuing CA's CDP and AIA to the same location as the root CA's CDP and AIA (http://cdp.domain.com). Wouldn't this require some form of scheduled copy script as the issuing CA's CRL is generally a 7 day validity? Can't I just leave it at the default location e.g. http://<DC-name>.<domain.FQDN>/certenroll/***.crl + LDAP + FILE. I'd rather do this than have to worry about copying the CRL weekly. I'd still like to move my root CA CDP and AIA to a remote HTTP location like http://cdp.domain.com Can I just have the following for my issuing CA script: certutil -setreg CA\CRLPeriodUnits 7 certutil -setreg CA\CRLPeriod "Days" certutil -setreg CA\CRLDeltaPeriodUnits 0 certutil -setreg ca\ValidityPeriodUnits 2 certutil -setreg ca\ValidityPeriod "Years" certutil -CRL Does that look sufficient? I'm pretty sure I can have a separate CDP and AIA for my offline root than for my issuing but seeing that 99% of certs issued by my issung CA will be internal I don't see why I'd want to move it and have to worry about updating it all the time. Can someone tell me why I would want to move it? for certs issued to external/DMZ devices that can't access the issuing CA I guess?? Thanks for your help so far.
June 30th, 2011 3:32am

mentioned registry settings will be used by a CA to publish CRL files in the defined timespans. No additional scheduling is necessary.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com
Free Windows Admin Tool Kit Click here and download it now
June 30th, 2011 5:20am

The problem with the CRL publication at the local host is that it is not highly available (unless your CA is a cluster) and is not internally/externally accessible (typically). Again, I would never publish at an issuing CA. I would publish to a Web cluster behind a device such as a F5/Cisco load balancer You state that 99% of the certs are for internal use, which means that 1% will be external. Unfortunately, you need to design for the total amount of certificates which means your current design would not allow for revocation checking for 1% of the issued certificates. I would recommend publication to an internally/externally accessible location. You can simply use a scheduled task running at the intervals of 1 week (for base CRLs) and 2 days for delta CRLs rem Base CRL Scheduled Task batch file certutil -crl timeout /t:10 /nobreak copy /y %windir%\system32\certsrv\certenroll\*.crl \\externalweb\externalshare For the delta CRLs rem Base CRL Scheduled Task batch file certutil -crl delta timeout /t:10 /nobreak copy /y %windir%\system32\certsrv\certenroll\*.crl \\externalweb\externalshare You can replace the copy command with any transfer protocol you want (FTP/SFTP/RCP/ROBOCOPY/XCOPY) Brian
June 30th, 2011 8:40am

Thank you everyone for your help. I've decided to configure my Production issuing CA to share the same CDP and AIA location as my offline root CA. This is so any devices in a DMZ, workstations or VPN users can get all the CRL info from the one highly available point. For the issuing CA in my test domain I'll keep it as default as this will only issue certs to computer/users within a single subnet. The test servers however will have the ability to resolve and access the CDP and AIA of the root CA so the whole cert chain should still work. Let me know if there's any problems with that configuration. Thanks again.
Free Windows Admin Tool Kit Click here and download it now
July 1st, 2011 1:21am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics