Microsoft Windows based PKI DOs and DON'Ts

DON’T install a Public Key Infrastructure without having a detailed plan. Plan the required PKI roles. Consider availability requirements.

DO use a CAPolicy.inf file for initial configuration during installation. You can use it to define attributes such as basic constraints extension, renewal key length and period, CRLs period, etc.

DO use a standardized naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Naming conventions should include the CAs Common Name.

DON’T change CA server name after ADCS role installation. Already enrolled certificates will stop working.

DON’T use Root CA to issue certificates directly to end entities.

DON’T install any PKI component on a domain controller. It is technically possible, but not recommended due to security and delegation considerations.

DO install the CA on failover clustering. Microsoft ADCS role can act as active-passive using failover feature of Microsoft Windows operating system.

DO create CPS (Certificate Practice Statement) and CP (Certificate Policy) documents to improve the trust to your PKI. Documents should be based on RFC 3647 recommendations.

DO create at least a 2-tiers architecture. For huge organizations, depending on Active Directory structure and amount of forests and domains, you can extend the architecture to a 3^rd-tier.

DON’T join the Root CA to your Active Directory Domain. Building an “offline” Root CA really means offline with no network connection.

DO protect your offline Root CAs hard drives or virtual disk files and place them in a secure vault until a CA certificate needs to be issued or a new CRL needs to be issued and published.

DO use a HSM to protect the keys of your CAs. I can recommend Gemalto formerly Safenet.

DO consider all operational and security related procedures when implementing a HSM.

DO use at least 4096b keylength for Root CA.

DO change default system accounts. The Local administrator account name should be changed. Domain Admins group should be deleted from the local administrators group on all systems belonging to the PKI.

DO use long and complex password and DO make sure it is kept in safe place.

DON’T leave default AIA (Authority Information Access) URLs with the CA hostname in issued certificates.

DON’T leave default CDP (CRL Distribution Point) URLs with the CA hostname in issued certificates.

If implementing in large organizations, DO use templates OID to differentiate company’s policy objects from default Microsoft policy objects tree. You can request PEN (Private Enterprise Number) from IANA organization (Internet Assigned Numbers Authority).

DO ony use customized templates, DON’T use default ones. Use organization name prefix for templates names.

DO use following commands to publish Roo CA CRLs and .crts to the Active Directory:

certutil -dspublish -f "name_of_root_ca_cert.CRT"  RootCA

certutil -dspublish -f "name_of_ca_crl.CRL"

DO make CDP (CRL Distribution Point) redundant. Include in CDP and publish CRLs to HTTP. Highly consider using split-brain DNS scenario to publish the CRLs.

Microsoft ADCS default repository is C:\Windows\System32\certsrv\CertEnroll. CRLs and CAs certificates are published to this folder. DON’T publish CertEnroll folder directly to the Internet. Instead create a mechanism which copies *.crt and *.crl to another machine and folder. Publish this other machine to the Internet with a reverse proxy.

DO use role separation. In simple scenario these should be: PKIBackupOperators, PKITemplateAdmins, PKIAuditors, PKICertAdmins, PKICAAdmins.

DO enable key archival for private keys if you are using certificates for email or file encryption. Otherwise you’ll not be able to recover old keys used to secure data in the past.

DON’T write down your user’s certificate password/PIN and stick it to monitor or hide under the keyboard.

DO use tokens or smartcards for users and special purpose accounts (Enrollment Agents, etc) if possible.

DO make sure that system time on CAs machines is set correctly.

DO renew the CA certificate with a supply of time so that certificates issued by the CA have shorter life time than the remaining life time of the CA certificate.

DO enable all auditing events for the CA.

certutil -setreg CA\AuditFilter 127

DO perform health checks on your PKI infrastructure using PKIView and check the eventlog on a regular basis.

DO create a CA backup, including private key, CA certificate, certificate database and certificate database log, CAPolicy.inf file, CA configuration from the registry and exported CA templates.

DO make sure that system backup is done regularly. Backups should be protected with password and kept in safe place.

DON’T consider internally issued certificates as a qualified certificate. Consider certificate usage to make sure the certificate is issued by the corresponding internal or external CA.