We want to seperate the private key of our Standalone-Root-CA onto an USB Token. We have tested this with a Safenet eToken 5100 (72k), the Safekey Authentication Client 8.1.65.0 and a Windows Server 2008 R2 SP1 Standard Edition. During the installation we have selected the „eToken Base Cryptographic Provider“ as the CSP provider and the option „Allow administrator interaction when the private key is accessed by the CA“. After the entering the password for the Tokenaccess the private key was successfull created on the USB Token. The installation of the Active Directory Certificate Service was successful too.

 

But if we try to start the Certificate Service on the server, the service doesn't find the private key, even if we logged in or out on the Token. In the registry the "eToken..." CSP is registered correctly.

Why the certificate service couldn't start ?

The error message is:

Event ID: 100
Source: CertificationAuthority
Text: "Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. Root CA An internal error occurred. 0x80090020 (-2146893792)"

What's wrong on our installation ?

Normally the CSP should ask for PIN or password when the ADCS service starts and you need to catch that on the default console by either being logged in at the server console or running RDP with /admin switch.

Second thought here is if the CSP is really working properly to be used in this scenario.

/Hasain

On Fri, 12 Aug 2011 15:30:31 +0000, Hasain Alshakarti - TrueSec wrote:

Normally the CSP should ask for PIN or password when the ADCS service starts and you need to catch that on the default console by either being logged in at the server console or running RDP with /admin switch.

Second thought here is if the CSP is really working properly to be used in this scenario.

Two other caveats here, in addition to Hasain's suggestions (while these
are not directly related to your problem, they are important nonetheless):

1. By default, the CAExchange certificate, which is automatically
generated, uses the same CSP as the one used for the CA, but you won't be
able to access the PIN prompt when the private key is being accessed, which
means that the attempt will fail. AD CS will fall back to a software-based
CSP and the CAExchange certificate will be generated, however, you'll find
errors in the event log every time this operation is performed.

2. On a more serious note, IMO, using a smart card or USB token to protect
a CA's private key is a really bad idea. Just because something is
supported and documented by a software vendor does not mean doing so is
advisable. With a smart card or USB token not only do you have a single
point of failure but more importantly, you have no way of backing up the
private key of the CA. If the smart card or USB token fails or is lost or
stolen then you're completely and utterly

I guess it's no more relevant but let me add this

2008R2 CA features a privilege mode that by default does not allow the PIN dialog needed to logon to the token. These privileges can be added after installation of the 2008R2 CA:
Add the following strings to the existing CertSvc configuration data (multi-string) in the registry: Key: HKLM\System\CurrentControlSet\Services\CertSvc

Property: RequiredPrivileges

SeTcbPrivilege

SeIncreaseQuotaPrivilege

SeAssignPrimaryTokenPrivilege

• Edited by Akhil Babal 2 hours 33 minutes ago