The Case for Short-Lived Certificates in Enterprise Environments

Digital certificates, issued by an internal, private Certification Authority (CA) like Microsoft Active Directory Certificate Services (AD CS), are commonly used in enterprise environments for user and device authentication for workloads such as VPN, Wi-Fi (802.1x), System Center Configuration Manager (SCCM), IPsec, and more. But how long should a user or device authentication certificate be valid? This question is increasingly critical as organizations strive to balance security and operational efficiency. Short-lived certificates, typically valid for weeks or months rather than years, are gaining traction as a powerful tool to enhance security. By reducing the window of opportunity for attackers to exploit compromised credentials, short-lived certificates offer a proactive approach to mitigating risks while aligning with evolving security best practices and the needs of modern IT infrastructures.

What is a Certificate?

A digital certificate is a document that binds an identity to an asymmetric key pair (public key and private key). Certificates offer strong, phishing-resistant authentication that improves security and assurance for users and devices authenticating to Microsoft Active Directory (AD). When a certificate is issued, an administrator decides how long the certificate will be valid. The criticality of this setting is often overlooked.

Certificate Lifetime

Administrators must define the certificate’s validity period when creating a certificate template in AD CS or an Intune PKCS or SCEP device configuration policy. Most commonly, administrators select the default one-year validity period. However, public CAs are trending toward shorter certificate lifetimes, and strong consideration should be given to their use in private enterprise deployments.

Current Standards

Today, the maximum certificate lifetime for a publicly issued TLS certificate is 398 days (approximately 13 months). This standard is imposed by the CA/Browser Forum, a voluntary consortium of public CAs, browser vendors, and other industry stakeholders that develop and promote security standards and best practices for digital certificates and Public Key Infrastructure (PKI). They established the 398-day certificate lifetime mainly in response to the previous decade’s plethora of SSL/TLS vulnerabilities.

Challenges

Having certificates with long lifetimes poses significant challenges for administrators when responding to key compromise events or zero-day vulnerabilities. This may necessitate urgent certificate replacement, often involving manual intervention. To address these challenges and promote automation, some public CAs like Let’s Encrypt issue certificates with much shorter lifetimes than one year.

Public CA Certificates

Shorter lifetimes for public SSL/TLS certificates have numerous positive security benefits. Short-lived certificates provide agility to update cryptography settings more rapidly than long-lived certificates. Also, the short lifetime of the certificate is beneficial if the private key is compromised because it limits the amount of time an attacker can exploit the stolen key, limiting exposure and reducing potential damage. These security benefits have driven significant changes in public CA practices, as seen in today’s standards.

47 Days

Recently, I wrote about a new directive from the CA/Browser Forum, which adopted a measure reducing the current maximum lifetime of public TLS certificates to 47 days. The maximum lifetime for public TLS certificates will be gradually reduced to allow the industry to adopt short-lived certificates.

Enterprise CA Certificates

Private enterprise PKI deployments like AD CS are not required to adhere to CA/Browser Forum mandates. Organizations are free to manage their internal PKI however they choose. However, examining industry trends and ensuring that security best practices are aligned as much as possible is crucial. While public CAs set the pace, private enterprise PKI can adopt similar strategies to bolster security.

AD Authentication

As stated previously, many positive security benefits are associated with short-lived certificates, especially for authentication to Active Directory.

PKINIT

PKINIT is an extension to the Kerberos protocol that enables certificate-based authentication with Active Directory (AD). You can read about the details here, but PKINIT allows a principal (user or device) to authenticate to AD by simply demonstrating control of the private key. Thus, protecting the private key is vital.

TPM

Enrolling certificates in a Trusted Platform Module (TPM) is the best way to ensure private keys remain private. No one, including administrators, can export private keys protected by TPM. Administrators should ensure TPM enrollment for client authentication certificates whenever possible.

Guidance

Today, I recommend that my customers issue end entity user and device authentication certificates with a lifetime of no more than one year for 2048-bit RSA certificates with private keys stored on TPM. However, there are important considerations and compelling advantages to using much shorter lifetime certificates.

Best Practice

General use client authentication certificates should be enrolled to TPM without exception and have a valid lifetime of no more than one year. However, there is still value in using shorter lifetime certificates, even with TPM. For example, short-lived certificates ensure timely renewal, which can be helpful when implementing changes to certificate templates. A perfect example of this is the changes required to support KB5014754. Administrators may wish to use certificates with validity periods of less than one year to ensure timely replication of certificate settings changes and to provide more frequent key rotation.

Non-TPM

There may be scenarios where a client authentication certificate must be issued to a device without a TPM. Examples include virtual machines without TPM, VDI deployments, and legacy devices. These cases should be treated as exceptions and managed accordingly. Consider shortening the lifetime of non-TPM certificates to 90 days or less.

Privileged Users

Administrators or other privileged accounts enrolling for certificates can benefit from even shorter validity periods. Consider issuing client authentication certificates to these users with certificate lifetimes of 30 days or less.

Considerations

Short-lived certificates aren’t always ideal in all cases. For example, consider a scenario where a user or device is offline for a prolonged period, such as extended vacations, maternity or paternity leave, or sabbaticals. Users may experience issues accessing resources after returning from an extended absence. Of course, if they can re-enroll for certificates, this shouldn’t be a problem. For AD CS, it means connectivity to an enterprise issuing CA server. Intune-managed endpoints simply need Internet access to obtain a new certificate.

Automation

Working with short-lived certificates manually is infeasible. Automation is the key to success with short-lived certificates. For client authentication certificates issued on-premises, enabling certificate autoenrollment via group policy ensures that all domain-joined devices enroll and renew their certificates automatically. Certificates deployed and managed using Microsoft Intune are automated by default.

Summary

The next time you create a certificate template in AD CS or Intune, consider the certificate lifetime. Recommended best practice is no more than one year validity period for 2048-bit RSA end-entity certificates with hardware-backed key storage. However, consider shorter validity periods for those cases where it makes sense. Prioritize TPM enrollment and put additional controls in place for exceptions. Ensure automated enrollment and renewal are in place to reduce administrative overhead. Following the guidance outlined above, your organization will reduce its attack surface and limit exposure to compromised certificates.

More Information

If you’d like to learn more about implementing short-lived certificates in your organization, fill out the form below, and I’ll provide more information.

References

Digital Certificates for Strong Authentication

Digital Certificates and TPM

Drawbacks of Multifactor Authentication

Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol

Arizona Systems Management User Group March 2025

I’m excited to announce that I’ll be speaking at the Arizona Systems Management User Group (AZSMUG) at their next user group meeting on Friday, March 7, at 9:00 AM MST. I am presenting on the topic of Certificate Deployment Strategies with Microsoft Intune.

Intune and Certificates

My session at AZSMUG will provide an overview of issuing and managing certificates with Microsoft Intune. We’ll begin by examining common scenarios for certificate authentication and explore various delivery methods, including PKCS and SCEP. Additionally, we’ll discuss supporting technologies such as the Network Device Enrollment Service (NDES) and review deployment strategies and high availability options for the Intune Certificate Connector. The session will also cover Cloud PKI for Intune, integration with on-premises Active Directory, and best practices for securing certificate lifecycles and key management in enterprise environments.

Register Now

If you are in the Phoenix area and would like to attend the user group meeting on Friday, March 7, you will find the registration link here. Hope to see you there!

Additional Information

Arizona Systems Management User Group

Intune and Certificates Masterclass

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN Dynamic Profile Configurator (DPC) is a software solution that enables administrators to deploy and manage Always On VPN client configuration settings using Active Directory and Group Policy or Microsoft Intune. DPC began life as a commercial product. Recently, DPC has been released to the public via open source. DPC open source allows administrators everywhere to deploy the solution without cost. If you’re not using DPC today, I’d strongly recommend it. If you were previously a DPC commercial customer, you’ll want to migrate to DPC open source soon.

We’re on Discord! Join the conversation: https://discord.aovpndpc.com/.

Migration

Migrating from DPC commercial to open source requires the administrator to deploy a Group Policy Object (GPO) and client software in a specific order to avoid disruption to end users. Perform the following steps to complete the migration.

GPO Files

Download the DPC v5.0 (open source) group policy settings file (ADMX) file here and the language definition (ADML) file here.

After downloading the files, copy dpc.admx to the following location.

\\<DC name>\sysvol\<domain name>\Policies\PolicyDefinitions

Next, copy dpc.adml to the following location.

\\<DC name>\sysvol\<domain name>\Policies\PolicyDefinitions\en-US

Once complete, allow domain controller replication to finish before deploying DPC group policy settings.

New GPO

Create a new GPO that will contain the VPN client configuration settings. Do NOT copy the original DPC commercial GPO. Starting with a blank GPO is best to ensure proper operation and prevent conflicts. Also, please note the location for DPC settings has changed. The new location for DPC v5.0 settings is:

Computer Configuration > Policies > Administrative Templates > DPC Client

You can now link the GPO to the applicable OU(s) or complete this task before deploying the new software.

Migration Tool

The easiest way to migrate from DPC commercial to open source is to migrate the settings from the current GPO to a new one. A PowerShell script is available to simplify this task. You can download the Migrate-DpcConfig.ps1 PowerShell script here.

Note: It is not strictly required to migrate your current settings from DPC commercial. Although this migration script makes importing settings easier, nothing prevents you from creating a new GPO for DPC open source and starting from scratch if you wish.

Prerequisites

The PowerShell migration script requires the installation of the Remote Server Administration Tools (RSAT). Specifically, the Group Policy Management tools are needed. Although it’s possible to run this script on a domain controller, it is not recommended. The best practice is to install the RSAT tools on an administrative workstation or server.

You can install the necessary RSAT feature on Windows 11 by opening an elevated PowerShell or command window and running the following command.

dism.exe /Online /add-capability /CapabilityName:Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0

On Windows Server, you can install the Group Policy Management tools by opening an elevated PowerShell command window and running the following command.

Install-WindowsFeature -Name GPMC

Once complete, restart the server to complete the installation process.

Import Settings

To migrate the DPC settings, open an elevated PowerShell command window and run the following command.

.\Migrate-DpcSetting.ps1 -PreviousGPOName <name of old DPC GPO> -NewGPOName <name of new DPC GPO>

For example,

.\Migrate-DpcSetting.ps1 -PreviousGPOName ‘Always On VPN DPC’ -NewGPOName ‘Always On VPN DPC – Open Source’

Apply GPO

If not done earlier, link the new DPC open-source GPO to the applicable OU(s). Do NOT unlink or delete the old GPO until all endpoints have been upgraded to the DPC v5.0 client.

Install Software

Once the new GPO has been configured and applied in Active Directory, the next step is to upgrade the DPC commercial client to the DPC open source client (v5.0). Software can be deployed via GPO using Active Directory software installation, SCCM, or any other method you use in your environment to deploy software. No switches or additional parameters are required to perform the upgrade. Simply run the .MSI file on the device, and the upgrade will occur automatically.

Important Note: Administrators must ensure that the new GPO settings are applied to the endpoint before installing the DPC v5.0 client.

Clean Up

After all endpoints have been upgraded to DPC v5.0, administrators can remove the DPC commercial GPO from AD. In addition, the commercial DPC ADMX and ADML files can be removed from domain controllers if desired.

Need Help?

If you’d like assistance migrating DPC commercial to open source, please don’t hesitate to reach out! I’m available to answer questions or provide remote assistance if necessary. You can reach me on the DPC-Chat channel on Discord here. Alternatively, you can fill out the form below, and I’ll provide more information.

Additional Information

PowerON Platforms Are No More

Always On VPN DPC Open Source

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune