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

What’s New in Entra Global Secure Access Client v2.28.96

On April 27, 2026, Microsoft announced an update for the Entra Global Secure Access (GSA) client version 2.28.96. This new release includes improvements to the user experience for BYOD scenarios, to surface more information about endpoint status on the main screen, and to Intelligent Local Access (ILA).

Sign Out

Microsoft has changed how the Sign Out button is displayed depending on the device’s join type. With GSA client 2.28.96, the Sign Out button now appears by default only on Microsoft Entra-registered devices. This option is hidden on Microsoft Entra-joined devices but can optionally be displayed by setting a registry key.

Intelligent Local Access

This update also includes changes to the Intelligent Local Access (ILA) feature. Administrators can now assign a private application to multiple private networks. In addition, the GSA client now includes a new Private Access Definitions section on the Forwarding Profile tab of the Advanced Diagnostics tool. This new section includes the Private DNS definitions and a new Private network definitions section, which detail the current ILA configuration, including defined private networks, configured DNS server addresses, the FQDN to resolve for the private network, and the expected IP address for the ILA FQDN.

Additional Changes

GSA client v2.28.96 also includes additional changes to address known issues and bugs.

  • Internet connection test changed from msn.com to www.msftconnecttest.com
  • Additional log data collection, including Kerberos logs and the output of gpresult.exe
  • Log collection includes the list of trusted root Certification Authorities (CAs) on the endpoint

Download GSA v2.28.96

Administrators can download the latest release of the Global Secure Access (GSA) client here.

Additional Information

Global Secure Access Client for Windows v2.28.96

Entra Private Access Intelligent Local Access (ILA)

Entra Private Access and BYOD

Always On VPN IKEv2 Security Vulnerability April 2026

Microsoft published its Security Updates for April 2026 today, and the good news is that there are no Windows Server Routing and Remote Access (RRAS) vulnerabilities this month. However, they disclosed a critical remote code execution (RCE) vulnerability that impacts deployments using Internet Key Exchange version 2 (IKEv2).

IKE Service Extensions RCE

CVE-2026-33824 addresses a security vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions. This vulnerability is a Remote Code Execution (RCE) vulnerability, with a CVSS 3.1 base score of 9.8 (Critical). Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected.

Impact

This vulnerability presents a unique challenge to Always On VPN administrators as IKEv2 is required to support device tunnel connections. Some implementations also use IKEv2 for the user tunnel. In either case, the vulnerable VPN server, often domain-joined, is reachable from the Internet, greatly increasing the attack surface and exposure to this vulnerability.

Recommendations

For deployments that use IKEv2 (device or user tunnel), administrators should update their RRAS server as soon as possible to protect against potential attacks on this service.

Not Using IKEv2?

If you are not using the device tunnel or IKEv2 for the user tunnel, ensure the following IKEv2 ports are blocked at the edge firewall.

  • Inbound UDP port 500 (IKE)
  • Inbound UDP port 4500 (IKE NAT-T)

In addition, consider disabling IKEv2 on the RRAS server by opening an elevated command window and running the following command.

netsh.exe ras set wanports device = "WAN Miniport (IKEv2)" rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

Optionally, you can use the Routing and Remote Access management console (rrasmgnt.msc) to perform this task.

  1. Right-click on Ports and choose Properties.
  2. Select WAN Miniport (IKEv2).
  3. Click Configure.
  4. Uncheck Remote access connections (inbound only).
  5. Uncheck Demand-dial routing connection (inbound and outbound).
  6. Enter 0 in the Maximum ports field.
  7. Click Ok.

Additional Information

Microsoft Security Updates for April 2026

CVE-2026-33824 – Windows Internet Key Exchange (IKE) Service Extension RCE