All posts in category TLS

WEBINAR: Preparing for 100-Day Certificates with CertKit

Join me and the CertKit team on Tuesday, October 6, 2026, at 9:00 AM PDT for a free, live webinar about the upcoming reduction in public TLS certificate lifetimes. Beginning March 15, 2027, the maximum validity period for public TLS certificates will be reduced to 100 days. This change will make manual certificate management increasingly difficult for many organizations.

Automation

Shorter certificate lifetimes require organizations to identify, enroll, deploy, and renew certificates more frequently. Automation can help reduce the administrative effort and the risk of service interruptions caused by expired certificates. This is especially important for public-facing Microsoft workloads such as Internet Information Services (IIS), Remote Desktop Services (RDS), Always On VPN, DirectAccess, and other services that use public TLS certificates.

Visibility

Effective certificate management begins with knowing which certificates exist, where they are installed, and when they expire. Without this visibility, organizations may overlook certificates until they are close to expiration or have already expired.

Internal Certificates

Certificates issued by a private certification authority (CA) aren’t subject to the lifetime restrictions imposed on public TLS certificates. However, they still require inventory, monitoring, and renewal. A consistent approach to managing public and private certificates can help reduce operational overhead.

How CertKit Helps

CertKit is a cloud-based service for managing public and private TLS certificates. During the webinar, we’ll demonstrate how CertKit provides visibility into certificate inventories and expiration dates while automating common lifecycle tasks such as enrollment, deployment, and renewal. We’ll also review recent additions to the service.

Register Now

The webinar takes place on Tuesday, October 6, at 9:00 AM PDT. Registration is required. Everyone who registers will be notified when the session recording is available.

Leave a comment
by Richard M. Hicks on September 22, 2026  •  Permalink
Posted in Always On VPN, Cloud PKI, DirectAccess, PKI, PowerShell, TLS, Training and Events, Windows Server
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on September 22, 2026

https://directaccess.richardhicks.com/2026/09/22/webinar-preparing-for-100-day-certificates-with-certkit/

Intranet Certificate Monitoring with CertKit

CertKit is a cloud-based solution that automates the issuance and management of public TLS certificates. It also provides certificate monitoring and alerting for public-facing workloads. However, many organizations have internal (non-public-facing) services that also use TLS. CertKit agent v1.13.0, currently in preview, closes this gap by providing visibility into TLS certificates used by intranet resources. After installing the latest release of the agent, CertKit can now provide visibility into the status of TLS certificates for internal resources.

Intranet Monitoring

After installing or updating the CertKit agent to v1.13.0, administrators can select an internal TLS service to monitor. Follow the steps below to enable this feature.

Certificate Collection

I recommend creating a separate Certificate Collection to support intranet monitoring. In the CertKit management console, click Add Collection, enter a unique, descriptive name, and click Add Collection.

Install the Agent

Once the new collection is created, navigate to the Agents tab, select your platform, then download, install, and register the agent.

Monitor New Host

After the agent is installed and registered, navigate to the Monitoring tab and click Monitor New Host. Enter the fully qualified domain name (FQDN) of the resource and specify its TLS port. Under Host Visibility, select Internal, and then choose the agent to monitor the host from. When finished, click Monitor Host.

Note: The server running the CertKit agent does not require a TLS certificate of its own to monitor internal resources.

Monitored Hosts

CertKit can track certificates for any internal workload that uses TLS. In this example, the monitored resources include web applications, security appliances, load balancers, and HTTP CRL distribution points. The list also includes LDAPS on the domain controllers and the RDP and WinRM HTTPS services on the management workstation.

The circle next to each resource indicates its certificate status. Green indicates a healthy certificate, yellow indicates one approaching expiration, and red indicates an expired certificate or another detected issue.

Note: The RDP certificate on the management workstation appears red because it contains only the Remote Desktop Authentication EKU (1.3.6.1.4.1.311.54.1.2). It intentionally does not include Server Authentication, which CertKit currently expects when validating the service. CertKit is aware of this limitation and plans to address it in a future release.

Host Discovery

CertKit provides robust discovery for public websites but does not currently offer equivalent functionality for intranet resources. Administrators can identify internal systems listening on a specific port by using Nmap.

nmap.exe -Pn -p [port] --open [internal subnet]

For example:

nmap.exe -Pn -p 443 --open 172.16.0.0/24

Alternatively, add the -oX switch to save the output in XML format.

nmap.exe -Pn -p 443 --open 172.16.0.0/24 -oX scan.xml

The resulting Nmap XML file output can be converted to CSV format using this PowerShell code.

Summary

CertKit agent v1.13.0 extends certificate monitoring to internal TLS services, giving administrators greater visibility into certificates that were previously difficult to track. Although intranet host discovery remains a manual process, tools such as Nmap and PowerShell can help identify resources to add to the monitoring platform

Getting Started with CertKit

Need help improving certificate visibility and management across your organization? Want to automate public TLS certificate enrollment for workloads such as DirectAccess, Always On VPN, IIS, SQL, and more? I can help you assess your certificate environment, identify monitoring gaps, and develop a strategy for managing certificates across internal and public-facing workloads. Fill out the form below, and I’ll provide you with more information.

← Back

Thank you for your response. ✨

Additional Information

CertKit Website

What Is CertKit?

CerKit Agent Support for Always On VPN SSTP and DirectAccess IPHTTPS TLS Certificates

IIS TLS Certificate Deployment with CertKit

The Case for 6-Day Public TLS Certificates

DirectAccess IPHTTPS and Let’s Encrypt 6-Day TLS Certificates

Leave a comment
by Richard M. Hicks on August 26, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cloud PKI, DirectAccess, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on August 26, 2026

https://directaccess.richardhicks.com/2026/08/26/intranet-certificate-monitoring-with-certkit/

Entra Internet Access TLS Inspection and Always On VPN: Troubleshooting SSTP Connection Failures

Microsoft Entra Global Secure Access (GSA) is a cloud-based Security Service Edge (SSE) solution that includes Entra Private Access to provide zero-trust network access to private data and applications, and Entra Internet Access to provide security controls for general internet access. Entra Internet Access includes features such as web content filtering, AI prompt controls, TLS inspection, and more. Entra Private Access and Entra Internet Access share a common client: the Global Secure Access Client.

TLS Inspection

TLS inspection is a powerful feature of Entra Internet Access that allows inspection and policy enforcement for encrypted internet traffic. It enables more thorough inspection and is required for features such as AI prompt policies. When TLS inspection is enabled, the TLS connection from the target server (origin server) is terminated by the Entra service. A new session is created between the cloud and the endpoint using a dynamically generated TLS certificate issued by Entra. As Entra holds the private key for this certificate, it can decrypt and inspect traffic as necessary.

Always On VPN

Recently, a customer asked me to help troubleshoot an Always On VPN user tunnel connectivity issue. The problem began shortly after deploying the Global Secure Access client with TLS inspection enabled. Administrators had configured the default TLS inspection policy to inspect traffic for all websites.

User Tunnel Failures

Attempts to manually start the Always On VPN user tunnel resulted in a failed connection attempt with the following error message.

Error 0x800704D4: The network connection was aborted by the local system.

Event Logs

Reviewing the client event logs revealed numerous Event ID 20227 entries from the RasClient source with the following error message.

The user DOMAIN\User dialed a connection named [connection name] which has failed. The error code returned on failure is -2147023660.

Note: Error code -2147023660 is the decimal equivalent of 0x800704D4.

Troubleshooting

Initial testing with Test-NetConnection confirmed that TCP port 443 on the VPN server was reachable. However, using Get-TlsCertificate revealed the real problem.

Although the certificate subject matched the VPN server, the issuer did not. Instead of the VPN server’s issuing CA, the certificate had been issued by Microsoft Entra Global Secure Access, confirming that TLS inspection was intercepting the connection.

SSTP and TLS Inspection

The Secure Socket Tunneling Protocol (SSTP) is a Microsoft proprietary VPN transport that uses HTTP for tunneling and TLS for security. Unlike a web browser, which can establish a new trusted TLS session with an inspection proxy, SSTP validates the VPN server’s certificate as part of establishing the VPN tunnel. Any certificate substitution, even by a trusted TLS inspection service, changes the server certificate thumbprint and causes SSTP validation to fail.

Workaround

The solution is to create a TLS inspection exclusion policy to exempt inspection for the VPN server FQDN(s), as shown here.

Summary

Microsoft Entra Internet Access TLS inspection can unintentionally interfere with Always On VPN deployments that use SSTP. Because TLS inspection replaces the VPN server’s certificate with one issued by Microsoft Entra, SSTP detects the certificate mismatch and terminates the connection. If you use Always On VPN with Entra Internet Access, configure a TLS inspection exclusion for your VPN server FQDNs to prevent interception while preserving TLS inspection for general internet traffic.

Additional Information

Always On VPN vs. Entra Private Access: Choosing the Right Access Model for your Organization

What is Microsoft Entra Global Secure Access?

Microsoft Entra Internet Access

Microsoft Entra Private Access

Always On VPN SSTP and 47-Day TLS Certificates

Always On VPN SSTP and HSTS

Leave a comment
by Richard M. Hicks on July 22, 2026  •  Permalink
Posted in Always On VPN, Azure and AWS, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, PKI, TLS, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on July 22, 2026

https://directaccess.richardhicks.com/2026/07/22/entra-internet-access-tls-inspection-and-always-on-vpn-troubleshooting-sstp-connection-failures/

Webinar: Certificate Automation in Practice – A Technical Deep Dive

If you manage Windows Server workloads that require public TLS certificates like Always On VPN, DirectAccess, Remote Desktop Gateway, Internet Information Services (IIS), and others, you know that certificate expirations don’t send friendly reminders. Certificates expire quietly. Too often, end users are the ones who sound the alarm—when resources are already unavailable. Of course, this never happens at a convenient time. It’s usually the middle of the night, on the weekend.

Missed the event? Watch the on-demand replay here.

Current State

Most Windows IT teams are still managing certificates the same way they did years ago, using spreadsheets, calendar reminders, and an assortment of renewal scripts. It usually works… until it suddenly doesn’t.

Free Webinar

I’m pleased to announce that I’ll be joining Todd Gardner from CertKit for a free live webinar on Tuesday, June 16, at 11:00 AM CDT, in which we will break down the following:

  • Why certificate mismanagement causes so much pain at scale
  • How to build real automation that works across your full environment, including internal services and vendor appliances
  • A live demonstration of CertKit showing end-to-end discovery, monitoring, and automated renewal

There will also be time for live Q&A, so bring your questions!

Join Us!

If you’re tired of patching the problem with fragile scripts and assorted reminders, join us to learn about a fully automated solution that can dramatically improve the situation. Register now and don’t miss this opportunity to reduce your TLS certificate management burden and end the need for 2 AM certificate renewal fire drills.

Webinar Details

Webinar: TLS Certificate Automation for Windows Infrastructure
Hosts: Todd Gardner (CertKit) and Richard Hicks (Richard M. Hicks Consulting, Inc.)
Date: Tuesday, June 16
Time: 11:00 AM CDT
Registration: Click here to register!

Recording

If you are unable to attend the live session, be sure to register to receive a link to the recorded session for on-demand viewing.

Leave a comment
by Richard M. Hicks on June 5, 2026  •  Permalink
Posted in Certificate-Based Authentication, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on June 5, 2026

https://directaccess.richardhicks.com/2026/06/05/webinar-certificate-automation-in-practice-a-technical-deep-dive/

Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise

Leave a comment
by Richard M. Hicks on May 18, 2026  •  Permalink
Posted in Always On VPN, Authentication and MFA, Certificate-Based Authentication, Cryptography, PKI, PowerShell, Security Updates, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on May 18, 2026

https://directaccess.richardhicks.com/2026/05/18/microsoft-ad-cs-adds-post-quantum-cryptography-support-with-ml-dsa/

Techmentor Event Microsoft HQ 2026

I’m pleased to announce I’ll be attending the Techmentor Event at Microsoft Headquarters in Redmond, WA, August 3-7, 2026. Register now and save $500.00 with the discount code HICKS.

Sessions

I’ll be delivering three sessions at this year’s event.

Join Me

The event is shaping up to be one of the best, with industry experts from around the world presenting on many important topics. Be sure to join me! Don’t miss out on this fantastic opportunity to learn from the best in the industry. Register today. Hope to see you there!

Leave a comment
by Richard M. Hicks on May 9, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Entra Global Secure Access, Entra ID, Entra Private Access, PKI, TLS, Training and Events, Zero Trust and SSE
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on May 9, 2026

https://directaccess.richardhicks.com/2026/05/09/techmentor-event-microsoft-hq-2026/

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

2 Comments
by Richard M. Hicks on May 4, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cryptography, DirectAccess, Microsoft Intune, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , ,

Posted by Richard M. Hicks on May 4, 2026

https://directaccess.richardhicks.com/2026/05/04/the-case-for-6-day-public-tls-certificates/

Webinar: Certificate Automation for Windows Infrastructure

If you manage Windows Server workloads that require public TLS certificates like Always On VPN, DirectAccess, Remote Desktop Gateway, Internet Information Services (IIS), and others, you know that certificate expirations don’t send friendly reminders. Certificates expire quietly. Too often, end users are the ones who sound the alarm—when resources are already unavailable. Of course, this never happens at a convenient time. It’s usually the middle of the night, on the weekend.

Did you miss the webinar? You can view it on demand here!

Current State

Most Windows IT teams are still managing certificates the same way they did years ago, using spreadsheets, calendar reminders, and an assortment of renewal scripts. It usually works… until it suddenly doesn’t.

Free Webinar

I’m pleased to announce that I’ll be joining Todd Gardner from CertKit for a free live webinar on Tuesday, May 26, at 11:00 AM CDT, in which we will break down the following:

  • Why certificate mismanagement causes so much pain at scale
  • How to build real automation that works across your full environment, including internal services and vendor appliances
  • A live demonstration of CertKit showing end-to-end discovery, monitoring, and automated renewal

There will also be time for live Q&A, so bring your questions!

Join Us!

If you’re tired of patching the problem with fragile scripts and assorted reminders, join us to learn about a fully automated solution that can dramatically improve the situation. Register now and don’t miss this opportunity to reduce your TLS certificate management burden and end the need for 2 AM certificate renewal fire drills.

Webinar Details

Webinar: TLS Certificate Automation for Windows Infrastructure
Hosts: Todd Gardner (CertKit) and Richard Hicks (Richard M. Hicks Consulting, Inc.)
Date: Tuesday, May 26
Time: 11:00 AM CDT
Registration: Click here to register!

Recording

If you missed the live event, you can view the on demand recording here!

Leave a comment
by Richard M. Hicks on April 28, 2026  •  Permalink
Posted in Certificate-Based Authentication, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on April 28, 2026

https://directaccess.richardhicks.com/2026/04/28/webinar-certificate-automation-for-windows-infrastructure/

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

Leave a comment
by Richard M. Hicks on April 20, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, DirectAccess, PKI, PowerShell, TLS, Windows Server
Tagged , , , ,

Posted by Richard M. Hicks on April 20, 2026

https://directaccess.richardhicks.com/2026/04/20/iis-tls-certificate-deployment-with-certkit/

DirectAccess IPHTTPS and Let’s Encrypt 6-Day Certificates

I’ve written extensively about how public TLS certificate lifetimes will drop to just 47 days by March 2029. Before then, we’ll see certificate lifetimes gradually drop from the current 398 days to 200 days on March 15, 2026, and then to 100 days on March 15, 2027. In preparation for this, I’ve been working with many customers to deploy automated certificate enrollment and renewal solutions to eliminate the need for manual intervention. Interestingly, Let’s Encrypt now offers extremely short-lived certificates that are good for just 6 days! While they work just fine for Always On VPN, I discovered they will not work for DirectAccess.

6-Day Certificate

After successfully enrolling for a 6-day TLS certificate from Let’s Encrypt (I used CertKit, BTW!), I encountered an error when trying to assign the short-lived certificate to the IP-HTTPS listener in the DirectAccess configuration. Specifically, when running the Set-RemoteAccess PowerShell command, I received the following error.

Set-RemoteAccess: The parameter is incorrect.

Further investigation showed that I could install other public TLS certificates just fine. For some reason, though, DirectAccess did not like this new 6-day certificate.

Missing Subject Name

After digging a bit deeper, I realized the Subject field of the new 6-day Let’s Encrypt certificate was empty.

Subject vs. SAN in Modern TLS

Modern TLS clients rely entirely on the Subject Alternative Name (SAN) field for identity validation, and the older practice of matching against the certificate’s Subject field has been phased out for many years. Many certificate authorities, including Let’s Encrypt, now leave the Subject field empty because it no longer serves a functional purpose in current TLS implementations. DirectAccess still expects this field to contain data and does not properly fall back to SAN‑only validation. As a result, any certificate with an empty Subject field, such as the new 6‑day certificates from Let’s Encrypt, will fail when applied to the DirectAccess IP‑HTTPS listener.

Workaround

Admittedly, using 6-Day public TLS certificates for DirectAccess is extreme and likely overkill for this workload. The good news is that DirectAccess still works perfectly with 90-day Let’s Encrypt certificates, so the lack of 6-day certificate support should not be impactful.

CertKit

Have you heard about CertKit? CertKit, an online service for automating Let’s Encrypt certificate enrollment and renewal, has added support for Always On VPN and DirectAccess. Find details on leveraging it for public TLS certificates for these solutions here.

Additional Information

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN and 47-Day Public TLS Certificates

The Case for Short-Lived Certificates in Enterprise Environments

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

Leave a comment
by Richard M. Hicks on March 16, 2026  •  Permalink
Posted in Always On VPN, Azure and AWS, Cryptography, DirectAccess, IPv6, PKI, PowerShell, TLS, Windows Server
Tagged , , , , , ,

Posted by Richard M. Hicks on March 16, 2026

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

« Older Posts