Introduction

SSTP (Secure Socket Tunneling Protocol) is a VPN transport that tunnels PPP traffic over an SSL/TLS channel. Originally developed by Microsoft, SSTP is widely used because it traverses firewalls and proxies using TCP port 443. While SSTP commonly relies on username/password and MS-CHAPv2 or EAP, using certificate-based authentication (EAP-TLS) dramatically improves security by eliminating shared secrets and enabling mutual authentication. This guide walks through the technical details and practical steps to deploy a secure SSTP VPN with certificate-based authentication suitable for site operators, enterprise administrators, and developers.

Why Choose Certificate-Based Authentication for SSTP?

Certificate-based authentication provides several security and operational advantages over password-based approaches:

  • Mutual authentication: Both client and server verify each other’s identity, reducing risk of man-in-the-middle attacks.
  • Elimination of shared secrets: No passwords to leak, brute-force, or phish.
  • Granular revocation and lifecycle control: You can revoke individual client certificates via CRL or OCSP without changing server configuration.
  • Better auditability: Certificates include metadata (CN, SAN, serial number) that assists logging and compliance.

High-Level Architecture and Requirements

Before diving into commands and configuration, understand the components involved:

  • Certificate Authority (CA) — internal PKI (OpenSSL, Microsoft CA) or a managed CA to sign server and client certificates.
  • SSTP Server — typically Microsoft RRAS on Windows Server, though other implementations exist (SoftEther, stunnel-based setups).
  • Clients — Windows built-in SSTP client supports EAP-TLS; third-party clients vary.
  • Network — ensure TCP port 443 is routed to the SSTP server and firewall policies allow TLS connections.

Prerequisites

  • Access to a CA to issue certificates (example here uses OpenSSL for a private CA).
  • FQDN for the SSTP server with DNS pointing to the public IP.
  • Windows Server with RRAS role (or alternative SSTP server) with administrative access.
  • Clients capable of EAP-TLS (Windows 10/11 built-in supports it).

PKI Design Considerations

Design your PKI with the following in mind:

  • Separate CA tiers: Use a root CA and one or more issuing CAs. Keep the root offline if possible.
  • Key types: Prefer ECC (P-256) for smaller keys and equivalent security, or RSA 2048/3072 for compatibility.
  • Validity: Use moderate validity (2–5 years) for server certs and shorter lifetimes (1 year) for client certs.
  • Extended Key Usage (EKU) and SAN: Server cert must include serverAuth EKU and a Subject Alternative Name (SAN) matching the FQDN. Client certs need clientAuth EKU.
  • Revocation: Publish CRL distribution points (CDP) and/or enable OCSP to allow the server to check client certificate revocation status.

Generating Certificates with OpenSSL (Example)

The following summarizes the OpenSSL workflow: create a CA, then issue server and client certs. Commands are shown conceptually — adapt paths and parameters for production.

  • Create a private CA key and self-signed cert (root CA).
  • Generate server key and CSR with CN and SAN set to your SSTP FQDN (e.g., vpn.example.com).
  • Sign the server CSR with the CA and include EKU=serverAuth.
  • Create client key and CSR; sign with EKU=clientAuth. Export client certs as PKCS#12 (.p12/.pfx) for Windows import.

Key technical points:

  • Include SAN rather than relying on CN for modern TLS validation.
  • Include CRL Distribution Points in issued certificates so the RRAS can perform revocation checks.
  • Protect private keys with strong passphrases and store CA keys offline.

Installing the Server Certificate on Windows RRAS

On the SSTP server (Windows Server running RRAS):

  • Import the server certificate (PFX) into the Local Machine Personal store. Ensure the private key is present and marked as exportable only if necessary.
  • Ensure the certificate’s subject or SAN matches the FQDN used by clients to connect.
  • Confirm the certificate’s EKU contains Server Authentication (1.3.6.1.5.5.7.3.1).
  • In RRAS MMC or Server Manager, configure the SSTP listener to use the installed certificate. RRAS automatically selects a certificate that matches the FQDN and includes serverAuth, but you can control selection via the certificate property dialog or PowerShell.

PowerShell tip: use the Get-ChildItem Cert:LocalMachineMy to confirm thumbprint and Netsh or RRAS settings if manual binding required.

Configuring RRAS for EAP-TLS (Certificate-Based Client Authentication)

RRAS supports EAP-TLS to authenticate clients with certificates. Steps:

  • Install and configure Network Policy Server (NPS) to act as RADIUS if you want centralized policy management. NPS can validate client certs and apply network policies.
  • Create an NPS Policy with Authentication Methods including EAP — Smart Card or other Certificate (EAP-TLS).
  • Configure the NPS policy to require a client certificate issued by your CA and ensure the CA is trusted by the server (CA chain in Trusted Root/Intermediate stores).
  • On RRAS, point authentication to NPS (if using RADIUS) or configure local policies to accept EAP-TLS directly.

Important: Configure the EAP properties to check certificate properties such as issuer and purpose. You can also map certificate attributes (Subject, SAN, UPN) to user accounts or groups.

Client Setup (Windows)

For Windows clients using EAP-TLS:

  • Import the client certificate (PKCS#12 .pfx) into the Current User or Local Machine personal certificate store. Include the private key and mark it as exportable only if needed.
  • Install the CA certificate chain in the Trusted Root Certification Authorities (for the CA) and Intermediate Certification Authorities (if applicable).
  • Create a new VPN connection (Settings > Network & Internet > VPN). Choose Windows (built-in) and set the VPN type to SSTP (Secure Socket Tunneling Protocol).
  • Under Authentication settings, choose Use machine certificate or configure the VPN connection to use Smart card or other certificate. Select the client certificate in the dialog (if prompted) or let Windows auto-select based on EKU.
  • Ensure “Remember my credentials” is not used — the certificate provides authentication.

When connecting, the client will perform TLS/SSL handshake with server cert verification and present its client certificate for EAP-TLS.

Firewall, NAT, and Load Balancing Considerations

SSTP operates over TCP 443. While this helps with firewall traversal, plan for:

  • Firewall rules: Allow inbound TCP 443 to your SSTP server or load balancer.
  • Load balancer: If using a TCP-level load balancer, ensure it supports SSL passthrough so the server sees the client certificate (EAP-TLS requires SSL end-to-end). Offloading TLS at the load balancer will break client certificate authentication unless you proxy client certificates (rare).
  • NAT traversal: Ensure proper NAT rules preserve source IPs if you rely on IP-based controls or logging.

Hardening TLS and Cipher Suites

To maximize security:

  • Disable TLS 1.0/1.1 and only allow TLS 1.2 and TLS 1.3 where supported.
  • Prefer ECDHE (Ephemeral Elliptic Curve) for forward secrecy. Configure server cipher suites to favor ECDHE suites.
  • Disable weak ciphers and legacy hash algorithms (RC4, DES, MD5). Use tools like Microsoft’s IIS Crypto or manual GPO settings to control cipher suites on Windows.
  • Use strong DH parameters if Diffie-Hellman is used; prefer ECDHE over finite-field DH.

Revocation and Certificate Lifecycle Management

Certificate revocation is critical. Implement at least one of the following:

  • Publish CRLs from your CA and ensure the CRL Distribution Points are reachable by the server and clients. Regularly publish updated CRLs.
  • Deploy OCSP responders for lower latency and real-time revocation checks.
  • Integrate certificate issuance and revocation with automation (scripts, APIs) to ease client certificate lifecycle tasks.

Additionally, implement monitoring and logging for certificate issuance, revocation events, and authentication failures.

Operational Tips and Troubleshooting

Common issues and troubleshooting steps:

  • Certificate mismatch: Ensure the server certificate SAN exactly matches the FQDN used by clients.
  • Private key missing: Windows will not use certificates without an associated private key. Verify the PFX import preserved the private key.
  • EAP-TLS failures: Check NPS logs, Event Viewer (Applications & Services Logs > Microsoft > Windows > IAS), and ensure client cert EKU contains clientAuth.
  • CRL/OCSP failures: Confirm the server can reach CRL/OCSP endpoints; firewall rules often block outbound HTTP/HTTPS.
  • Load balancer issues: If using LB, make sure TLS is passed through. Consider configuring a dedicated SSL passthrough pool for SSTP servers.

Backup and Disaster Recovery

Protect your PKI assets:

  • Back up CA keys and store them securely (hardware security module preferred for production).
  • Have an offline root CA and one or more online issuing CAs; maintain documented procedures for emergency certificate issuance and revocation.
  • Maintain an inventory of issued client certificates and automate renewal reminders for expiring certs.

Conclusion

Implementing SSTP with certificate-based authentication yields a robust, firewall-friendly VPN solution that significantly improves security posture compared to password-based methods. The critical success factors are a well-designed PKI, correct certificate attributes (SAN and EKU), proper RRAS/NPS configuration, revocation infrastructure (CRL/OCSP), and hardened TLS settings. Follow best practices for key protection, certificate lifecycle management, and operational monitoring to maintain a reliable SSTP service.

For further resources and managed options, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.