Troubleshooting Certificate Enrollment: Resolving 'Certificate Template Unavailable' Errors on Windows Server

Table of Contents

This article addresses a common issue encountered in Windows Server environments where certificate enrollment fails due to a certificate template being unavailable. This problem manifests when the Certificate Authority (CA) service is unable to load a specific certificate template, consequently preventing users and computers from successfully requesting certificates based on that template. This situation can disrupt critical services and processes that rely on certificate-based authentication and encryption within an organization’s infrastructure. Understanding the root cause and implementing the appropriate resolution is crucial for maintaining a healthy and secure PKI (Public Key Infrastructure).

Symptoms¶

When attempting to request a certificate from a Windows Server Certification Authority, users may encounter a specific error message after selecting a certificate template and clicking the Enroll button. The error dialog typically displays the following message:

“The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)”

This error code, CERTSRV_E_UNSUPPORTED_CERT_TYPE, clearly indicates that the CA is unable to process the certificate request for the selected template. Furthermore, upon inspecting the Certification Authority console or logs, administrators might observe that the specific certificate template in question fails to load during the CA service startup. This failure during startup is a key indicator that the problem lies within the CA’s ability to access and utilize the template definition. The inability to load the template at the CA level is the underlying reason for the enrollment failures experienced by users.

Cause: Access Control List (ACL) Misconfiguration¶

The primary cause of the “Certificate Template Unavailable” error is often related to the Access Control List (ACL) configuration of the certificate template within Active Directory. By default, certificate templates in Active Directory are configured with an ACL that includes the Authenticated Users group. This group encompasses all domain users and computers, including the Certification Authority server itself. The CA server, as a computer object in Active Directory, relies on this group membership to gain the necessary permissions to read and access the certificate template definition.

Specifically, the CA needs Read permissions on the certificate template object to load it into its configuration and make it available for certificate requests. If the Authenticated Users group is inadvertently or intentionally removed from the template’s ACL, or if the Read permission is removed for this group, the CA will lose its ability to access the template. Consequently, when the CA service starts, it will fail to load the template, and any subsequent certificate requests based on this template will be rejected with the CERTSRV_E_UNSUPPORTED_CERT_TYPE error.

Think of it like this: the certificate template is a document stored in a secure filing cabinet (Active Directory). The CA needs a key (permissions) to open the cabinet and read the document (template). The Authenticated Users group is like a master key that, by default, allows authorized entities (including the CA) to access these documents. Removing this master key, or changing the lock, prevents the CA from accessing the template.

Resolution: Restoring CA Access to the Template¶

To resolve the “Certificate Template Unavailable” error, the crucial step is to ensure that the Certification Authority server has the necessary Read permissions on the affected certificate template. The most straightforward approach is to reinstate the Authenticated Users group to the template’s ACL with Read permissions. This action restores the default permission configuration and typically resolves the issue in most scenarios.

However, in environments where the Authenticated Users group has been intentionally removed for security reasons, a more granular approach is required. In such cases, instead of re-adding the Authenticated Users group, you must explicitly add the computer account of each Certification Authority server to the template’s ACL. It is essential to add the computer account, not a user account. This ensures that the CA service, running under the context of the computer account, has the required permissions. For each CA computer account added to the ACL, grant it Read permissions.

Step-by-step guide to modify template ACL using Active Directory Administrative Center:

1. Open Active Directory Administrative Center: On a domain controller or a server with the Remote Server Administration Tools (RSAT) installed, open the Active Directory Administrative Center (DSAC.exe).
2. Navigate to Certificate Templates: In the left pane, navigate to your domain, then expand System, then expand Public Key Services, and finally select Certificate Templates.
3. Locate the affected template: In the right pane, find the certificate template that is causing the enrollment errors.
4. Open Template Properties: Right-click on the template and select Properties.
5. Navigate to Security Tab: In the template properties window, click on the Security tab.
6. Check Existing Permissions: Review the list of users and groups and their associated permissions. If Authenticated Users is missing or does not have Read permissions, or if the CA server’s computer account is not listed, you need to add or modify permissions.
7. Add Permissions (Option 1: Authenticated Users): If you want to re-add the Authenticated Users group:
   • Click Add….
   • In the “Select Users, Contacts, Computers, or Groups” dialog, type Authenticated Users and click Check Names.
   • Select Authenticated Users from the list and click OK.
   • In the “Permissions for Authenticated Users” section, ensure that Read is checked under the “Allow” column.
   • Click Apply and then OK.
8. Add Permissions (Option 2: CA Computer Account): If you want to add the CA server’s computer account:
   • Click Add….
   • In the “Select Users, Contacts, Computers, or Groups” dialog, click Object Types…, ensure Computers is checked, and click OK.
   • Type the name of your Certification Authority server computer account (e.g., CAName$, where CAName is the NetBIOS name of the CA server) and click Check Names.
   • Select the computer account from the list and click OK.
   • In the “Permissions for CAName$” section, ensure that Read is checked under the “Allow” column.
   • Click Apply and then OK.
9. Restart CA Service (Optional but Recommended): While not always strictly necessary, restarting the Certification Authority service on the affected CA server(s) is recommended to ensure that the changes are fully applied and the template is loaded correctly.

Important Considerations:

• Replication Latency: After modifying ACLs in Active Directory, allow time for replication to occur across your domain controllers. In larger environments, this might take some time before the changes are fully propagated and the CA can access the updated template information.
• Multiple CAs: If you have multiple Certification Authorities in your environment, ensure that you apply the necessary permission changes to the ACL of the template on Active Directory, as this is the central repository for template information. All CAs will then be able to access the updated permissions after replication.
• Security Auditing: If you have security auditing enabled, ensure that you review audit logs for any changes made to certificate template ACLs to track modifications and maintain accountability.

More Information: Understanding Certificate Template Permissions¶

To fully grasp the resolution and prevent future occurrences, it’s beneficial to understand the permission requirements for certificate enrollment. The process involves two key entities: the requesting user or machine and the Certification Authority itself.

Minimum permissions required for an entity to successfully request a certificate based on a template are:

• Requesting User/Machine:

  • Read permissions on the certificate template object. This allows the user or machine to view the template and its properties.
  • Enroll permissions on the certificate template object. This is the crucial permission that allows the user or machine to actually request a certificate based on the template.

• Certification Authority Object:

  • Read permissions on the certificate template object. As discussed earlier, the CA needs to read the template definition to load it and process enrollment requests.

These permissions are typically granted through Active Directory ACLs. Certificate templates are objects stored within the Active Directory configuration partition, and their security is managed using standard Active Directory permissions.

Default Permissions and Best Practices:

By default, certificate templates are configured with reasonable permissions that cater to common scenarios. The inclusion of the Authenticated Users group with Read and Enroll permissions on most standard templates allows domain users and computers to enroll for certificates without requiring overly complex permission configurations.

However, in more security-conscious environments, administrators might choose to refine these default permissions. It is generally not recommended to remove the Authenticated Users group entirely from certificate template ACLs unless there is a very specific and well-justified security requirement. If you do remove Authenticated Users, you must meticulously grant Read permissions to each and every Certification Authority computer account to avoid the “Certificate Template Unavailable” error.

Diagram illustrating the permission flow:

mermaid graph LR A[Requesting User/Machine] --> B{Certificate Template in AD}; C[Certification Authority Server] --> B; B --> D{Permission Check}; D -- Read & Enroll (User/Machine) --> E[Certificate Request Allowed]; D -- Read (CA Server) --> E; D -- Missing Permissions --> F[Certificate Request Denied / Template Unavailable]; E --> G[Certificate Issued]; F --> H[Error: CERTSRV_E_UNSUPPORTED_CERT_TYPE]; style D fill:#f9f,stroke:#333,stroke-width:2px

This diagram illustrates the flow of a certificate request and highlights the critical permission checks at the certificate template level in Active Directory. Both the requesting entity and the CA server must have the necessary permissions for successful certificate enrollment.

Errors Observed When Enrollment Is Unsuccessful¶

Besides the primary error message “The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)” encountered by users during enrollment, administrators might also observe errors in the Application log on the Certification Authority server itself when the CA service starts. These errors often provide more detailed insights into the template loading failure.

Common Event Log Errors:

• Event ID 13: Source: CertSvc. Message: “Active Directory Certificate Services could not load Certificate Template TemplateName. The template will not be offered. The error was: Access is denied.” This event clearly indicates an access denied issue when the CA attempts to load the specified certificate template.

• Event ID 18: Source: CertSvc. Message: “Certificate Services did not start because it could not load any certificate templates. The error was: Access is denied.” This error might be seen if the CA is unable to load any certificate templates due to widespread permission issues.

These event log entries serve as valuable diagnostic information and should be reviewed when troubleshooting certificate enrollment problems. They often point directly to permission-related issues on certificate templates.

Troubleshooting Checklist:

1. Verify Event Logs: Check the Application log on the CA server for CertSvc errors related to template loading failures.
2. Inspect Template ACL: Use Active Directory Administrative Center or ADSI Edit to examine the ACL of the affected certificate template.
3. Confirm Authenticated Users Permissions: Ensure the Authenticated Users group has Read permissions on the template. If not present, consider re-adding it.
4. Check CA Computer Account Permissions: If Authenticated Users is intentionally removed, verify that the CA server’s computer account has Read permissions.
5. Test Enrollment: After making permission changes, attempt to enroll for a certificate using the affected template to confirm the issue is resolved.
6. Replication Delay: Remember to account for Active Directory replication delays if you have made changes to ACLs and are still experiencing issues shortly after.

By systematically following these troubleshooting steps and understanding the underlying permission requirements, administrators can effectively resolve “Certificate Template Unavailable” errors and ensure smooth certificate enrollment operations in their Windows Server environments. Maintaining proper ACL configurations on certificate templates is a fundamental aspect of managing a secure and functional Public Key Infrastructure.

Do you have any experiences with certificate template issues or further questions about managing certificate enrollment in Windows Server? Share your thoughts and comments below!