Entra Global Secure Access (GSA) Client Intune Deployment PowerShell Script

The Microsoft Entra Global Secure Access (GSA) client is commonly deployed using Microsoft Intune. To deploy the client as an Intune Win32 app, administrators package the installer and a PowerShell installation script into an .intunewin file. Microsoft provides a sample PowerShell script that creates a log, configures Windows to prefer IPv4 over IPv6, and launches the installer. However, the sample has several limitations that can make it unreliable in production environments. To address these shortcomings, I’ve refactored the code to make it more robust and better aligned with enterprise deployment best practices.

Script Improvements

Microsoft’s PowerShell script for installing the GSA client has several significant limitations. My refactored version includes the following improvements.

  1. Preserved the existing DisabledComponents setting. Microsoft’s example overwrites the entire registry value, potentially removing previously configured settings. My version sets the 0x20 bit to prefer IPv4 while preserving any other flags already present.
  2. Validates the installer’s Authenticode signature. My revised script verifies that the installer has a valid Authenticode signature and that the signing certificate identifies Microsoft Corporation as the publisher.
  3. Preserves the pending reboot state. My script records when the registry setting was changed and compares that timestamp with the device’s last boot time. If the device has not restarted, subsequent runs continue to return exit code 3010, even if an earlier installation attempt failed.
  4. Expanded exit-code handling. The script writes a timestamped PowerShell transcript to the Intune Management Extension log directory, allowing it to be included with collected Intune diagnostics. Logging failures do not prevent the installation from continuing.
  5. Intune-integrated logging. I’ve updated the script’s logging to use the Intune Management Extensions logs folder, so logs are captured by Intune’s diagnostics collection. Each run of the script generates its own timestamped log file, making troubleshooting easier. Also, logging failures never block installation.
  6. Best practice alignment. I’ve added comment-based help, culture-invariant timestamps, and a $PSScriptRoot guard with a clean error to handle script execution issues. In addition, the script is digitally signed to support environments that enforce signed-script execution policies.

GitHub

I’ve published my refactored GSA client installation script on GitHub. You can download the script here:

https://github.com/richardhicks/gsa/blob/main/Install-GSAClient.ps1

Note: The script expects the installer to be named GlobalSecureAccessInstaller.exe. However, downloaded installers typically include the version number in the filename, such as GlobalSecureAccessInstaller_<version>.exe. Before creating the .intunewin package, either rename the installer or update the $InstallerName variable in the script.

Contribute

Suggestions and contributions are welcome. If you have ideas for making the GSA client deployment more robust or reliable, please submit a pull request on GitHub.

Summary

Microsoft provides a PowerShell script to deploy the Entra GSA client via Intune, but it has several limitations. This refactored version preserves existing registry settings, validates the installer, improves reboot and exit-code handling, integrates logging with Intune diagnostics, and better aligns with enterprise deployment best practices.

Additional Information

Install-GSAClient.ps1 PowerShell Script on GitHub

Prepare Win32 App Content for Upload to Microsoft Intune

Install the Global Secure Access Client for Microsoft Windows

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

Microsoft Security Service Edge Now Generally Available

A few weeks ago, Microsoft announced the general availability of its Security Service Edge (SSE) offering, Global Secure Access (GSA). GSA encompasses Entra Internet Access, a cloud-based Secure Web Gateway, and Entra Private Access, a Zero Trust Network Access (ZTNA) solution for accessing private data and applications on-premises.

ZTNA vs. VPN

Entra Private Access will be a compelling alternative to traditional VPN solutions such as Windows Always On VPN. Where traditional VPNs grant the endpoint an IP address on the internal network, Entra Private Access provides more granular access and does not require the device to be directly connected to the network.

GSA Client

Administrators must install the GSA client on all endpoints using Entra Internet Access or Entra Private Access. Today, the client is available for Windows and Android devices. iOS and macOS clients are forthcoming.

Private Network Connector

The Entra Private Access solution relies on the Entra Private Network Connector. The Entra Private Network Connector is a software component installed on-premises that provides remote access connectivity. Previously, it was called the Azure AD Application Proxy. Essentially, it is the same technology extended to support TCP and UDP network access in addition to HTTP.

Limitations

Entra Private Access is the way of the future for secure remote access. However, today, there are still some important limitations associated with this technology.

Private DNS

Although Microsoft announced general availability for Entra Private Access, it still lacks the private DNS feature many organizations require to provide feature parity with their existing VPN. This feature is still in private preview at the time of this writing. Hopefully, Microsoft will release this feature soon.

Device Connection

Entra Private Access does not support device-based connections. This limits its capabilities for domain-joined devices. If your organization uses hybrid Entra join today, consider sticking with Always On VPN until you move to native Entra joined endpoints.

Licensing

Global Secure Access (Entra Private Access and Entra Internet Access) are included in the Microsoft Entra Suite license. More information about Entra licensing can be found here.

Additional Information

Microsoft Global Secure Access Now Generally Available

Microsoft Entra Global Secure Access (GSA) Overview

Microsoft Entra Security Service Edge (SSE) on the RunAs Radio Podcast

Microsoft Entra Plans & Pricing