• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1758
  • Last Modified:

Subordinate Certificate authority, CRL Downloading how is it done?

For the company i work for i have set up a offline root CA and a Subordinate CA

i know i need to put the offline CA back on line when the CRL is due to be downloaded my questions are,
when will the CRL be downloaded?
if it fails at first who frequently will the subordinate CA attempt to dowload the CRL?
can i force the subordinate CA to download the CRL?
if someone was daft enough to forgot to put the offline root CA on-line what would be the best aproch to get the subordinate CA to download the CRL, and will the subordinate CA fail to function if this happens?

all the CA settings (off line root and subordinate CA) setting are currently set to default, i havent played with them YET!

thanks in advance ;)
1 Solution
ParanormasticCryptographic EngineerCommented:
The root CA should remain offline.  You should sneakernet the CRL over to the sub CA and either do the same to the CDP locations, or create a script to copy the root and sub ca CRL's to the CDP locations.  We use a flash drive for this purpose, it is dedicated for that, any scripts that are used, and any patches applied for archival, tracking, and auditing reasons.

When setting up the root CA, it should be completely offline - i.e. don't even join it to a domain.  The sub-CA will normally be on the domain and populate AD with the PKI info.  The reason to not join the root ca to the domain is two-fold - one, to do so would mean that it was once online and hence that much less secure, and also for it to remain offline you need to have it so that the user accounts don't expire, so local accts are needed, not domain accts.

How to handle the root crl and cert expiring - depending on your requirements you can probably have this be an annual process - just set a calendar reminder with plenty of reminder time, and also add it to your documentation re: the ca for future admins.  For some more strict requirements, I believe the Common Policy is written this way, offline CRL's can be done once per month, online CRL's daily.  To give ourselves recovery time, we actually publish the CRL every 1/2 requirement period, so we do it twice per day for sub by script, and on the 1st and 3rd mondays for the offline root and policy ca's (or first business day thereafter) which we do manually.  That way we have a little bit of give in case of forgetfulness, outage, and weekend/holidays.

If you are that worried about missing the CRL, and your security policy allows for it, another possibility would be to have a secluded private network running off of a small 4- or 8-port switch (just a netgear, linksys,etc is fine).  This could be used to access your HSM if you have one, and also could be used for a NAT protected root, giving it a fair amount of security - technically this would not be fully offline, but would typically count well enough to pass most organizations requirement for an offline root.  You could then script the CRL to push to private IP on the Sub CA, and then script from the sub to the CDP.

If doing the latter method, you could set your root CRL to say once per month and publish a new one weekly for ease of using task scheduler.  Then have it run the following concept in a batch file, which will publish the CRL and log that event informally, copy the CRL and whenever your root CA cert gets renewed (in 10-20 years probably) this will just copy that over automatically too, backup your CA database to a time stamped folder (you probably want to create another script to clean these up every now and then or do so manually).  This presumes the existence of a D: drive, but you can just change to fit your needs.

REM Publish new CRL
certutil -crl
REM Remove any accidental z: drive mappings
net use z: /delete
REM Map drive to private IP of the Sub CA
net use z: \\\certenroll
REM Copy CRL & new CRT files to SUB CA
copy %systemroot%\system32\certsrv\certenroll\*.cr* z: /y /v > D:\logs\CApub.log
net use z: /delete
REM set variable for the timestamp to use as part of the filename - YYYY/MM/DD format
set var1=%date:~10,4%_%date:~4,2%_%date:~7,2%
REM create directory for the backup file to go into
mkdir D:\cabackup\%var1%
REM run certutil.exe to backup the CA database
certutil -backupdb d:\cabackup\%var1% keeplog
CraigShagAuthor Commented:
thats great, i didnt know you could keep the root CA off line all the time, i thought you had to put it on line every time a sub needs a new crl.

I will use USB drives like you said, i am going to set this up on VMWare, with a bit of luck ill get time to try your recomendations today.

thanks for the advice its realy apreciated, its helped alot !!!
1. rootCA (offline one) shouldn't even have network card (MSoft recommendation). Make it VM, burn on DVD, hide well.

2. Once configuring your rootCA you can make CRL (certificate revocation list) to be valid for e.g. 180days
certutil -setreg ca\CRLPeriodUnits 180
certutil -setreg ca\CRLPeriod "Days"
That way you only need your offline rootCA be switched on 2x/year
unless  you plan your sub_ca being compromised more often then that (can always publish BetaCRL if that happens).

3. publish your offline_RootCA CRL and AIA on well accessible place (Intranet web server +Active Directory) -you will need to do that every 6m-ths

4. your on-line issuing Sub-CA (ad integrated) will have have no problems in being authorised that way.
5. good luck

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now