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
crypto::FS_PROP_KEY_USAGE_COUNT_ENABLED
...
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.