All posts tagged transport layer security

Entra Internet Access TLS Inspection Fails with ERR_CERT_INVALID

Microsoft Entra Internet Access is a powerful cloud-based Secure Web Gateway (SWG) feature within the Entra Global Secure Access (GSA) Security Service Edge (SSE) solution. Entra Internet Access provides Zero Trust, identity-aware access to internet resources, private web-based applications, and Microsoft 365, with full integration with Entra Conditional Access.

TLS Inspection

Entra Internet Access includes an optional TLS Inspection feature that allows the GSA client to decrypt HTTPS traffic, inspect for threats, identify policy violations, and enforce Data Loss Prevention (DLP) policies. Importantly, enabling TLS inspection for GSA allows administrators to apply prompt injection protection policies to control the usage of generative AI applications.

TLS Inspection Certificate

Before enabling TLS inspection for Entra Internet Access, administrators must first create a TLS inspection certificate. This certificate must be signed by a trusted certification authority (CA). The process is simple and straightforward, and well-documented here.

Invalid Certificate Error

After enabling Entra Internet Access TLS inspection, administrators may find that all websites subject to TLS inspection are inaccessible. The browser displays the following error message:

Your connection isn’t private
Attackers might be trying to steal your information from <website> (for example, passwords, messages, or credit cards.)

NET:ERR_CERT_INVALID

Clicking on the Advanced button shows the following additional information:

<website> uses encryption to protect your information. When Microsoft Edge tried to connect to <website> this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be <website>, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Microsoft Edge stopped the connection before any data was exchanged.

You can’t visit <website> right now because the website sent scrambled credentials that Microsoft Edge can’t process. Network errors and attacks are usually temporary, so this page will probably work later.

Root Cause (Pun Intended!)

This issue can be caused by restrictions placed on the root CA. Specifically, if the root CA certificate includes a policy that restricts the CA path length (the number of subordinate CAs allowed downstream), the Microsoft Global Secure Access Intermediate CA, which issues certificates for TLS-inspected websites, cannot be validated successfully.

In this example, the root CA certificate includes a basic constraint that defines a maximum of 1 intermediate CA in the chain. Crucially, the extension is marked as Critical, so it must be enforced.

Because the root CA enforces a path length constraint of 1, the TLS inspection subordinate CA can exist beneath it, but no additional subordinate CA certificates are permitted. As a result, the Microsoft Global Secure Access Intermediate CA exceeds the allowed chain depth, causing certificate validation to fail.

Resolution

The fix for this issue is simple, yet complex. The root CA certificate must be renewed, this time without enforcing the CA path length policy. To do this, open an elevated command window on the root CA and run the following command.

certutil.exe -setreg policy\capathlength 0xffffffff

Important: If your CA hierarchy uses CAPolicy.inf to define the CAPathLength setting, update the file before renewing the CA certificate.

Next, restart the CA service for the change to take effect.

Restart-Service CertSvc -PassThru

Finally, renew the CA certificate.

certutil.exe -f -renewcert ReuseKeys

Restart the CA service once more for the change to take effect.

Restart-Service CertSvc -PassThru

Once complete, distribute the new root CA certificate to Active Directory and to Intune-managed endpoints using a Trusted Certificate device configuration policy.

Finally, configure a new Entra TLS inspection certificate in the Entra admin center to replace the old one, signed with the updated root CA certificate. Once the certificate has been uploaded, ensure it is enabled.

Important: Renewing a root CA certificate can be highly disruptive. Proceed with caution in production environments. Ensure that all enterprise assets receive the new root CA certificate in a timely manner. Alternatively, to reduce the chance of disruption, consider deploying a new root CA dedicated to Entra TLS inspection.

Result

Once these changes are made, the certificate chain will allow the Microsoft Global Secure Access Intermediate CA to exist beneath the TLS inspection CA, resulting in a valid certificate chain for TLS-inspected websites. Browsers will once again trust the dynamically generated certificates, eliminating the ERR_CERT_INVALID error.

The following certificate chain shows the corrected configuration after renewing the root CA certificate and recreating the TLS inspection certificate.

Summary

Entra Internet Access TLS inspection relies on a certificate chain that includes the Microsoft Global Secure Access Intermediate CA. If the root CA that signs the TLS inspection certificate enforces a restrictive path length constraint, certificate validation can fail, causing browsers to display ERR_CERT_INVALID errors for all TLS-inspected websites. Reviewing the certificate chain and understanding how basic constraints affect subordinate CAs can help quickly identify and resolve this issue. When deploying TLS inspection, ensure that CA hierarchy restrictions are compatible with this deployment scenario. Consider using a dedicated PKI hierarchy to minimize operational impact.

Additional Information

Tutorial: Enable Entra Internet Access TLS Inspection

Protect Enterprise Generative AI Applications with Prompt Injection Protection

Leave a comment
by Richard M. Hicks on June 16, 2026  •  Permalink
Posted in administration, cloud, Cloud Service, Conditional Access, Deployment, Enterprise, enterprise mobility, Entra, Entra Conditional Access, Entra Global Secure Access, Entra Internet Access, Global Secure Access, GSA, Microsoft, Microsoft Entra, Microsoft Entra Global Secure Access, Microsoft Entra ID, Microsoft Entra Internet Access, Mobility, Operational Support, Proxy, Proxy Server, public cloud, Secure Access Service Edge, Secure Service Edge, Secure Web Gateway, Security, Security Service Edge, SWG, troubleshooting, Windows 11, Zero Trust, ZTNA
Tagged , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 16, 2026

https://directaccess.richardhicks.com/2026/06/16/entra-internet-access-tls-inspection-fails-with-err_cert_invalid/

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 administration, Always On VPN, AOVPN, Automation, Certificate Authentication, Certificate Authority, Certificate Lifecycle Management, Certificate Services, certificates, CertKit, Cryptography, Deployment, Device Management, DirectAccess, Encryption, Enterprise, enterprise mobility, Infrastructure, Microsoft, Mobility, Operational Support, PKI, Remote Access, RRAS, Security, SSL, SSL and TLS, TLS, Transport Layer Security, VPN, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
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/

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 Automation, Certificate Authentication, Certificate Authority, Certificate Services, certificates, CertKit, DirectAccess, IP-HTTPS, PowerShell, routing and remote access service, RRAS, SSL, SSL and TLS, TLS, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , ,

Posted by Richard M. Hicks on April 20, 2026

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

« Older Posts