Andrzej Kaźmierczak

Get IT solutions today!

The DOs and DON’Ts of PKI – Microsoft ADCS

Share this post to your SOCIAL MEDIA!

DON’T install PKI without a detailed plan. Ask yourself what you need it for, what features will you use and would it be scalable enough in the future.

DO use Windows Server Enterprise Edition for Active Directory users enrollment. UPDATE: This only applies to Windows Server 2008 R2 or earlier, as for Windows 2012 or later you can use Windows Server Standard Editions.

DO use a CAPolicy.inf file during installation. There you can define attributes such as basic constraints extension, renewal key length and period, CRLs period, etc.

Server naming and CA (Certification Authority ) naming should be standardized. DO create naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Root CA shouldn’t follow the pattern and be named differently than other servers in organization.

DON’T change CA server name after ADCS role installation. It is possible to rename server and reconfigure infrastructure, but not recommended. Enrolled certificates will stop working.

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

DON’T install CA on a domain controller. It is technically possible, but not recommended. CA should run on a separate machine.

For high availability DO failover clustering. Only one CA instance can be running at a time. 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). Structure of those two documents should be based on the RFC 3647 recommendations. This allows subscribers and relying parties comparison with other, similar documents issued by other organizations.

DO create multi-tiers architecture. For huge organizations, depending on Active Directory structure and amount of forests and domains, DO use 2 or 3-tier architecture.

In 3-tier architecture, subordinate CAs located in the second tier, are called Policy CAs. Those CAs should only enroll for other CAs and no users. DO put in CAPolicy.inf file for Policy Issuing CA following section:
Pathlength = 1
Critical = true
After installation run following command:
certutil –setreg Policy\CAPathLength 1
This “Pathlength=” setting specifies the length of the path, the maximum number of CA certificates that may be issued as subordinated to the Policy CA. Pathlength with value set to „1” means that establishment CA two (or more) tiers below Policy CA is not possible.

DON’T domain join Root CA or Subordinate CA. Let those most important, top-level CAs stay in workgroup.

DON’T use online Root and Policy CAs, especially if it’s private keys are not protected by HSM (Hardware Security Module). Offline CAs hard drives or virtual disk files should be placed in a secure vault until a CA certificate needs to be issued or a new CRL needs to be issued and published.

If using HSM that are located in distant server room, DON’T restart CA server or certsrv service. You may find out that you need to insert operator’s cards set into HSM to start the service again. Sometimes it needs involving many people.

If not using HSM, CA’s keys are generated with software CSP. DO use at least 4096b keylength for Root CA.

DO change default system accounts. Local administrator should have its name changed, the default Enterprise and Domain Administrators group permissions for CA should be taken away, and Domain Admins group should be deleted from the local administrators group on all systems belonging to the PKI.

DO use long and complex local administrator 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.  Default value is %windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt. The part „%%1_” in CA certificate will be replaced by „<CAservername>_” which will reveal internal naming convention and structure. „%%1_” should be deleted. It is important to remember that during renewal process because .crt file will be generated with %%1_ prefix, so it has to be manually deleted after renewal operation.

If implementing in organizations, DO use templates OID to differentiate company’s policy objects from default Microsoft policy objects tree. You should request PEN (Private Enterprise Number) from IANA organization (Internet Assigned Numbers Authority). Templates OID should be created with PREFIX (got from IANA) and individually created numbers for template structure.

DO customize templates, DON’T use default ones. Use organization name prefixes with templates names, customize them and add OID created with IANA’s PREFIX.

After ADCS installation DO use following commands to publish 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"

UPDATE: As HTTP is recommended path to publish CRT and CRL there is no need to use CDP and AIA with LDAP and to publish them to AD.

DO make CDP (CRL Distribution Point) redundant. Include in CDP and publish CRLs to both LDAP and HTTP. Make sure that at least one HTTP is accessible from Internet, WAN or partner’s network. It is required if you want to use certificates outside your intranet. UPDATE: DO NOT use LDAP in your CDP path at all – use only HTTP and make sure HTTP location is highly available, highly consider using split-brain DNS scenario.

If however, you decide to distribute CRL using Active Directory, DO bear in mind AD replication delays.

DO implement OCSP. Online Certificate Status Protocol reduces CRL usage (bandwith) and is more reliable. End-users workstations cache CRL in local user profile, so user’s certificate revocation may become effective when cached CRL validity period is over. Unlike this CRL weakness, OCSP uses delta CRL, so to work efficiently I suggest setting Active Directory Certificate Services Delta CRL time to minimum period (30 minutes):
certutil -setreg CA\CRLDeltaPeriodUnits 30
certutil -setreg CA\CRLDeltaPeriod "Minutes"
OCSP should be available from both Internet and intranet.  Keep in mind that despite the revocation of the certificate, the preferred method for removing user access to resources is disabling AD account.

DO use PKI repositories. Those are places to keep PKI related data. It can be a public web folder for all with CRLs and CA’s certificates or private folder for internal users only with CP, CPS, user’s .crt certificates, user’s regulations. CRLs and CA’s .crts as well.

Microsoft ADCS default repository is C:\Windows\System32\certsrv\CertEnroll. To that directory are published CRLs and CA’s .crt certificates. As mentioned before, CDP and AIA should be published redundantly – with HTTP protocol. DON’T publish CertEnroll folder directly to the Internet. Instead create a copying script which copies *.crt and *.crl to another machine and folder and create task schedule to trigger it every, let’s say, 5 minutes. When in another folder, publish to Internet with your reverse proxy, for example Microsoft Forefront Threat Management Gateway UPDATE: Microsoft TMG is discontinued. Be careful on credentials that are provided to run script. You can use this simple code below to create batch file:
xcopy C:\Windows\System32\certsrv\CertEnroll\* \\\Repository\* /Y /Q

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

In some cases DO set private keys archivization. Thanks to that you will be able to recover old keys used to secure data in the past.

DO set KRA (Key Recovery Agent) and DRA (Data Recovery Agent). Those two are one of the most important accounts that help recover important data and must be protected with increased caution. KRA can restore lost private key. DRA is a user granted the right to decrypt data encrypted by other users.

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

Whenever possible, DO use tokens or smartcards for users and special purpose accounts (Enrollment Agents, etc). Without them private keys are generated by software CSP and kept in Windows registry! Whoever has access to workstation and knows where and how to look, may find these interesting things. To protect from that situation use smartcards which lets keys be generated by hardware CSP and if FIPS-3 compliance, never leave the smartcard.

DO take into account above when disposing user’s hard drives, especially CA hard drives. If not on smartcard, user’s private key is still on that hard drive.

DO make sure that system time on CAs machines is set correctly. The best way (but not cheap) is to use NTP (Network Time Protocol).

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 when configuring Microsoft ADCS:
certutil -setreg CA\AuditFilter 127
Also, enable ‘Audit Object Access’ within Group Policy (for ‘Success’ and/or ‘Failure’ as required) in order for any Cert Services events to be logged.

DO health check of PKI infrastructure. If using Microsoft ADCS, use tool PKIView. Moreover, PKI events are logged in Security event log on CA server. Use event viewer to check for events especially those red and yellow ones.

If needed to increase level of logging, DO change value „3” to „4” in following registry path:
HKLM\CurrentControlSet\Services\certsrv\configuration\Subordinate CA\Loglevel

DO create CA backup, including private key, CA certificate, certificate database and certificate database log, CAPolicy.inf file and exported CA templates. Make copy of folder „Database” including certpkxp.dat, edb*.log and <CAname>.edb files. Also export settings of registry path:

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

DON’T consider internally issued certificates as a qualified certificates. Qualified certificate is issued to a person acting on his or her own behalf by Trusted Third Party CA. Qualified certificates can be used to authenticate to government organizations.

Andrzej Kazmierczak

About Andrzej Kazmierczak

Andrzej Kaźmierczak is an IT professional with many years of IT security experience to his credit. As a certified Architect and Systems Engineer in the field of Microsoft security solutions, Andrzej expands on his vast knowledge of the industry working with many major worldwide corporations and organizations from a wide variety of industry fields. Andrzej is also a published author of many security articles and blogs. His key specialties include the architecture, design, implementation and support for Identity Federation, Azure and Cloud, work in the field of Public Key Infrastructure and smart cards, as well as a wide array of Information Protection and Rights Management. Follow on twitter: @ANDKAZM View all posts by Andrzej Kazmierczak →
This entry was posted in Public Key Infrastructure and tagged , , . Bookmark the permalink.

59 Responses to The DOs and DON’Ts of PKI – Microsoft ADCS

  1. Nicki

    There is a hidden swtich on certutil.exe that does the exact same thing.Certutil -dsdel Funnily, certutil also neglects to remove the certificate from the AD NTAuth store, probably because removing that certificate involves removing a value from an attribute on the NTAuthCertificates object rather than deleting an entire object like the other entries related to a CA. Basically, this is dev work that was never completed, and the reason why the swtich is hidden. Anyway, you’d need one more certutil command to purge the CA’s certificate from the NTAuth container and complete the decommissioning process.certutil -delstore ldap:///CN=NTAuthCertificate,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority

  2. J

    Excellent article! I’d love articles on PEN+OID explained in detail.

  3. Jake Kim

    Once I have the PEN, would my OID be And, do I need to register this OID with Microsoft? If so, where @ MS? Thanks.

    • When you receive Private Enterprise Number (PEN) from IANA, your OID will be[PEN], for example That’s the OID your Company objects (including PKI objects) will start with. You don’t register this OID with Microsoft directly. If you receive it, it means that it’s already been registered @ IANA and you check it on

      Now, remember to categorize your objects and divide into subclasses using OID. The best way is to draw a tree with numbers you want to use, for example
      Whole Company ID class[PEN]
      Company’s CA ID class[PEN].1
      Company’s Root CA ID class[PEN].1.1
      Company’s Internal Policy CA ID class[PEN].1.10
      Company’s External Policy CA ID class[PEN].1.20
      Company’s Internal Issuing CA ID class[PEN].1.100
      Company’s External Issuing CA ID class[PEN].1.200

      You have to choose Certificate practice statement (CPS) ID class, which I choose to be under Root CA ID class, so something like[PEN].

      When installing CAs, in capolicy.inf file just add following

      Now create some Certificate Policies names used for grouping templates. You can use “Applications”, “Systems”, “Employees” Certificate Policies (for example in “Systems” Certificate Policy youwould add Computer template, Domain Controller template, EFS Template, etc). Combination of Certificate Policy name, CPS location and OID is called Issuance Policy which describes the condition under which a certificate is issued. When duplicating template, on Extensions tab edit Issuance Policies you can add Issuance Policies with your OID:
      New issuance Policy

  4. NeilM

    If a PKI is being used for Microsoft products, do you need to request your own OID and alter the templates that are built in Windows 2008 R2. If you are only using the PKI for Client devices, Exchange, SCCM, SCOM etc I’m not sure what the requirement is to amend the templates that are there (and work out of the box) and update with your own PEN and therefore OID? Am I missing something?

    Thanks for any clarification.


    • Hi Neil,

      When you’re using your own certificate templates /and not those out of the box/, you add OID to mark them as clearly distinguished and belonging to your company PKI. In this way you identify your company’s certificates, and what’s more, each OID is mapped, documented and described in the Certification Practice Statement document.
      I don’t think that every certificate template works out of the box. What good is in having Web Server template certificate if you cannot export private key out of the box?


  5. Dawn

    Can you elaborate more on the PKITemplateAdmins, PKICertAdmins, PKICAAdmins roles and the permissions you would set with each?

  6. Ratko

    Hi Andrzej,

    Can you put one capolicy.inf file for IssuingCA here with examples of Assurance policies and custom OIDs?
    I have error on the RootCA when trying to issue the certificate for IssuingCA (error constructing or publishing certificate invalid issuance policies)



  7. Omar

    Hi Andrzej,

    I’m planning a CA cluster and I need to deploy also CA Web Enrollment and Certificate Enrollment Web Services. The CA web enrollment and the CEWS should be deployed on separate servers with network load balancing for high availability, right? As I understood from Microsoft documentation, I can’t put these two roles on the CA cluster.


    • Hi Omar,

      You CAN put CEWS and Web Enrollment services on the CA machines (instead of separate servers), but listen to this: The purpose of CEWS is to PROXY requests from users that are sent to CA, so that CA servers are not accessed directly by users. So again – if you install CEWS roles on the CA servers, purpose of why CEWS were created becomes useless 🙂
      It is very well explained on Ned Pyle’s blog here:


      • Omar

        The CEWS is required for deploying Multi-Function Devices (MFDs) wireless printers and, unfortunately, to keep cost low, I have to put them on the CA server. 🙂

        Thanks a lot Andrzej, I highly appreciate your help and guidance 🙂

  8. Pingback: Microsoft CA – Two-Tier PKI – Server 2012 R2 | geekhain

  9. Pingback: ADCS (PKI) Useful links | BritV8

  10. Wayne Harris

    Good post. Captured a lot of great information here. Could not agree more with the OID and CP/CPS portions.
    My only criticism, as minor as it might be, would be with the recommendation of a delta CRL that is good for only 30 min.
    If a delta-CRL, whose validity is set for 30 min is used, this would mean that a PKI administrator would have 30 minutes or less to respond to any problems related to not being able to sign that delta CRL. After that, certificate validation could start to fail. In my experience, that is an operationally tight timeframe to respond to an IT outage.
    So, if your issuing CA experiences some operational issue that prevents it from signing it’s delta CRL, or Base CRL, you have then designed in a very tight timeframe in which to recover or repair your CA.
    I would not recommend timeframes this tight unless you absolutely have to.
    And if it turns out that you must use a timeframe that is this tight, I would absolutely recommend deploying the issuing CA on a well-functioning cluster server.
    Which, I think you eluded to.
    Again, great post.

    • Thank you Wayne! Absolutely you are right about delta CRLs validity periods. If you have a well designed CA cluster, you can opt for 30 minutes. If not, well, use less tight timeframes. Having 30 minutes for delta CRL publishing may be helpfull when you want to rely on revoking certificate as a method of blocking users’ login access. However, it still recommended way is to disable users’ AD account in the first place. On the other hand you can have a business process defining that after revoking a certificate, CA Administrator is issuing CRL manually or CRL issuance is done automatically (f.e. with FIM).

  11. Von Hawkins

    Thanks for publishing this. I’ve been working PKI for several years without much exposure to the MS PKI products and I’ve been meaning to start learning about the MS offerings. This looks like a good guide to MS-specific pointers (and several generally good practices).

    • There are tons of Microsoft technologies I bet you’ll find very interesting. You should start your exploration with Active Directory (Domain Services) and expand more technologies consecutively depending on what you are keen on – infrastructure, communication, collaboration, identity and security, etc. To keep up to date stay tuned with Microsoft Azure and read/try everything about Cloud services – this is where everything seems to be going nowdays… as an example: you can find a PKI-as-a-service offerings.

      It’s been a while since my last article, but I’m planning to post some guide on Microsoft Azure ADRMS, so don’t drift away to far from my blog and discover new MS pointer 🙂

  12. Pingback: Direct Access + Network Access Protection – part 4 – Potential issue with multiple CAs. Lessons learned.

  13. John Spaid

    Great post, Andrzej. It’s been very helpful.

    I have a question about this section:

    “Server naming and CA (Certification Authority ) naming should be standardized. DO create naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Root CA shouldn’t follow the pattern and be named differently than other servers in organization.”

    Why should the root CA not follow the naming convention? I’ve seen this advice elsewhere but no elaboration.



    • Hi John,

      Mainly because it would be harder to guess the Root CA server name for potential attackers. Root CA should one of the most secured servers in your environment. As it is non-domain joined you have a lot of options to hide it to increase security. You can f.e. opt not to register it in your DNS, break the naming convention, or remove server name from all CDP and AIA paths.


  14. Pingback: AD CS (PKI) Resources and Migration to 2012 R2 | Jacques DALBERA's IT world

  15. Mike

    Anyone know a way to get the cert logs exported out to put into Splunk. I would love to have some reporting into soon to expire certs, who is creating them, etc..

    I’m new to all this, and all we have is an offline CA and the two issuing CAs with what seems to be NO reporting in any fashion.

  16. Pavel

    Hello Andrzej,
    nice blog post. Thank you. Anyway I have a question about CRL and AD.

    You say “UPDATE: DO NOT use LDAP in your CDP path at all – use only HTTP…”

    But few lines above you say:
    “After ADCS installation DO use following commands to publish 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”

    Why should I publish CRL to AD, when nobody will look at AD for CRL? (as the CDP in all cert will be missing the LDAP).

    The same way it doesn’t make sense to me to publish Root CA to AD, when I probably also get rid of LDAP in AIA? Can you elaborate this please?

    • Yes Pavel, you are right. Fixed this as there is no need to publish to AD. Thanks for pointing this out!

      • Patrick

        Hi Andrez, if you do not publish the RootCA certificate to AD how does it become a Trusted Root CA in AD? I thought you would publish the certificate but not the CRL, CRL will be published to the locations in the CDP i.e. HTTP location only.

        • Hi Patrick,
          Users trust CA cert using those ways: GPO, Microsoft Root Certificate Program (delivered with updates) and by NTAuthCertificates container. NTAuthCertificates Container in Configuration Partition contains all of the CA certificates in the current forest and CA certificates are added automatically only if your CA was installed with account that has Enterprise Admin priviliges. Of course you can also add your CA to NTAuthCertificates container manually later on (which can done if for external 3rd party CAs).

  17. fatbloke

    I think you would also need to enable ‘Object Access Auditing’ within Group Policy (for ‘Success’ and/or ‘Failure’ as required) in order for any Cert Services events to be logged?

  18. Patrick

    Andrzej, is there a method to quickly ascertain whether an AD environment has an existing CA infrastructure – apart from running the Enterprise PKI Healthcheck MMC? Numerous times I have been on a customer site & deployed a CA on the understanding there is not an existing PKI, after the install I run the Enterprise PKI MMC (because I do not have access to it beforehand) only to find there are other CAs in place. I was thinking of a Power Shell query (or similar) that the onsite admin could run to determine whether there is an existing CA.

    • Hi Patrick,

      Yes. ADSIEdit (or any LDAP tool) and Configuration partition to look for AD containers.
      The Certification Authorities container is stored in CN=Certification Authorities, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain.Contains all the Root Certification Authorities in the Active Directory Forest.
      Enrollment Services Container contains all enterprise issuing certification authorities in an Active Directory Forest. The container is CN=Enrollment Services, CN=Public Key Services, Configuration, CN=Services, DC=ForestRootdomain.

  19. Johnathan Panepinto

    Thank you for this information, very helpful.

    Is it possible to deploy an Enterprise CA issuing server in an isolated subnet where only the domain controller in the restricted zone is allowed connectivity out via IPSEC encapsulation to peer domain controllers? Member servers within the restricted subnet, including the Enterprise CA issuing server, only have connectivity to the one domain controller, but no system outside of the restricted subnet.

    If so, is there a related article describing how? I have a functional issuing CA in the “parent” network,

  20. Johnathan Panepinto

    I found my error. I did not enable the templates in the second Issuing CA that is located within the restricted zone. Enabling the templates has resolved my issue.

  21. J Hedley

    Your site is a gold mine for what is, to me, an utterly mind numbing subject.

    It would appear that during 802.1x authentication occasionally NAP/Radius is using an expired Domain Controller certificate. Inspecting the list of issued certs shows that there are three years of expired certs for the PDC and BDC- they apparently have been auto reissuing. I confirmed from the client that failed to authenticate that the cert presented was expired. Can I safely revoke these old/expired certs? What really is the point of keeping issued certs that have expired?

  22. Ron

    Hi Andrzej, I was trying to publish CRL to AD LDS but keep on getting this error: “Cannot open Cert store. -addstore command failed… Access is denied” I’ve followed this link to no avail. I’ve created SPNs. I even added the service account to the domain admin just for testing. What do you think am I missing here? Will really appreciate your help. Thanks!

    • Hi Ron,

      What SPN and what service account are you talking about?
      What Paths have you configured in CDP of the CA? What account are you using to log in to ADCS server? Have you tried “certutil -crl”?

  23. Shashank Agarwal

    Hi Andrez,

    We are planning to move our root CA server from Windows server 2003 to Windows server 2012. We have SCCM 2012 in our environment. We are using PKI certificates for some Site systems. Please let us know what should we take care from SCCM 2012 perspective.

  24. Thomas Schittli

    Good eveing

    Thank you very much for this great List!

    There is just one strange thing:
    could CAPolicy.inf be replaced by certutil commands (in Windows Server 2012 R2)?

    It’s strange to have some settings in CAPolicy.inf and then other settings being applied using certutil.

    Or is there a difference how the settings in CAPolicy.inf
    and the settings from certutil written into the registry are applied?

    Thanks a lot for any light in the dark 🙂

    kind regards,

    • Hi Thomas,

      CAPolicy.inf is used to modify some of the settings of the CA certificate itself. With certutil you can change settings of the certificates issued by the CA.
      Some of the settings defined in CAPolicy.inf file and commands used with certutil overlap. CAPolicy.inf played a big role in W2K3 Operating System..

  25. Jaspreet Singh Jhans


    After Installation of Certificate on my Issuing CA while restarting the services i am getting below error

    The system cannot find the path specified. 0x3 (WIN32: 3 ERROR_PATH_NOT_FOUND)

  26. Jaspreet

    When i am submitting the .req file of my issuing CA (Domain Joined) to Policy CA( Non Domain). I am getting below Error.

    Active Directory Certificate Services denied request 2 because Bad Data 0x80090005 (NTE_BAD_DATA)
    Error constructing or publishing certificate resubmitted by administrator
    EVENT ID 53

  27. JC


    What would be the pros and cons if I use a Linux box as the offline RootCA? The SubCA will be Windows 2012 ADCS role with HSM.


    • Hi JC,

      It’s up to you wether you use Windows based PKI or Linux based. It all should come to security – make sure that Root CA is the most secure one (offline / using HSMs). The platform and UX is for your and your users convenience.

  28. Daniel L. Benway

    I’ve posted a step by step guide to installing a 2-Tier, Offline-Root, Internal PKI with an IIS CDP on Windows Server 2012 R2. Posts and blogs from people like Andrzej were extremely helpful in my own learning process. My blog is, and it includes explanations and screenshots of a lot of the material Andrzej discusses on his blog, including: general theory, CAPolicy.inf, CertUtil.exe, OIDs, Cert Publishers Group, CDP, CRL, AIA, etc..

  29. Taner Karagol

    What should “certification authorities container” contain in two tier CA infrustructure. We have rootCA (non domain offline computer), and subordinate enterprise CA. Which one should be in “certification authorities container”.

    Now “certification authorities container” is empty. Why? Maybe migration (from 2008 to 2012)deleted the container.

    • Hi,

      The Certification Authorities container contains a certificationAuthority objects for each Root CA. If Root CA has been installed on the domain joined server, it will automatically be added to that container. If it is a non domain server, to have it in Certification Authorities container you need to “dspublish” it 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *