Secure Socket Tunneling Protocol (SSTP) remains a popular choice for VPN tunneling on Windows platforms thanks to its integration with Secure Sockets Layer (SSL)/TLS and strong compatibility with corporate firewalls. However, the security posture of an SSTP deployment depends heavily on how you manage certificates and their revocation. A poorly configured Certificate Revocation List (CRL) can leave endpoints trusting compromised or revoked certificates, undermining the entire VPN. This article dives into practical, technical best practices for CRL configuration tailored to SSTP VPNs, aimed at sysadmins, developers, and security teams responsible for deploying and operating enterprise VPNs.

Why CRL matters for SSTP

SSTP uses TLS for the initial SSL handshake. During that handshake, the server presents its certificate and clients must verify that certificate’s validity. Beyond checking the certificate chain and expiration, a critical step is verifying that none of the certificates in the chain have been revoked. Revocation typically occurs when a private key is compromised, a certificate is misissued, or an employee leaves an organization.

Two primary revocation mechanisms exist: CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol). SSTP clients and servers commonly rely on CRL because it is widely supported and can be deployed internally without an OCSP infrastructure. However, CRLs bring operational challenges—distribution, freshness, scalability, and availability—that must be addressed carefully.

CRL basics you must get right

  • CRL Distribution Points (CDP): Ensure every issued certificate contains a correct CDP extension pointing to a reachable HTTP(S) URL (or LDAP if needed) where the CRL is published. SSTP/TLS clients expect CDPs to be reachable during verification.
  • CRL frequency: Set CRL issuance frequency based on risk. Shorter validity (hours to days) reduces exposure but increases load; longer validity (weeks) reduces operational overhead but increases risk. For VPN server certificates, a common compromise is 24–72 hours for high-security environments.
  • NextUpdate handling: Clients use the CRL’s NextUpdate field to determine freshness. Make sure CRLs are updated before NextUpdate expires to avoid clients treating CRLs as stale.
  • Delta CRLs: Use delta CRLs where supported to reduce bandwidth and processing. A base CRL with periodic deltas lets clients fetch smaller updates that contain only changed serial numbers.

Publishing CRLs for SSTP: Availability and Performance

For enterprise SSTP deployments, CRL availability is as important as correctness. If clients cannot access the CRL during TLS validation, they may either fail open (trust anyway) or fail closed (deny connection) depending on client policy. Both outcomes have trade-offs.

Designing a resilient CRL distribution architecture

  • Use highly available web endpoints: Publish CRLs over HTTPS using redundant web servers, load balancers, or CDN-backed endpoints. HTTPS ensures integrity and authenticity of the CRL fetch.
  • Geographic distribution: Deploy CRL endpoints in multiple regions to reduce latency for remote clients and to handle regional outages.
  • Leverage caching carefully: Edge caches and CDNs can accelerate CRL delivery, but ensure cache TTL respects CRL validity windows. Use conservative cache-control headers aligned with CRL NextUpdate.
  • Firewall rules: Open outbound HTTPS (or HTTP if unavoidable) from clients to CRL endpoints and ensure SSTP servers can reach CRL servers during certificate verification.

Integration specifics: Windows SSTP (RRAS/IIS) and CRL checks

Most SSTP deployments rely on Windows Server RRAS or IIS to terminate SSTP sessions. Windows uses the CryptoAPI/Schannel stack for certificate validation, and CRL checking behavior can be influenced by Group Policy and local certificate store settings.

Group Policy and registry controls

  • Group Policy: Policies such as “Check for server certificate revocation” can be enforced on clients via Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings. Ensure this is enabled for stricter revocation checks.
  • Schannel settings: Schannel behavior (e.g., allowing connections when CRL is unreachable) can be impacted by HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL registry keys and WinHTTP/WinINET settings. Modify these only with careful testing.
  • Certificate Chain Buildup: Ensure all intermediate CA certificates are present in the server’s certificate store so chain validation and CRL lookup succeed without hitting external endpoints unnecessarily.

Automating CRL publication on Windows CA

If you run Microsoft CA, automate CRL publishing via the CA’s CRL Publication Point. Common steps include:

  • Set CDP and AIA locations in CA properties to internal HTTPS/HTTP paths; include both internal and external URLs if clients are off-network.
  • Use scheduled tasks or CA auto-publish settings to generate and copy CRLs to web servers. Typical commands: certutil -CRL to force generation, and use robocopy or PowerShell to copy files to the WWW root.
  • Manage delta CRLs by enabling delta publishing and setting appropriate lifetimes (e.g., base CRL validity 7 days, delta validity 1 day).

Linux and cross-platform considerations

Although SSTP is native to Windows, Linux servers (e.g., using sstpd or stunnel-based gateway) and cross-platform clients must also perform CRL checks. Use OpenSSL and related tooling to manage and verify CRLs.

OpenSSL-based CRL management

  • Generate CRLs with OpenSSL CA commands and include proper CRL Distribution Points in the certificate config (using v3 extensions crlDistributionPoints).
  • Host CRLs on HTTPS endpoints. Configure clients to use the -crl_check option or equivalent API calls to enforce CRL checks in OpenSSL-based stacks.
  • Use scriptable automation to publish CRLs and rotate CRL signing keys when needed. Keep CRL files named clearly (e.g., ca.crl, ca-delta.crl) and update webserver symlinks atomically to avoid inconsistent reads.

Key management and CRL signing

A CRL must be signed by the CA private key (or a dedicated CRL signing key). Protecting this key is critical.

  • Store CA keys in HSMs or TPMs where possible to limit exposure.
  • Use a dedicated CRL signing certificate or a subordinate CA for CRL issuance if operational separation is required.
  • Rotate CRL signing keys on a defined schedule and plan for overlapping validity (new CRL signed by new key while old CRL remains valid) to avoid verification failures.

Operational practices and monitoring

CRL configuration is not a one-time task; it needs operational monitoring and testing.

Key monitoring items

  • CRL freshness: Monitor NextUpdate and trigger alerts if a CRL is not regenerated on schedule.
  • Endpoint reachability: Probe CRL URLs from representative client networks (internal, remote, mobile) to detect DNS/firewall issues.
  • Revocation verification tests: Periodically revoke a test certificate and validate that clients correctly block connections to a server presenting that certificate.
  • Log and audit: Enable logging on web servers delivering CRLs and on SSTP servers to record CRL fetch failures and certificate verification errors.

Troubleshooting common CRL issues with SSTP

When SSTP connections fail due to revocation checks, common culprits include unreachable CRL URLs, expired CRLs, incorrect CDP settings, or client policy blocking CRL fetching.

Diagnostic checklist

  • From the client/network side, attempt to download the CRL URL in a browser or via curl/wget and check HTTP response codes and TLS issues.
  • Confirm the certificate’s CDP and AIA fields via certutil or openssl x509 -text and ensure they match published CRL locations.
  • On Windows clients, inspect Event Viewer under System and Applications for Schannel and CryptoAPI errors that hint at revocation problems.
  • Check webserver access logs for 4xx/5xx responses and for client IPs blocked by firewall rules.

Advanced: Combining OCSP and CRL for resilience

Where possible, consider supplementing CRLs with OCSP. OCSP provides near-real-time revocation checks and reduces the need for frequent CRL regeneration. Use OCSP stapling on SSTP servers (if supported by your stack) so the server presents a fresh OCSP response during the TLS handshake, avoiding client-side network dependencies.

  • Publish OCSP responder locations in the certificate’s AIA extension.
  • Implement OCSP responders with redundancy and low-latency endpoints.
  • Fallback to CRL if OCSP is unavailable and your policy allows; otherwise enforce fail-closed policies where security is paramount.

Checklist: Minimum must-haves before production roll-out

  • All server certificates contain accurate CDP/AIA entries pointing to highly available HTTPS endpoints.
  • CRL generation is automated with schedules that ensure CRLs are always valid and published before NextUpdate.
  • Monitoring and alerting for CRL freshness and endpoint reachability are in place.
  • Client Group Policy enforces certificate revocation checking and is tested across representative devices.
  • CRL signing keys are protected and rotated per policy, with overlapping validity planning to avoid downtime.

Proper CRL configuration is an often-overlooked but critical component of secure SSTP VPN deployments. By designing for availability, automating publishing, protecting signing keys, and monitoring operational health, you can reduce attack surface and ensure revoked credentials are not accepted by clients. These measures, combined with complementary technologies such as OCSP and strong certificate lifecycle management, significantly improve the resilience and trustworthiness of SSTP-based remote access.

For more practical VPN deployment guides and configuration checklists, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.