- Public Key Infrastructure Part 1 – introduction to encryption and signature
- Public Key Infrastructure Part 2 – main components
- Public Key Infrastructure Part 3 – implement a PKI with Active Directory Certificate Services
- Public Key Infrastructure Part 4 – Configure CRL
- Public Key Infrastructure Part 5 – Registry key, certutil and Active Directory
- Public Key Infrastructure Part 6 – Manage certificate templates
- Public Key Infrastructure Part 7 – Enrollment and Auto-enrollment
- Public Key Infrastructure Part 8 – OCSP responder
- Public Key Infrastructure Part 9 – Management accounts
- Public Key Infrastructure Part 10 – Best practices about PKI
General ADCS best Practices
- Make a detailed plan of your PKI infrastructure before deployment. One mistake and you have to rebuild your PKI.
- Do not rename your CA server name after ADCS configuration. Issued certificates will no longer work
- Avoid to install ADCS on a domain controller
- On all CA, implement Role-Based Administration
Root CA
- The operating system should be without Graphical Shell (Core)
- Make a hardening of your server
- Use a specific administrator password
- Do not join an Active Directory domain
- Shutdown the server except when publishing the CRL
- Protect the offline Root CA with Bitlocker (View Flemming Riis topic)
- If you can, protect the private key with HSM
- Store the database and transaction log on a separate hard drive
- Do not issue certificates to clients (devices or users) from Root CA
- Backup the CA private key, CA registry Key, the CA database and the CA certificate
- Publish the CA certificate in Active Directory
- Enable auditing events
Sub CA
- The operating system should be without Graphical Shell (Core)
- Make a hardening of your server
- Use a specific administrator password
- If you can, protect the private key with HSM
- Store the database and transaction log on a separate hard drive
- The Sub CA should issue certificates for clients OR for Sub CA but not both
- If your Sub CA issue certificates for other Sub CA (and not clients), keep this server outside of an Active Directory Domain.
- Install Enterprise CA only if your CA issue certificate for clients (devices or users)
- Backup the CA private key, CA registry Key, the CA database and the CA certificate
- On CAs that deliver certificates for user clients, implement Key Archival
- Enable auditing events
Template Certificates
- Do not use default templates and always duplicate certificate templates.
CRL, AIA and OCSP
- Modify default file system CDP path
- Modify default file system AIA path
- CDP should be highly available. For internal usage, prefer use Active Directory and for External usage, prefer use HTTP.
- For larger organization, prefer using of high available OCSP responder
- Publish Root CA CRL to Active Directory
CA certificates
- Validity period: maximum 20 years
- Key length: at least 4096bit
- Hash algorithm : at least Sha-2 (Sha 256bit)
Client certificates
- Validity period: maximum 2 years
- Key length: at least 4096bit (be careful that some applications support only 2048bit, I’m talking about you SCCM 2012 R2 … Red card)
- Hash algorithm : at least Sha-2 (Sha 256bit)
Sir would you consider creating a post on installing and configuring NDES?
Hi Martin,
Ok, I’ll write a topic on Network Device Enrollment Service in the next few weeks. Stay tuned 🙂
Thanks you very much for your post, it’s very interesting!!!!
This was great. Thanks!
do you know how long it takes for a clients web browser to reflect the revoked certificate status?
after revoking a cert on the CA, and publishing. i confirm with certutil from the client that its revoked, but the browser still shows valid for a few hours.
With the browser, I think it is a cache story. Try to open an inconito window and check again
Dear Romain,
Thanks for the post. Just wondering if I could email you to ask some specific questions.
Dushan
Hey, you can contact me at rserre [ at ] seromIT [ dot ] com