How to Revoke One Azure Point-to-Site Client Certificate

Revoking one Azure Point-to-Site client means adding its thumbprint to the gateway's revoked list. It does not mean deleting the trusted root. The root is the issuing authority for every client certificate you ever handed out, so removing it is a different operation with a much larger blast radius. The unit of revocation here is a single certificate.

Step 1: Pin the certificate you mean

Start from the certificate record, not from a display name. Azure shows a friendly name you typed yourself, and that label does not have to match the subject or the device it was issued to.

One more check before you revoke: find out how many devices present it. If several laptops were built from copies of the same PFX, revoking the thumbprint locks out all of them, and Azure has no way to tell the lost one from the spare in the drawer.

On the client, Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotAfter lists what is installed for that user, and Cert:\LocalMachine\My is worth checking as well because the VPN client may pick from either store. Compare the thumbprint against your enrollment inventory. A renewed certificate has a different thumbprint even when the subject is identical.

You do not need the client's private key or a password-protected PFX to read a public certificate's thumbprint. Any procedure that demands one was copied from a different task.

Step 2: Add it to the gateway's revoked list

In the portal, open the virtual network gateway, then Point-to-site configuration, then the revoked certificates section. Add a friendly name you will recognise in six months and paste the thumbprint as one continuous string with the spaces removed.

Check which gateway is selected before you save, because a subscription with several gateways is exactly where this goes wrong. Microsoft's certificate configuration guide states that once the update completes, the certificate can no longer be used to connect.

Confirm the stored value afterwards rather than trusting the portal toast: az network vnet-gateway show --name gw-p2s --resource-group rg-vpn --query "vpnClientConfiguration.vpnClientRevokedCertificates" prints what the gateway actually holds.

Step 3: Verify both directions

Test the denial with the revoked certificate, then test that a different certificate under the same root still authenticates. That second test is the one people skip, and it is the one that catches an accidental root removal or a policy change nobody mentioned. Use a device where you can see which certificate is being presented. A client holding several certificates may quietly use a working one and make your revocation look broken.

Record both results in the ticket. A revocation verified only in the denial direction is half verified.

Step 4: Sessions that are already up

The documented outcome concerns new connections. Do not stretch it into a promise that every existing tunnel drops the second the list is saved. If immediate removal matters, use the controls your deployed configuration actually offers and check for the specific session instead of assuming.

Test that separately from authentication, because the two fail in different places and leave different evidence behind.

Rollback, and the shortcuts to avoid

Rolling back means removing the thumbprint from the revoked list and waiting for the same update to finish. That is safe when you revoked the wrong entry, and it is dangerous when the certificate is genuinely compromised, so decide which case you are in first. Deleting the trusted root is not a shortcut for one lost laptop. Deleting a local VPN profile on one machine does not change what any gateway accepts.

If the identity also authenticates to a second gateway, both need the same treatment. The revoked list belongs to a gateway, not to the subscription.