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

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Note: For information about configuring the F5 BIG-IP to perform IP-HTTPS preauthentication, click hereFor information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerIP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.

When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.

IP-HTTPS Connection

Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.

ICMP and IPsec

By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).

Security Risk

This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.

Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time with the default configuration.

IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerTo mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.

Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.

Citrix NetScaler Configuration

To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the client before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.

Important Considerations

Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.

Summary

The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.

References

Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/

Security Assessment of Microsoft DirectAccess [Full Document] – https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html

Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w

Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx

Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

Configure Windows Server 2012 R2  and Windows Server 2016 to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/