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

Always On VPN SSTP and 47-Day TLS Certificates

The Secure Socket Tunneling Protocol (SSTP) VPN protocol uses Transport Layer Security (TLS) encryption and HTTP transport over TCP port 443. SSTP is easy to configure and firewall-friendly, making it an excellent choice for the Always On VPN user tunnel. Security best practices dictate using a TLS certificate issued by a public Certification Authority (CA). Today, the maximum lifetime of a public TLS certificate is 398 days (approximately 1 year). Always On VPN administrators using SSTP are familiar with the process of renewing their SSTP certificate annually. However, that’s about to change.

47 Days

In April of this year, 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), adopted a measure reducing the current maximum lifetime of public TLS certificates to 47 days. This means Always On VPN administrators using public TLS certificates must eventually update their TLS certificates monthly.

Automation

Of course, no administrator in their right mind would want to renew SSTP certificates every month. Automating this process will be crucial to ensuring reliability and reducing management overhead. I’ll provide more details later in this post.

Why Is This Happening?

The industry has been trending toward shorter certificate lifetimes for a while now. In the old days, you could purchase a certificate valid for 5 years or more. Today, a one-year certificate is all you can get. Let’s Encrypt, a public CA that issues certificates for free, issues only 90-day lifetime certificates.

Advantages

The advantage of using short-lived certificates for public TLS certificates is that they improve security and provide agility for future changes. Public TLS certificates become less secure and trustworthy over time. The longer a certificate is valid, the less trustworthy it becomes and the longer the opportunity for an attacker to leverage a certificate for which the private key has been compromised.

Why 47 Days?

A 47-day maximum certificate lifetime allows administrators to rotate their certificates monthly (a maximum of 31 days plus some margin to resolve issues).

Not So Fast

The good news for Always On VPN administrators using SSTP with public TLS certificates is that they won’t have to worry about this immediately. The reduction in maximum certificate lifetime to 47 days takes place gradually over a few years.

  • Today, the maximum public TLS certificate lifetime is 398 days
  • On March 15, 2026, the maximum public TLS certificate lifetime will be reduced to 200 days
  • On March 15, 2027, the maximum public TLS certificate lifetime will be reduced to 100 days
  • On March 15, 2029, the maximum public TLS certificate lifetime will be reduced to 47 days

Let’s Encrypt

Over the years, I’ve deployed Always On VPN with SSTP for several customers using Let’s Encrypt TLS certificates. Let’s Encrypt is a pubic CA that issues certificates with a maximum lifetime of 90 days, so automating this task is essential. Let’s Encrypt supports ACME, a standard protocol for automating the issuance and renewal of TLS certificates, which makes automating TLS certificate installation and renewal a breeze.

Sample Script

I’ve published a sample PowerShell script demonstrating how to automate the enrollment process for Let’s Encrypt TLS certificates. It leverages the Posh-ACME PowerShell module and my AOVPNTools module to enroll and automatically install a TLS certificate for SSTP. This script will also work for DirectAccess. You can find the sample script here.

Note: My sample script demonstrates using the Cloudflare DNS plugin for Posh-ACME. Posh-ACME has plugins for many public DNS providers, which can be found here. Feel free to customize my script to meet your specific needs.

Act Now

Always On VPN administrators are advised to consider solutions to automate TLS certificate enrollment and renewal as soon as possible. If your public CA of choice doesn’t support some form of certificate automation like ACME, it’s time to find another provider.

Summary

Starting in March 2026, the maximum lifetime for public TLS certificates will be reduced gradually, reaching just 47 days by March 2029. Automation will no longer be optional for Always On VPN administrators using SSTP—it will be essential. Tools like the Posh-ACME PowerShell module provide a reliable solution to streamline certificate management and ensure uninterrupted connectivity. Now is the time to prepare for this industry shift by implementing automated certificate renewal solutions. If you’d like professional assistance with this task or simply want to learn more about your options, drop me a note via the contact page, and I’ll respond with more information.

Additional Information

TLS Certificate Lifetimes Will Officially Reduce to 47 Days – DigiCert

Posh-ACME PowerShell Module

Posh-ACME Documentation

Always On VPN Tools (AOVPNTools) PowerShell Module

Enable TLS in Microsoft SQL Server 2022

In a recent post, I described some of the security benefits of using Transport Layer Security (TLS) with Microsoft SQL Server. Configuration changes are required to take full advantage of these capabilities. By default, SQL Server uses an unmanaged, self-signed certificate, which provides little security value. The best practice is to use a certificate issued by the organization’s enterprise PKI. In this guide, I’ll demonstrate how to prepare and deploy a certificate template for SQL server using Active Directory Certificate Services (AD CS), enroll for the certificate, and configure SQL server to use the new certificate for TLS connections.

Note: I have recorded a video demonstration for enabling TLS in Microsoft SQL Server 2022 on my YouTube channel here. Enjoy!

Certificate Requirements

The minimum recommended requirements for a TLS certificate for SQL Server 2022 are:

  • Subject Name = Server’s fully qualified domain name or the alias name of the cluster
  • 2048-bit RSA key with SHA256
  • Server Authentication EKU (1.3.6.1.5.5.7.3.1)

Certificate Template

Administrators must prepare a certificate template in Active Directory (AD) adhering to the requirements listed above. On an issuing certification authority (CA) or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certificate Templates management console (certtmpl.msc) and perform the following steps.

  1. Right-click the default Web Server template and choose Duplicate Template.
  2. Select the Compatibility tab.
    1. In the Compatibility Settings section, select the latest version of Windows Server supported by your issuing CA servers from the Certification Authority drop-down list.
    1. Select Windows 10/Windows Server 2016 from the Certificate recipient drop-down list.
  3. Select the General tab.
    1. Enter a descriptive name in the Template display name field.
    1. Select a validity period of 1 year with a renewal period of 6 weeks.
  4. Select the Cryptography tab.
    1. Select Key Storage Provider from the Provider Category drop-down list.
    1. Select RSA from the Algorithm name drop-down list.
    1. Enter 2048 in the Minimum key size field.
    1. Select SHA256 from the Request hash drop-down list.
  5. Select the Issuance Requirements tab.
    1. Check the box next to CA certificate manager approval.
  6. Select the Subject Name tab.
    1. Select Supply in the request.
  7. Select the Extensions tab.
    1. Select Application Policies.
    1. Ensure that Server Authentication is the only application policy listed.
  8. Select the Security tab.
    1. Click Add.
    1. Grant Read and Enroll permissions to the SQL Server security group or the SQL server’s computer account.
    1. Ensure no other users/groups have enroll permission.

Once complete, publish the certificate template on all issuing CA servers in the organization.

Enroll Certificate

The certificate enrollment process involves several steps.

Request Certificate

To enroll for a new TLS certificate, open the computer certificate management console (certlm.msc) on the SQL server and perform the following steps.

  1. Right-click on the Personal folder and choose All Tasks > Request New Certificate.
  2. Click Next.
  3. Click Next.
  4. Check the box next to the SQL server certificate template.
  5. Click the More information is required to enroll for this certificate. Click here to configure settings link.
  6. Select the Subject tab.
  7. In the Subject Name section, select Common Name from the Type drop-down list.
  8. Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
  9. Click Add.
  10. In the Alternative name section, select DNS from the Type drop-down list.
  11. Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
  12. Click Add.
  13. [OPTIONAL] Enter the SQL server’s single-label hostname in the Value field.

Note: Adding the single-label hostname to the Subject Alternative Name list allows administrators or applications to connect to the SQL server using its short name (NetBIOS name) without resulting in a subject name mismatch error.

  1. Click Add.
  2. Click Ok.
  3. Click Enroll. The status should indicate that enrollment is pending.
  4. Click Finish.

Approve Certificate

Once the certificate request is made, the request must now be approved. On an issuing certification authority (CA), or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certification Authority management console (certsrv.msc) and perform the following steps.

  1. Expand the CA.
  2. Select Pending Requests.
  3. Note the request ID for the pending request. After approval, the request ID will be required later to retrieve the certificate.
  4. Right-click the pending request and choose All Tasks > Issue.

Important Note: I am performing the above tasks in a test lab environment. On a properly configured CA in a production environment, the requestor should not be able to approve their own request. In your environment, you may need to request that a CA administrator review and approve your request.

Install Certificate

Once the certificate has been approved and issued, open an elevated PowerShell or command window on the SQL server and perform the following steps.

  1. Enter certreq.exe -retrieve <request ID>.
  2. Select the CA where the certificate was issued.
  3. Click Ok.
  4. Select a location and enter a name for the file in the File name field.
  5. Click Save.
  6. Enter certreq.exe -accept <path to certificate file>.

Configure Certificate

Once the certificate has been enrolled on the SQL server, expand Personal > Certificates and refresh the view to confirm certificate enrollment. Next, perform the following steps.

  1. Right-click the SQL server certificate and choose All Tasks > Manage Private Keys.
  2. Click Add.
  3. Enter the name of the SQL server domain service account and click Check Names.
  4. If using the default SQL server service account, perform the following steps.
    1. Click on Locations.
      1. Select the local server.
      1. Click Ok.
      1. Enter NT Service\MSSQLSERVER and click Check Names.
  5. Click Ok.
  6. Uncheck Full control. The only permission required is Read.
  7. Click Ok.

SQL Configuration

Next, the new certificate must be assigned to the SQL Server service. Open the SQL Server Configuration Manager (sqlservermanager16.msc) and perform the following steps.

  1. Expand SQL Server Network Configuration.
  2. Right-click Protocols for MSSQLSERVER and choose Properties.
  3. Select the Certificate tab.
    1. Select the new certificate from the Certificate drop-down list.
  4. Select the Flags tab.
    1. Select Yes next to Force Strict Encryption.
  5. Click Ok.

Restart the SQL Server service for the changes to take effect.

Important Note: Selecting Force Strict Encryption will force encryption and certificate validation for all clients connecting to the SQL server. It will override any settings to bypass encryption or certificate checks. Force Strict Encryption may not be compatible with older applications or drivers. Please test thoroughly before enabling this setting.

Video

I’ve published a demonstration video for configuring TLS on Microsoft SQL Server 2022 on YouTube. You can find the video here.

Summary

After completing the configuration steps above, administrators can be assured that all communication between clients and the SQL server is fully protected with TLS using modern cryptography and their enterprise-managed certificate. With TLS enabled for SQL server communication, security is enhanced by encrypting data in transit, ensuring authentication, and protecting sensitive information from interception. In addition, this configuration helps meet compliance requirements.

Additional Information

TLS and Microsoft SQL Server 2022

Always On VPN and SQL Target Principal Name Incorrect