Friday, January 04, 2013 7:25 PM
Ive tried to search for this, but am surprised nothing relevant came up. My apologies if this is an FAQ (I would guess it would be).
There seems to be at least a few regular tasks that need to be performed for online issuing CAs which scream to be automated via a Scheduled Task.
1) Backing up the CA DB.
2) Publishing new CRLs to appropriate CDP locations for an enterprise CA (which has LDAP locations in the active directory)
3) Publishing new CRLs simply to a local directory on the CA for a standalone issuing CA (ie, not a member of the domain).
I am assuming 1) is accomplished via certutil -backupdb as a scheduled task, and the identity it needs to run as needs to be a member of the Backup Operators group. Is there a smaller set of permissions than that (like "only allowed to backup CAs" or the like?)
2) is the more distressing in my current configuration - the task is currently running as a domain admin. What is the minimum permissions and/or group membership required for publishing CRLs via certutil -crl? The identity needs access to write into AD, right?
3) what is required to simply certutil -crl where the only location to publish to is C:\Windows\Certsrv\certenroll? I have a separate script that copies out to an http url.
If it matters, all servers are 2012.
Thanks in advance for your help -
Saturday, January 05, 2013 12:12 AM
1) certutil -backupdb only backs up the database of issued certificates. It does not include the IssuingCA's private Key nor it's local registry settings. Ensure that you create a backup of these items as well from time to time. If you want to split the rights for managing your CA you can implement the "common criteria role model" which allows you to designate an account that has only the permission to back up the CA and not to do anything more.
2) I assume your IssuingCA is domain joined because you stated that you are currently using a domain account for certain tasks on it. If your CA is domain joined it publishes it's CRLs automatically to the configuration partition of Active Directory every time it is necessary. This is because during installation of the IssuingCA via a enterprise admin account the required permissions in Active Directory have automatically been granted to the IssuingCA. You can configure the publishing interval of your CRLs as explained here:
What you have to make sure of:
Configure correct Paths for HTTP-Distribution of IssuingCA and RootCA CRLs and AIA
Configure correct Paths for LDAP-Distribution of RootCA CRL and AIA
Publish the CRLs of RootCA and IssuingCA to the HTTP-CDP via network-copy, floppy disk or sth.
Publish the CRL of RootCA to the LDAP-CDP via certutil script
3) The Publishing to C:\Windows\CertSrv\Certenroll is done automatically, too. See 2
- Edited by StevenD_2011 Saturday, January 05, 2013 12:42 AM
Saturday, January 05, 2013 1:53 AM
Hi Steven -
First, thank you for such a comprehensive reply, it is appreciated.
On backing up, I did realize that backupdb only backs the database up, and not the private keys or registry keys. I manually back the key and regy entry up interactively since they are so sensitive.
I have a Scheduled Task that runs nightly that basically does a certutil -backupdb. That is currently running as administrator, which is overkill and I'm guessing dangerous. I want to create a user that only has rights to backup the CA database, and wanted to know what groups to join or permissions to apply. Do you know what the best practice is for this?
On the other question, I probably did not explain in enough detail. I have 3 machines for my CAs.
- One is an offline (ie, not even a network card) that is my Standalone Root CA (obviously not joined to the domain). That is not a concern in terms of backing it up. CRL publish is a manual operation.
- One is what I call my "External Issuing CA". This is a Standalone Sub CA. Not joined to the domain, but on the network. Signed by the RootCA. This is used for certs that will be used outside the domain. CRLs are published to an internet accessible URL and thats it. Since not a member of the domain, AD publishing is not a concern.
- The last one is what I call my "Internal Issuing CA". This is an enterprise Sub CA, and is joined to the domain. Signed by the RootCA. This is used for internal only certs that will never be used outside the network/domain. CRLs are published to AD, but nowhere else (not needed anywhere else).
I have created a scheduled task on the external and internal CAs that does a certutil -crl, that runs inside the publishing interval(s).
The External Issuing CA script copies the CRL out to the http-cdp at the same time.
The Internal Issuing CA script just does a certutil -crl .
so my lingering questions are:
1) you said "for a domain joined CA, the CA publishes its CRLs automatically to the configuration partition of AD every time it is necessary". Does this mean that I do not need to have a scheduled task to do the certutil -crl to publish the CRL? Does the CertSrv Service do this automagically for me, assuming my publishing intervals are setup correctly? Does this also mean that publishing to Certenroll is also done without my intervention at each publishing interval? If so, I am making this so much harder than it needs to be :-)
2) Similarly to the question about necessary group membership/user permissions above, what is the best practice for creating a user for the task to run as that is allowed to do the certutil -crl (if I need to do it at all, dependent on the question to the preceding question).
Thank you so much for your time and help, I like MS's CA functionality, but have to say that the documentation (aside from Brian Komar's now dated book) leaves a lot to be desired... :-)
- Marked As Answer by Mavericano Sunday, January 06, 2013 9:10 AM
Saturday, January 05, 2013 11:22 AM
1) You're right, there is nothing to do to publish the CRL files to the locations where the checkbox "publish CRL to this location" is checked in your scenario. You only may need to distribute those files to your Web Servers via script.
2) Best practise is to let the CA publish the CRLs on it's own (I suppose) ^^