The Case for 6-Day Public TLS Certificates

In February 2025, Let’s Encrypt introduced the option to enroll for public TLS certificates with a 6-day validity period.  This represents a significant shift toward short-lived certificates and aligns with the broader industry trend of reducing certificate lifetimes to improve security. While this may seem aggressive at first glance, organizations that have embraced automation will find that extremely short-lived certificates offer compelling security and operational advantages in some scenarios.

Benefits

Extremely short-lived TLS certificates offer several important security and operational benefits, particularly for organizations that have already embraced automation for certificate lifecycle management. Key advantages include:

  • Minimized Risk of Key Compromise – 6-day certificates dramatically reduce the exposure window of private key compromise events, giving attackers a limited window of opportunity to exploit key access.
  • Automation Validation – Short-lived certificates force organizations to adopt and validate automated enrollment and renewal processes, ensuring that certificate lifecycle management is reliable and resilient.
  • IP Address Support – 6-day TLS certificates from Let’s Encrypt support IP addresses, allowing administrators to secure workloads that do not have entries in DNS.

Use Cases

6-day TLS certificates are well-suited for a range of modern workloads, especially those that benefit from frequent key rotation, automation, and dynamic provisioning. 6-Day TLS certificates are well-suited for the following workloads:

  • High Value Resources – Using 6-day TLS certificates is beneficial for high-security or sensitive workloads where frequent key rotation is desired.
  • Test Labs – High-frequency certificate rotation allows for thorough testing of automation processes to ensure operational reliability of production deployments. Rapid iteration of 6-day TLS certificates allows administrators to identify potential issues and implement changes before long-term certificates expire.
  • Ephemeral Infrastructure – 6-day TLS certificates work well with dynamic workloads such as containers, where environments are rapidly provisioned and destroyed. These hosts might only live for a few hours or days, making short-lived certificates an ideal choice in this scenario.
  • Workload Bootstrapping – 6-day TLS certificates can be used where a certificate is required only to perform initial configuration. For example, an IP-based TLS certificate can be used to configure TLS services, then later migrated to a long-term certificate when DNS is configured and the service is placed into production.

Enterprise Usage

Administrators will find that 6-day public TLS certificates work well with many popular Windows Server workloads. Here are a few examples.

  • Always On VPN – Enterprise secure remote access is a popular target for attackers because the service is exposed to the Internet. Using 6-day TLS certificates ensures frequent key rotation, reducing exposure to key compromise.
  • Remote Desktop Services – Many organizations continue to use Remote Desktop Gateway to provide access to on-premises applications, another workload that is exposed to the Internet. Using 6-day TLS certificates is equally effective in this scenario.

What About DirectAccess?

Although DirectAccess would be another ideal Windows Server workload for 6-day TLS certificates, my testing shows that it does not work. The root cause is that 6-day TLS certificates from Let’s Encrypt do NOT include subject information (the field is blank). Unfortunately, because of the way in which DirectAccess validates this certificate, it requires information in this field. More details can be found here.

https://directaccess.richardhicks.com/2026/03/16/directaccess-iphttps-and-lets-encrypt-6-day-certificates/

Summary

If you are automating certificate enrollment and renewal, it shouldn’t matter if the certificate is valid for 6 days or 60 days. In fact, shorter lifetimes can significantly improve your security posture by minimizing risk and enforcing operational discipline around certificate management. Organizations that invest in automation today will be well-positioned to adopt even shorter certificate lifetimes in the future, while those relying on manual processes will find it increasingly difficult to keep up.

Questions?

Do you have questions about certificate lifecycle automation in your environment? I’m happy to help you validate your approach and address any challenges you’re encountering. Fill out the form below, and I’ll provide you with more information.

Additional Information

Let’s Encrypt Issues First Six-Day Certificate

DirectAccess IP-HTTPS and Let’s Encrypt 6-Day TLS Certificates

The Case for Short-Lived Certificates in the Enterprise

IIS TLS Certificate Deployment with CertKit

With public TLS certificate lifetimes shrinking to just 47 days by 2029, administrators must find ways to automate certificate enrollment and renewal for workloads that require them. One of the most common is Microsoft Internet Information Services (IIS). I’ve been using CertKit.io to handle this process for workloads like Always On VPN and DirectAccess, so it made sense to migrate my public-facing IIS servers to this solution as well. The migration went smoothly, but I encountered an unexpected issue when deploying a new IIS server using CertKit.

CertKit Agent

CertKit Agents make loading certificates on the server a breeze. The CertKit agent automatically detects installed software (e.g., Terminal Services, RRAS, DirectAccess, IIS, etc.) and handles the server-side process of assigning the TLS certificate to the application. For RRAS and DirectAccess, it works perfectly. For an IIS server with an HTTPS binding and TLS certificate already configured, it works without issue as well. However, I ran into a snag when I tried to deploy a certificate to a brand-new IIS server.

New Server

After installing the CertKit agent on an IIS server, it searches for existing HTTPS web bindings to identify the workload. However, on a freshly installed IIS server, no HTTPS bindings have been configured yet, so the agent doesn’t recognize the IIS workload.

Of course, you could create an HTTPS web binding before installing the agent, but you’ll need a TLS certificate first. This introduces the classic “chicken and egg” scenario. 🤪 Fortunately, there are a few ways to resolve the issue.

Windows Certificate Store

With this method, you configure the CertKit agent to download and install the certificate into the local computer certificate store on the IIS server. Once complete, you can create the HTTPS binding in the IIS Manager console or by using PowerShell. After that, restart the CertKit agent service by running the following PowerShell command.

Restart-Service -Name certkit-agent -PassThru

The IIS workload will now appear in the agent’s Software list. At that point, you can delete the Windows certificate store configuration and replace it with the IIS configuration.

Self-Signed Certificate

Using this method before installing the CertKit agent allows the agent to automatically discover IIS after installation, which can be helpful when deploying IIS servers programmatically. First, create a short-lived certificate (one day in this example) and configure the IIS site binding by running the following PowerShell commands.

$Hostname = 'www.example.net'
$Certificate = New-SelfSignedCertificate -DnsName $Hostname -CertStoreLocation 'Cert:\LocalMachine\My' -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddDays(1) -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.1')
$Params = @{
    Name                 = 'Default Web Site'
    BindingInformation   = '*:443:'
    Protocol             = 'https'
    CertificateThumbPrint = $Certificate.Thumbprint
    CertStoreLocation    = 'Cert:\LocalMachine\My'
}
New-IISSiteBinding @Params

Once complete, run iisreset.exe to apply the changes. Now, when you install the CertKit agent, it will automatically detect IIS, and you can assign your public TLS certificate accordingly. You can delete the old self-signed certificate later if desired.

Summary

If you’re automating server builds, the self-signed certificate approach is typically the easiest because it enables IIS discovery immediately. For ad-hoc deployments, installing to the Windows certificate store first is usually the quickest option.

Additional Information

CertKit.io

CerKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

With public TLS certificate lifetimes set to drop to 200 days soon (next week!), Always On VPN and DirectAccess administrators face an increased risk of service disruption if certificates aren’t renewed on time. These shorter certificate lifetimes require more frequent renewals, substantially increasing management overhead. Although 200 days equate to roughly a twice-a-year renewal, lifetimes will decrease further to 100 days next year and eventually to just 47 days in 2029. SSTP and IP-HTTPS are TLS-based tunneling protocols used by Always On VPN and DirectAccess, respectively, tying their certificate health directly to remote access availability. Now is the time to automate the enrollment and renewal of Always On VPN SSTP and DirectAccess IP-HTTPS/TLS certificates to ensure reliable operation in the future.

Always On VPN

Previously, I wrote about using CertKit.io to automate the enrollment and renewal of public TLS certificates for Always On VPN. CertKit is an online service that administrators can use to delegate the task of enrolling for short-lived certificates from Let’s Encrypt. In that post, I shared some sample code to retrieve the certificate from CertKit and assign it to the SSTP listener for the Routing and Remote Access Service (RRAS). However, CertKit added new features to its solution, eliminating the need for additional code.

CertKit Agents

Recently, CertKit introduced CertKit Agents. These lightweight software agents are installed on Windows Servers (other operating systems are supported as well) to automate the process of downloading CertKit certificates and installing them in the local computer certificate store. Importantly, they now specifically support both the Always On VPN (SSTP) and DirectAccess (IP-HTTPS) workloads natively.

Always On VPN

The CertKit agent automatically detects the Routing and Remote Access (RRAS) workload and updates the certificate binding for the SSTP listener accordingly. Since this process requires a service restart, which terminates all current VPN connections, CertKit allows you to select an outage window for certificate updates.

Here, administrators can define the day(s) and time window during which the agent is authorized to restart the RemoteAccess service when updating the TLS certificate for SSTP. The day and time are based on the server’s configured time zone settings.

DirectAccess

Beginning with CertKit agent v1.6.2, the agent automatically detects whether DirectAccess is configured, enabling IP-HTTPS TLS certificates to be automatically enrolled and renewed. However, additional configuration is required. The following changes must be made to support CertKit for DirectAccess.

  • Service Account – Administrators must configure a service account in Active Directory for the CertKit agent. A Group Managed Service Account (gMSA) is preferred, but a standard domain service account is also supported.
  • GPO Delegation – CertKit service account must be delegated the ‘Edit settings, delete, and modify security’ permission on the DirectAccess server and client settings GPOs.
  • Log On as a Service – When using a domain service account, administrators must grant the CertKit service the ‘Log on as a service’ right on the DirectAccess server. However, when using gMSA, the ‘Log on as a service’ right is not required.
  • Local Administrator – Administrators must also add the CertKit agent service account to the Local Administrators group on the server.

Configuration Script

I have published a PowerShell script to simplify configuring the CertKit agent on DirectAccess servers. The script automatically performs all required tasks for the CertKit agent to work with DirectAccess. You will find the Enable-DACertKit.ps1 PowerShell script on GitHub. Alternatively, you can install the script directly from the PowerShell Gallery.

Install-Script -Name Enable-DACertKit -Scope CurrentUser

After installing the CertKit agent, run the PowerShell script to complete the configuration. Next, authorize the agent in the CertKit management portal and assign a certificate. Once complete, CertKit can fully manage the IP-HTTPS TLS certificate for DirectAccess.

Note: Like Always On VPN, changes to the DirectAccess IP-HTTPS certificate require a service restart, which is disruptive. Be sure to define a maintenance window (as shown previously) to ensure the change is made during non-peak times.

Summary

As TLS certificate lifecycles continue to shrink, automating certificate enrollment and renewal has become essential for both Always On VPN and DirectAccess environments. CertKit agents streamline this process by automatically retrieving, installing, and binding certificates for SSTP and IP-HTTPS, all while supporting scheduled outage windows to minimize disruption. With these new capabilities, administrators can significantly reduce operational overhead and ensure consistent, reliable remote access services without manual intervention. Visit CertKit.io to get started today.

More Information

If you would like to learn more about CertKit or see a demonstration with Always On VPN or DirectAccess, fill out the form below, and I’ll provide you with more details.

Additional Information

Always On VPN SSTP Certificate Automation with CertKit

CertKit Agents

Enable-DACertKit.ps1 on GitHub

Enable Group Managed Service Accounts