Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > How to correctly use AD CS with hardware based cryptographic provider
December 08
How to correctly use AD CS with hardware based cryptographic provider

For higher security deployments, you may want to use a hardware based cryptographic provider module for AD CS (Active Directory Certificate Services) certificate authority (CA). Such a module is usually called HSM (hardware security module) or you can also make do with a simpler and cheaper smart card. A HSM module is usually bigger than just a smart card or token, has some advanced certifications for environmental things such as fireproofing or waterresistance, can usually be mounted to a wall etc. but is also much more expensive than a token or a smart card which will cost you about 50 EUR/USD. One important advantage in HSMs is also their speed. The devices can usually sign more than a single certifice in a second or two which would be the case with smart cards. Smart cards are just slow.

Yet smart cards or tokens provide the necessary separate crypto CPU and physically protected private key storage, so do not throw them away. They may be just as good for root CAs which do not issue tens of certificates a day, thus making a fine security for an enterprise PKI environment. Although not forgeting about regular CRL signing, you still do not have more than several signatures daily at the very most.

In case of smart cards or cryptographic tokens, there are tens of products such as Gemalto IDPrime (formerly known as Gemalto .NET) or anything else such as Aladin (made in Israel) or CryptoPlus ProID from Monet+ (made in Czech Republic) etc.

Anyway, to access private key stored in such device, you must usually provide PIN or any other form of a pass code. You will have to type the PIN manually to allow AD CS CA access the private key each time the Windows service (certsvc, certsrv.exe) starts or anytime else after you unplug the device and connect it again back to the CA computer.

When you install AD CS to use such a hardware device, you will select its hardware cryptographic provider (CSP or CNG/KSP), usually either the RSA#Microsoft Smart Card Key Storage Provider or the Microsoft Base Smart Card Crypto Provider or any other custom provider supplied by its hardware vendor. The important point is you must also select the option to Allow administrator interaction when the private key is accessed by the CA.

Active Directory Certificate Services service (the certsvc service) is a Windows service running under Local System identity on a protected desktop, so without the option selected it cannot display the PIN dialog and would hang waiting for PIN entry.

When you select the Allow administrator interaction when the private key is accessed by the CA during installation (or use the Install-AdcsCertificationAuthority cmdlet switch AllowAdministratorInteraction from PowerShell), the certsvc service is marked as interactive service (service type 0x110) and may be able to display the PIN dialog boxes when necessary.

Not by default though. Even if you enable the switch on Windows 2012 and newer, the service will freeze when starting and you will not see anything. The reason manifests itself by an error event:

Log: System
Event type: Error
Event Id: 7030
Event Source: Service Control Manager
The Active Directory Certificate Services service is marked as an interactive service. However, the system is configured to not allow interactive services.

Yet more to the problem is the fact the service is set to Automatic start mode so that it will hang every time you restart the CA's operating system. If you enabled debug logging, it would not get further than messages such as the following:

CertSrv: Database open
Enabled use count

To correct this, you have to do the following steps:

  • enable interactive services in registry. You must zero the NoInteractiveServices = REG_DWORD = 0 in HKLM\System\CurrentControlSet\Control\Windows registry key.
  • enable and start the Interactive Service Detection service (the UI0Detect service) and rather configure it to start mode of Automatic itself
  • reconfigure the Active Directory Certificate Services service (the certsvc service) to rather start Manually in order to have some time to start it yourself only after logging on.

After you reconfigure the interactive service detection, you can try starting the AD CS service manually. If your hardware requires interaction, for example due to a PIN entry, you will be first presented with a window called Interactive Service Detection which offers you option to View the message. Only then you will be brought to the Session0 desktop to insert the PIN.

Or you can also make do without PIN at all. You still can bring the smart card or token each time you need to sign a certificate request or CRL and after that return the unpluged device back to a safe.

Note about an installation warning

I have did some AD CS HSM-like deployments with Gemalto .NET cards and tokens, with Gemalto IDPrime and also Monet+ ProId cards and all of them show the following warning after installation:

An error occured when setting the security access on the private key, or the CSP selected does not support setting security access on private keys.

You can safely ignore the error message. Base provider smart cards do not support changing or even setting private key security descriptors. That is perfectly ok, you yourself control the access to the private key with PIN and/or physical device presence or disconnection to and from the CA operating system.



Great article, but I have a question. How do you manage backup/restore when using smartcard? HSM have this functionality builtin (without exposing the private key), but not smartcards.
One way could perhaps be to create a soft certificate in Windows, export to pfx, import the pfx to a smart card and then use that certificate on the smartcard when installing the CA. That way you have the backup (the pfx file), but the private key is more exposed then if it is was generated directly on the smart card itself.
Do you have any more information or tips about this?
 on 13/12/2015 14:16

Re: How to correctly use AD CS with hardware based cryptographic provider

good point, but smart cards, especially those based on Base Smart Card Provider (the minidriver cards) do have two PINs - regular user PIN and a master PIN. Master PIN (48 digits) can be used to completelly control the card, export and import certificates with private keys or anything else imanigable. So you can always backup smart card using the master PIN and store everything in separate locations.
anyway, I was talking about cheap solution, so even the backup would be a cheap procedure.
 on 14/12/2015 09:10



really useful article, thanks!!!

I have just tried setting it up using a Yubikey as a PIV smartcard and using the Private Key to generate the ADCA. using the -KeyContainerName switch. I got the key container name from certutil -scinfo

It works!!! - well, kinda. The CACommonName is set to the key container name and it will not accept the CACommonName switch.

Any ideas how to get around this or change the key container name ?
 on 27/04/2017 19:04

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *