In order to run a certificate-based network, admins need to understand how to create and configure X.509 certificates. X.509 is a cryptography standard for defining a public key certificate. X.509 falls in the X.500 network standards that covers electronic directory services and was developed by Telecommunication Standardization Sector of the International Telecommunications Union (ITU-T) back in 1988. x.509 is the international standard for public key infrastructure (PKI), which is required to operate certificates.
What is an X.509 Digital Certificate Template?
A certificate template provides the blueprint for admins to configure and assign attributes so the certificate knows what it’s supposed to do. Once a template is configured, it turns into a certificate and is ready for issuance.
Admins can configure certificate templates through certificate authorities (CA), which are trusted entities that issue digital certificates. An x.509 certificate follows the CA hierarchical system, meaning only CAs can sign certificates, as opposed to other standards that let anyone sign and issue certificates. When a device/user requests a certificate, the CA can be configured to determine if the device/user is allowed to enroll for a certificate and what type of certificate it should be issued. The certificate template is the blueprint for what user attributes are contained on the certificate, and what the certificate’s intended use case is.
This article will go over the many components of certificate templates, including structure, settings, policies, types of templates, use cases, and how to configure certificate templates.
- Certificate Templates are a simple and effective way to scale your certificate distribution for managed devices.
Structure of x.509 Digital Certificate Templates
This section will go over how templates are structured and what attributes admins can configure onto templates to turn them into certificates for issuance.
Subject
Here you can enter the name of the user/device the CA issues the certificate to. Most organizations opt to use this to store the certificate Common Name, which is almost always the user’s email address.
DNS
The Domain Name System (DNS) translates domain names into IP addresses so internet browsers can find and load websites. SAN:DNS is one of the attributes on a certificate and its purpose is to print device information onto the certificate.
However, with SecureW2, you insert any attribute you wish into any field in the certificate template. Above, you can see that we’ve inserted the Device’s Identity into the DNS field, as it’s really helpful for searching and managing certificates.
Issuer
The name of the CA that issues certificates. The Issuer and Subject are the same for root CAs.
Validity
Admins are able to determine how long a certificate will last.
Key Size
In a cryptographic algorithm, key size in the number of bits in a key. Currently, the RSA-recommended key size is 2048.
Signature Algorithm
The algorithm that is used to sign the private key. This is usually RSA 2048
Serial Number
The CA gives a serial number to each certificate it issues for identification.
SAN
Subject Alternative Name (SAN) structures and lists all of the domain names and IP addresses that fall under the security umbrella of a particular certificate. In the image above, the subdomains and IP addresses highlighted in yellow are protected by this certificate.
Policies
Policies define the parameter of certificates. They determine what type of certificate it can be, such as server authentication, client authentication, email, etc. Admins can define policies like security permissions, determining who has control over certificate templates.
DACL
A Discretionary Access Control List (DACL) determines which users have access to configure certificate templates.
Types of x.509 Certificate Templates
This section provides an overview of the different types of certificate templates. The types covered are the default templates in Active Directory Certificate Services (AD CS), as well as some of the Certificate Templates in SecureW2.
Administrator
These templates are used by domain administrators and provide signatures and encryption services. They’re for administrators who oversee account identification and certificate trust list (CTL) management.
Authenticated Session
Allows users to authenticate to a web server and provide their credentials for login. Commonly deployed for remote worker authentication.
Basic EFS
These templates are stored in AD with the user account info and encrypt data through the Encryption File System (EFS), which encrypts files and folders.
Computer
This certificate template covers certificate enrollment, as well as client and server authentication.
Domain Controller
Domain controllers are servers that respond to authentication requests and verify users. Active Directory and Azure AD (Microsoft Entra ID) are two common domain controllers. There are three types of domain controller certificates: domain controller, domain controller authentication, and Kerberos authentication. Kerberos is the most recent certificate template for domain controllers and is the one recommended by Microsoft to use for AD CS.
EFS Recovery Agent
Certificates that were encrypted with EFS can be decrypted using this certificate template.
Smartcard Logon
SecureW2’s certificate delivery platform allows end users to easily enroll their PIV-Backed Smartcards for a unique client certificate. A Smart Card Logon certificate template would be used for a certificate enrolled on a Smart Card that would be used for Desktop Logon.
Microsoft CA environment’s also have a Smartcard Logon template. While this process is much more complex than SecureW2’s, it’s definitely possible. Here are some helpful links:
- Yubikey Smart Card Deployment
- Micrsoft: Enabling Smart Card Logon with Third-Party CA
- Smart Card Self Enrollment Configuration
User
User certificate templates are bound to a single user to provide an identity for that specific user.
Web Server
This certificate template also encrypts data and authenticates the server for the clients. This template is necessary to set up certificate autoenrollment.
Use Cases of x.509 Certificate Templates
The sole purpose of certificate templates is to be told by a CA server what type of certificate it needs to be. However, there are many different use cases for certificates, all of which are configured onto templates.
Certificate enrollment is one of the main use cases and can either be handled manually or set up to be automatic. Manual enrollment is much more labor intensive because you have to choose the template and configure the options yourself. Automatic certificate enrollment is much easier for IT admins because they don’t need to manually configure each certificate.
Security is also an imperative feature of certificate templates. Templates can be configured for client and server authentication, so only an approved user can request a certificate and connect to the right CA.
Certificate templates offer S/MIME capabilities so users can encrypt their emails. S/MIME is an imperative security measure that enrolls the email client with a certificate so network users can be sure that when they receive an email from an IT admin or coworker, they know for sure that the email is from that person and not a phishing scam. For more information on S/MIME, click here.
Key archival and recovery are configured through certificate templates. Key archival involves storing a certificate private key and must be configured before a certificate is issued to protect the user’s private data. Key archival is imperative when using EFS. Key recovery makes it possible for admins to recover keys for data decryption.
- The primary use case for a certificate template is configuring a standard format for certificate enrollment.
- Certificate templates can be used to deploy S/MIME capabilities for email security.
Where are x.509 Certificate Templates Stored?
For Microsoft Environments they are stored in Active Directory. The direct quote from Microsoft’s documentation is “In Windows environments, certificate templates are stored as objects in the Active Directory and used by Microsoft enterprise CAs.”
For managed PKIs, like SecureW2, they are stored in the PKI and available to be customized and managed in the management GUI, which in SecureW2’s case is in our Cloud Management Portal.
How to Create x.509 Certificate Templates
Creating Certificate Templates in AD CS
We won’t go into too much detail here, but here’s a general overview for creating certificate templates with AD CS.
- Navigate to your Certificate Authority and look for Certificate Templates.
- Click on which template type you want to choose (user, server, administrator, etc.).
- Duplicate the template.
- This step is critical because you cannot create new default templates.
- Configure the required attributes, including security permissions, policies, and validity.
- Make the template available for issuance.
Every certificate template is designed differently and requires different attributes. Here are a couple configuration guides to help you along the way. These two involve configuring user and server certificate templates.
- https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj129701(v=ws.11)
- https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-the-server-certificate-template
Creating Certificate Templates in SecureW2
Creating certificate templates in SecureW2 is incredibly easy and straightforward, and is one of the reasons why so many people are switching from AD CS to SecureW2.
All the admin needs to do is navigate to Certificate Authorities under PKI Management and add a new certificate template. SecureW2’s GUI settings are easier to understand and there’s no need to duplicate templates.
x.509 Certificate Template Management
Managing certificate templates with AD CS requires extra steps because you need to duplicate default certificate templates and create new ones based on those. If you accidentally modify a default template, you can’t revert back or create a new default, so you’re stuck.
With SecureW2, managing certificate templates is incredibly easy because our GUI interface allows admins to edit or delete any templates in a matter of minutes. All you need to do is go back to the SecureW2 management portal, under Certificate Authorities, and re-configure the templates.
Another bonus that comes with using SecureW2 for template management is that SecureW2 can integrate with any MDM vendor. Each MDM has their own formula for defining attributing, and the only MDM that works effectively with AD CS is Microsoft Intune. But with SecureW2, you can easily integrate our software with your MDM, whether it’s Jamf, Airwatch, Intune, MobileIron, what have you.
Better x.509 Certificate Template Deployment and Management
Microsoft has been the big player for certificate template management for a long time, and AD CS used to be a no-brainer for certificates. That isn’t the case anymore because, as we explained, AD CS doesn’t have the same abilities as a cloud-based service like SecureW2. Certificate template deployment is much more seamless with SecureW2 than using an on-premise system like AD CS. Our software has a better GUI interface, and templates can be configured and deployed at a much faster rate because we don’t require as many steps. Better yet, our service comes at a much more affordable cost, check out pricing for more.
- AD CS has very limited certificate template options. Use a proper certificate management solution (CMS) like SecureW2 for more effective certificate lifecycle management.
