Setting up an SSTP VPN on Windows with client certificate authentication provides a strong security posture by combining TLS transport and mutual X.509 verification. This guide walks through the full process—from certificate authority (CA) and certificate issuance to installing the client certificate and configuring the Windows VPN client—so administrators, developers, and site operators can deploy a secure SSTP endpoint in minutes.

Why use client certificates with SSTP?

SSTP (Secure Socket Tunneling Protocol) encapsulates VPN traffic over TLS (HTTPS). By default, SSTP uses server-side certificates for encryption. Adding client certificate authentication enforces mutual TLS (mTLS), which helps prevent credential theft, brute-force logins, and unauthorized client access even if username/password credentials are compromised. For business environments and developer teams, this model enables stronger access control and easier auditability.

Prerequisites and assumptions

  • Windows server or appliance exposing an SSTP endpoint (e.g., RRAS on Windows Server or a compatible VPN gateway).
  • A trusted Certificate Authority (internal Microsoft CA, OpenSSL-based CA, or public CA) to issue both server and client certificates.
  • Administrative access to client Windows machines for certificate installation and VPN configuration.
  • Familiarity with basic PKI concepts (private key, public key, PFX, certificate chain).

High-level flow

  • Create or use an existing CA and issue server and client certificates.
  • Configure the VPN server to require client certificates for authentication.
  • Export client certificate(s) as PFX files (including private key) and install them on client machines.
  • Configure the Windows VPN client to use the installed certificate and SSTP transport.
  • Verify connectivity and troubleshoot common errors.

Generate certificates: two common approaches

Two practical options exist for generating certificates: a Microsoft AD CS (Active Directory Certificate Services) based CA, or a simple OpenSSL CA for smaller deployments or lab environments. Both approaches are described below with essential commands and steps.

Option A — Using Microsoft AD CS

  • On your CA server, create a template for client authentication (User or Computer templates with “Client Authentication” EKU).
  • Enroll a server certificate on the RRAS host: include the public FQDN used by clients to reach the SSTP endpoint and enable Server Authentication EKU.
  • Issue client certificates to users or devices. You can auto-enroll via Group Policy for domain-joined machines or manually request certificates with the Certificates MMC snap-in.
  • Export the client certificate from the issuing machine (or user profile) as a PFX containing the private key. Protect it with a strong password if transferring.

Option B — Using OpenSSL

OpenSSL is flexible for non-domain or lab scenarios. Steps below assume a simple CA is already created.

  • Create a client key and CSR (replace client1 with your identifier): 
    openssl genrsa -out client1.key 2048
openssl req -new -key client1.key -out client1.csr -subj "/CN=client1"
  • Sign the CSR with your CA to create a client certificate (include clientAuth EKU in config): 
    openssl x509 -req -in client1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client1.crt -days 365 -extensions usr_cert -extfile openssl.cnf
  • Bundle into a PFX for import into Windows: 
    openssl pkcs12 -export -out client1.pfx -inkey client1.key -in client1.crt -certfile ca.crt

Install the client certificate on Windows

Once you have a PFX file, follow these steps on the client machine. Administrative rights are normally required to import into the Local Computer store; user-level installations are possible when certificates are bound to specific user accounts.

  • Double-click the PFX file to start the Certificate Import Wizard, or use the Certificates MMC (certmgr.msc for Current User or mmc → Certificates for Local Computer).
  • Select “Place all certificates in the following store” → choose “Personal.” Ensure the private key is marked exportable only if you need to move the certificate later (least privilege recommends non-exportable).
  • Verify the certificate shows under Personal → Certificates and that the certificate contains the private key icon and lists “Client Authentication” (Enhanced Key Usage).

Configure Windows VPN client to use the certificate

Windows’ built-in VPN client supports SSTP and certificate-based authentication. Below are key configuration steps for a VPN connection profile.

  • Open “Network & Internet” → “VPN” → “Add a VPN connection.”
  • Set the VPN provider to “Windows (built-in).” Enter the connection name and the server name or IP address (must match the server cert CN/SAN).
  • For “VPN type” select “Secure Socket Tunneling Protocol (SSTP).”
  • Under “Type of sign-in info” select “Use a certificate.” Windows will pick a certificate from the user or computer store. If multiple certificates are present, you can define the specific certificate by thumbprint later using rasphone.pbk or PowerShell.
  • Save the profile and then click “Advanced options” or edit the connection properties (Network Connections → right-click the connection → Properties) to confirm SSTP and certificate selection under the Security tab.

Selecting a specific certificate programmatically

For mass deployment or device management, you may want to bind a specific certificate by thumbprint instead of relying on the UI. You can edit the phonebook file (rasphone.pbk) or use PowerShell/Netsh to set a certificate thumbprint for the connection.

  • Phonebook approach: locate the .pbk file (typically in %AppData%MicrosoftNetworkConnectionsPbkrasphone.pbk) and edit the entry CertHash to the certificate thumbprint.
  • PowerShell: you can deploy the PFX and then update the rasphone settings via scripts that edit the .pbk or use the Windows VPN client APIs.

Server-side: require and validate client certificates

On the server, ensure your SSTP endpoint is configured to request/require client certificates and to validate issuer chains:

  • RRAS (Windows Server): In Remote Access Management, configure the VPN server properties to require IKEv2/EAP or set authentication to “Smart Card or other certificate” for SSTP. Bind the server certificate in the machine computer store (Personal → Certificates).
  • Ensure the server trusts the issuing CA (install the CA certificate in the Trusted Root Certification Authorities store or Intermediate CA store if applicable).
  • Configure your RRAS policy or NPS (Network Policy Server) policies to accept certificate authentication and map certificate attributes to user/group access if you need fine-grained authorization.

Verification and testing

After configuration, test the connection and validate mutual TLS:

  • Connect from the client using the configured SSTP profile. If successful, you should see the VPN connect without prompting for a username/password (unless you configured dual-factor flows).
  • On the server, check event logs (Applications and Services Logs → Microsoft → Windows → Routing and Remote Access) and NPS logs for certificate validation entries.
  • Use network-level capture tools (Wireshark) to confirm SSTP handshake and that the TLS handshake includes client certificate in Certificate message (look for “Certificate, Client” entries in TLS layer).
  • Verify certificate details on the client (Certificates MMC) and on the server (mmc → Certificates for Local Computer) to ensure chain validation and EKU presence.

Troubleshooting common issues

Below are targeted solutions to frequent roadblocks.

  • Certificate not presented by client: Ensure the private key is present and the certificate is in the Personal store. Check that the certificate has Client Authentication EKU. If multiple certificates exist, explicitly set CertHash in rasphone.pbk.
  • Server rejects client certificate: Confirm the server trusts the issuing CA (CA cert in Trusted Root store) and the certificate chain is intact. Check CRL/OCSP accessibility if you enforce revocation checks.
  • Thumbprint mismatch when deployed via script: Remove spaces from the thumbprint and ensure case-insensitive match. Thumbprint can include hidden Unicode characters if copied from UI—use certutil -store to retrieve raw thumbprint.
  • Connection falls back to password authentication: Verify VPN profile is set to certificate-only sign-in info and that no policy enforces alternative authentication methods.

Security and operational best practices

  • Use long-lived CA protection: Keep your CA offline if possible or use HSMs for CA private key protection.
  • Rotate certificates periodically and enforce short validity for client certs if device compromise risk is high.
  • Protect exported PFX files with strong passwords and deliver them via secure channels (SCCM, Intune, or encrypted file transfer).
  • Log certificate-based connections extensively and integrate with SIEM for anomaly detection (multiple certs used from one identity, unusual geographic access patterns, etc.).
  • Where applicable, combine certificate auth with device posture or endpoint compliance checks to ensure only managed devices connect.

Implementing SSTP with client certificates significantly raises the security baseline for Windows VPN deployments while remaining compatible with native clients. Careful certificate lifecycle management, correct store placement, and server trust configuration are the keys to a smooth rollout. For automated deployments, script the PFX installation and rasphone.pbk updates, and test certificate chains and revocation checks in a staging environment before wide rollout.

Published by Dedicated-IP-VPN — https://dedicated-ip-vpn.com/