Always On VPN Users Prompted for Certificate

Always On VPN Users Prompted for CertificateWhen deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) authentication with client certificates, administrators may find the VPN connection does not establish automatically. In this specific scenario the client is prompted to select a certificate to use to authenticate to the VPN server.

Always On VPN Users Prompted for Certificate

Multiple Certificates

This can occur when certificates from multiple Certification Authorities (CAs) are issued to the user that include the Client Authentication Enhanced Key Usage (EKU). When this happens, the user is forced to select the correct certificate to use for VPN authentication.

Clearly this is less than ideal, as it not only breaks the seamless and transparent nature of Always On VPN, the user may select the wrong certificate resulting in authentication failure. Ideally the client should be configured to select the correct certificate without user interaction.

Certificate Selection

Follow the steps below to configure automatic certificate selection for VPN authentication.

  1. On a VPN client, right-click the Always On VPN connection and choose Properties.
  2. Select the Security tab.
  3. In the Authentication section click Properties below Use Extensible Authentication Protocol (EAP).
  4. In the Select Authentication Method section click Configure.
  5. In the When connecting section click Advanced.
  6. Check the box next to Certificate Issuer.
  7. Select the root CA used to issue client authentication certificates for VPN authentication.
  8. Click Ok four times to save the configuration.

Always On VPN Users Prompted for Certificate

Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.

Certificate Purpose

By default, a client certificate requires only the Client Authentication EKU to establish a VPN connection. In some cases, this may not be desirable. For example, consider a deployment where Client Authentication certificates are issued to all users for Wi-Fi authentication. Depending on the Network Policy Server (NPS) configuration, these certificates may also be used to authenticate to the VPN.

VPN Specific Certificate

Follow the steps below to create a user authentication certificate template to be used exclusively for VPN authentication.

Certificate Template

  1. On the CA server, open the Certificate Templates management console (certtmpl.msc).
  2. Right-click the certificate template configured for VPN authentication and choose Properties.
  3. Select the Extension tab.
  4. Highlight Application Policies and click Edit.
  5. Click Add.
  6. Click New.
  7. Enter a descriptive name for the new application policy.
  8. Copy the Object identifier for later use and click Ok four times to save the configuration.

    Always On VPN Users Prompted for Certificate

  9. If certificate autoenrollment is configured and the certificate is already provisioned to users, right-click the certificate template and choose Reenroll All Certificate holders.

Client Configuration

  1. On the VPN client, follow the steps outlined previously to configure certificate selection.
  2. In addition to choosing a certificate issuer, select Extended Key Usage (EKU).
  3. Uncheck All Purpose.
  4. Select Client Authentication and the following EKUs.
  5. Click Add.
  6. Click Add once more.
  7. Enter the name of the custom EKU policy created previously.
  8. Enter the custom EKU object identifier copied previously from the custom policy.

    Always On VPN Users Prompted for Certificate

  9. Click Ok twice.
  10. Uncheck AnyPurpose and the following EKUs.
  11. Click Ok four times to save the configuration.

Always On VPN Users Prompted for Certificate

Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.

Additional Information

Windows 10 Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Get-EapConfiguration PowerShell Script on GitHub

Windows 10 Always On VPN Hands-On Training

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Always On VPN Clients Prompted for Authentication when Accessing Internal ResourcesWhen deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.

“The system cannot contact a domain controller to service the authentication request. Please try again later.”

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Resolution

This can occur if one or more domain controllers in the enterprise have expired or missing domain controller authentication certificates. To ensure seamless single sign-on to internal resources, ensure that all domain controllers have a certificate issued by the internal certification authority (CA) that includes the Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), KDC Authentication (1.3.6.1.5.2.3.5), and Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Enhanced Key Usage (EKU). Administrators can duplicate the Kerberos Authentication template for this purpose.

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

 

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or ComputersOnce Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.

Certificate Revocation

When certificates are used for authentication, for example when a device tunnel is deployed, or a user tunnel is configured to use Extensible Authentication Protocol (EAP) with user certificate authentication, immediately revoking issued user and device certificates and publishing a new Certificate Revocation List (CRL) is recommended. However, this will not instantly prevent VPN access because revocation information is cached on the VPN and NPS servers, as well as any online responders. The process of flushing certificate revocation caches is challenging and time consuming as well.

Blocking Users

To immediately prevent users from accessing the VPN, a security group must be created in Active Directory that contains users that will be denied access. In addition, a Network Policy must be created on the Network Policy Server (NPS) that denies access to users belong to this security group.

NPS Configuration

Once the security group has been created, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand Policies.
  2. Right-click Network Policies and choose New.
  3. Enter a descriptive name for the policy in the Policy name field.
  4. Select Remote Access Server (VPN-Dial up) from the Type of network access server drop-down list.
  5. Click Next.
  6. Click Add.
    1. Select User Groups.
    2. Click Add.
    3. Click Add Groups.
    4. Select the security group create for denied users.
    5. Click Ok twice.
  7. Click Next.
  8. Select Access denied.
  9. Click Next four times and click Finish.

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or Computers

Once complete, move the deny access policy so that it is before the policy that allows VPN access.

Denying Access to Always On VPN Users or Computers

Device Tunnel Considerations

Since device tunnel connections don’t use the NPS for authentication, blocking devices from establishing Always On VPN connections requires a different technique. Once again, revoking the computer certificate and publishing a new CRL is recommended, but isn’t immediately effective. To address this challenge, it is recommended that the computer certificate issued to the client be retrieved from the issuing CA and placed in the local computer’s Untrusted Certificates store on each VPN server, as shown here.

Note: The certificate must be imported on each VPN server in the organization.

Terminating Connections

Once the guidance above is put in to place, any user or device that is denied access will be unable to connect to the VPN. However, if a user or device is currently connected when these changes are implemented, additional steps must be taken to proactively terminate their existing session. When using Windows Server Routing and Remote Access Service (RRAS) as the VPN server, uUser sessions can be proactively terminated using RRAS management console or PowerShell.

GUI

To terminate an established Always On VPN connection, open the RRAS management console (rrasmgmt.msc), highlight Remote Access Clients, then right-click the client connection and choose Disconnect. Repeat the process for any additional connections established by the user or device.

Denying Access to Always On VPN Users or Computers

PowerShell

Alternatively, Always On VPN connections can also be terminated programmatically using PowerShell. To identify currently connected users on a VPN server, open an elevated PowerShell command window and run the following command.

Get-RemoteAccessConnectionStatistics | Format-Table -AutoSize

Next, to disconnect a user tunnel, identify the User Principal Name (UPN) of the user to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “[email protected]

To disconnect a device tunnel, identify the Fully-Qualified Domain Name (FQDN) of the device to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “client1.corp.example.net”

Additional Information

Windows 10 Always On VPN Hands-On Training

Always On VPN IKEv2 Features and Limitations

Always On VPN IKEv2 Features and LimitationsThe Internet Key Exchange version 2 (IKEv2) VPN protocol is a popular choice for Windows 10 Always On VPN deployments. IKEv2 is a standards-based IPsec VPN protocol with customizable security parameters that allows administrators to provide the highest level of protection for remote clients. In addition, it provides important interoperability with a variety of VPN devices, including Microsoft Windows Server Routing and Remote Access Service (RRAS) and non-Microsoft platforms such as Cisco, Checkpoint, Palo Alto, and others.

IKEv2 Limitations

IKEv2 is clearly the protocol of choice in terms of security. It supports modern cryptography and is highly resistant to interception. It’s not without some operational challenges, however. Consider the following.

Firewalls

IKEv2 uses UDP ports 500 and 4500 for communication. Unfortunately, these ports are not always open. Often, they are blocked by network administrators to prevent users from bypassing security controls or attackers from exfiltrating data.

Fragmentation

IKEv2 packets can become quite large at times, especially when using client certificate authentication with the Protected Extensible Authentication Protocol (PEAP). This can result in fragmentation occurring at the network layer. Unfortunately, many firewalls and network devices are configured to block IP fragments by default. This can result in failed connection attempts from some locations but not others.

Load Balancing

Load balancing IKEv2 connections is not entirely straightforward. Without special configuration, load balancers can cause intermittent connectivity issues for Always On VPN connections. Guidance for configuring IKEv2 load balancing on the Kemp LoadMaster and the F5 BIG-IP can be found here:

IKEv2 Fragmentation

IKEv2 fragmentation can be enabled to avoid IP fragmentation and restore reliable connectivity. IKEv2 fragmentation is supported in Windows 10 and Windows Server beginning with v1803. Guidance for enabling IKEv2 fragmentation on Windows Server RRAS can be found here. Support for IKEv2 fragmentation on non-Microsoft firewall/VPN devices is vendor-specific. Consult with your device manufacturer for more information.

IKEv2 Security and RRAS

Be advised that the default security settings for IKEv2 on Windows Server RRAS are very poor. The minimum recommended security settings and guidelines for implementing them can be found here.

IKEv2 or TLS?

IKEv2 is recommend for deployments where the highest level of security and protection is required for remote connections. In these scenarios, the sacrifice of ubiquitous availability in favor of ultimate security might be desired.

SSTP or another TLS-based VPN protocol is recommended if reliable operation and connectivity are desired. SSTP and TLS VPNs can be configured to provide very good security by following the security and implementation guidelines found here.

IKEv2 with TLS Fallback

In theory, preferring IKEv2 and falling back to the Secure Socket Tunneling Protocol (SSTP) or another TLS-based VPN protocol when IKEv2 is unavailable would seem like a logical choice. This would ensure the highest level of protection, while still providing reliable connectivity. Unfortunately, the Windows VPN client doesn’t work this way in practice. Details here.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN SSTP Load Balancing and SSL Offload

SSL Certificate Considerations for DirectAccess IP-HTTPSThe Windows Server Routing and Remote Access Service (RRAS) is a popular choice for a VPN server to support Windows 10 Always On VPN deployments. One significant advantage RRAS provides is support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to ensure privacy between the VPN client and server. The advantage to using a TLS-based transport is that it leverages the standard HTTPS TCP port 443, making it firewall friendly and ensuring ubiquitous remote access even behind highly restrictive firewalls.

Load Balancing SSTP

Load balancing SSTP can be accomplished in much the same way as a load balancing a common web server using HTTPS. The external load balancer is configured with a virtual IP address (VIP) and each VPN server is configured behind it. Session persistence should be configured to use SSL with source IP address persistence as a fallback.

SSL Offload for SSTP

In most cases, simply forwarding encrypted SSTP connections to the VPN server will be sufficient. However, offloading SSL/TLS processing to an Application Delivery Controller (ADC) or load balancer can be beneficial for the following reasons.

Resource Utilization

Enabling TLS offload for SSTP VPN connections can reduce CPU and memory utilization on the VPN server. However, this will likely only be necessary for very busy servers supporting many concurrent connections.

Security

In some cases, the administrator may not be able to install the public SSL certificate on the VPN server. For example, a security policy may exist that restricts SSL certificate installation to dedicated security devices using a Hardware Security Module (HSM). In some cases, it may be desirable to restrict access to high value certificates such as wildcard certificates.

Certificate Management

Often SSL certificates are implemented on load balancers to reduce certificate sprawl and to ease the management and administration burden in the enterprise. By having all enterprise certificates installed only on dedicated security devices, administrators can more effectively monitor and manage SSL certificate lifecycles.

SSTP Configuration for TLS Offload

Configuration changes must be made on the load balancer and the RRAS server to support TLS offload for SSTP.

Load Balancer

Install the public SSL certificate on the load balancer and configure it for TLS termination. Configure the load balancer to then use HTTP for backend server connections. Consult the load balancer vendor’s documentation for configuration guidance.

Load Balancing Always On VPN SSTP Load Balancing with F5 BIG-IP

RRAS Server

If the public SSL certificate is installed on the VPN server, enabling TLS offload for SSTP is simple and straightforward. Follow the steps below to enable TLS offload for SSTP VPN connections.

  1. Open the RRAS management console (rrasmgmt.msc).
  2. Right-click the VPN server and choose Properties.
  3. Select the Security tab.
  4. Check Use HTTP in the SSL Certificate Binding section.
  5. Click Ok and then Yes to restart the Remote Access service.

Always On VPN SSTP Load Balancing and SSL Offload

If the public SSL certificate is not or cannot be installed on the RRAS server, additional configuration will be required. Specifically, SSL offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be downloaded here.

Once the script has been downloaded and imported, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the load balancer and the VPN server will be sent in the clear using HTTP. In some scenarios, TLS offload is required only for traffic inspection, not performance gain. When terminating TLS on the load balancer and re-encrypting connections to the VPN server is required, it is only supported if the same certificate is used on both the load balancer and the VPN server.

Additional Information

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN SSL Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN Hands-On Training Classes for 2019

 

Always On VPN and IKEv2 Fragmentation

The IKEv2 protocol is a popular choice when designing an Always On VPN solution. When configured correctly it provides the best security compared to other protocols. The protocol is not without some unique challenges, however. IKEv2 is often blocked by firewalls, which can prevent connectivity. Another lesser know issue with IKEv2 is that of fragmentation. This can result in failed connectivity that can be difficult to troubleshoot.

IP Fragmentation

IKEv2 uses UDP for transport, and typically most packets are relatively small. The exception to this is when authentication takes place, especially when using client certificate authentication. The problem is further complicated by long certificate chains and by RSA keys, especially those that are greater than 2048 bit. If the payload exceeds 1500 bytes, the IP packet will have to be broken in to smaller fragments to be sent over the network. If an intermediary device in the path is configured to use a smaller Maximum Transmission Unit (MTU), that device may fragment the IP packets.

IP Fragmentation and Firewalls

Many routers and firewalls are configured to drop IP fragments by default. When this happens, IKEv2 communication may begin initially, but subsequently fail. This typically results in an error code 809 with a message stating the following.

“Can’t connect to [connection name]. The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.”

Always On VPN and IKEv2 Fragmentation

Troubleshooting

When troubleshooting potential IKEv2 fragmentation-related connection failures, a network trace should be taken of the connection attempt on the client. Observe the packet sizes during the conversation, especially IKE_AUTH packets. Packet sizes exceeding the path MTU will have to be fragmented, as shown here.

Always On VPN and IKEv2 Fragmentation

Measuring Path MTU

Measuring the path MTU between the client and server can be helpful when troubleshooting fragmentation related issues. The mtupath.exe utility is an excellent and easy to use tool for this task. The tool can be downloaded here.

Always On VPN and IKEv2 Fragmentation

IKEv2 Fragmentation

To address the challenges with IP fragmentation and potential connectivity issues associated with network devices dropping fragmented packets, the IKEv2 protocol itself can be configured to perform fragmentation at the IKE layer. This eliminates the need for IP layer fragmentation, resulting in better reliability for IKEv2 VPN connections.

Both the server and the client must support IKEv2 fragmentation for this to occur. Many firewall and VPN vendors include support for IKEv2 fragmentation. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, the feature was first introduced in Windows Server 1803 and is supported in Windows Server 2019. Windows 10 clients support IKEv2 fragmentation beginning with Windows 10 1803.

Enabling IKEv2 Fragmentation

Windows 10 clients support IKEv2 fragmentation by default. However, it must be enabled on the server via the registry. The following PowerShell command will enable IKEv2 fragmentation support on Windows Server 1803 and later.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

A PowerShell script to implement IKEv2 fragmentation can be found on my GitHub here.

Validation Testing

Once IKEv2 fragmentation is configured on the VPN server, a network capture will reveal the IKE_SA_INIT packet now includes the IKEV2_FRAGMENTATION_SUPPORTED notification message.

Always On VPN and IKEv2 Fragmentation

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

RFC 7383 – IKEv2 Message Fragmentation

IEA Software MTU Path Scan Utility

Windows 10 Always On VPN Hands-On Training Classes

Troubleshooting Always On VPN Error Code 0x80092013

Troubleshooting Always On VPN Error Code 0x80092013Windows Server Routing and Remote Access Service (RRAS) is commonly used for Windows 10 Always On VPN deployments because it is easy to configure and manage and it includes Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP). SSTP is a Transport Layer Security (TLS) VPN protocol that is firewall-friendly and ubiquitously available. However, a common configuration mistake can lead to failed connections.

Error 0x80092013

A Windows 10 Always On VPN client may fail to establish a VPN connection to an RRAS VPN server when using SSTP. The VPN client will return the following error message.

“Can’t connect to Always On VPN. The revocation function was unable to check revocation because the revocation server was offline.”

Troubleshooting Always On VPN Error Code 0x80092013

The event log will also include RasClient event ID 20227 with the following error.

“The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is -2146885613.”

Troubleshooting Always On VPN Error Code 0x80092013

The Win32 error code –2146885613 converts to hexadecimal 0x80092013, which translates to CRYPT_E_REVOCATION_OFFLINE, indicating that the client was unable to successfully perform a check of the VPN server’s SSL certificate.

Revocation Checking

When the VPN client attempts to establish an SSTP connection to the Windows RRAS VPN, it will check the Certification Revocation List (CRL) using the information provided in the SSL certificate. If the CRL is unreachable for any reason, the client will not complete the connection

Common Cause of Error 0x80092013

Certificate revocation failures for Windows 10 Always On VPN SSTP connections commonly occur when the RRAS VPN server is configured with an SSL certificate issued by an internal certification authority (CA) and the CRL is not publicly available.

Resolving Error 0x80092013

Making the internal CA’s CRL available publicly will of course resolve this error. However, best practice recommendations for the SSTP SSL certificate call for the use of a certificate issued by a public CA. For detailed information about SSL certificate requirements and recommendations, please see Always On VPN SSL Certificate Requirements for SSTP.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN Protocol Recommendations for Windows RRAS

Always On VPN ECDSA SSL Certificate Request for SSTP

As I’ve discussed previously, it is strongly recommended that the TLS certificate used for SSTP be signed using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA provides better security and performance compared to RSA certificates for Windows 10 Always On VPN connections using SSTP. See my previous post Always On VPN SSL Certificate Requirements for SSTP for more information.

Certificate Signing Request

To generate a Certificate Signing Request (CSR) using ECDSA to send to a public Certification Authority (CA) using Windows, open the local computer certificate store (certlm.msc) on any Windows server or client and follow the steps below.

Note: Guidance for creating a CSR with ECDSA using OpenSSL can be found at the end of this post.

  1. Expand Certificates – Local Computer.
  2. Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
  3. Click Next.
  4. Select Proceed without enrollment policy.
  5. Click Next.
  6. From the Template drop-down list choose (No template) CNG key.
  7. Click Next.
  8. Click Details.Always On VPN ECDSA SSL Certificate Request for SSTP
  9. Click Properties.
  10. On the General tab enter a name in the Friendly name field.
  11. Click on the Subject tab.
    1. In the Subject name section, from the Type drop-down list choose Common name.
    2. In the Value field enter the VPN server’s public hostname and click Add.
    3. In the Alternative name section, from the Type drop-down list choose DNS.
    4. In the Value field enter the VPN server’s public hostname and click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  12. Click on the Extensions tab.
    1. Expand Extended Key Usage (application policies).
    2. Highlight Server Authentication.
    3. Click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  13. Click on the Private Key tab.
    1. Expand Cryptographic Service Provider.
    2. Uncheck RSA,Microsoft Software Key Storage Provider.
    3. Check ECDSA_P256,Microsoft Software Key Storage Provider.Always On VPN ECDSA SSL Certificate Request for SSTP
  14. Expand Key options.
    1. Select the option to Make private key exportable.Always On VPN ECDSA SSL Certificate Request for SSTP
  15. Click Ok.
  16. Click Next.
  17. Enter a name for the file in the File Name field.
  18. Click Finish.

Certreq

Installing the TLS certificate for Always On VPN SSTP on a Windows Server Core server will require using certreq.exe. First, using notepad.exe, create a certificate request configuration file that includes the following information. Save it with a .INF file extension.

[NewRequest]
Subject = “CN=vpn.example.net”
FriendlyName = vpn.example.net
KeyAlgorithm = ECDSA_P256
KeyLength = 256
MachineKeySet = True
Exportable = TRUE

[Extensions]
2.5.29.17 = “{text}”
_continue_ = “dns=vpn.example.net&”

Next, create the CSR file by opening an elevated command window and running the following command.

certreq.exe -new .\newcert.inf .\newcert.csr

OpenSSL

If the TLS certificate for Always On VPN SSTP will be installed on a load balancer or other security device, creating the CSR using OpenSSL may be required. Use the following commands to generate a CSR with ECDA using OpenSSL.

openssl ecparam -out aovpn_sstp.key -name prime256v1 -genkey
openssl req -new -key aovpn_sstp.key -out aovpn_sstp.csr -sha256

Submit the Request

Once complete, submit the CSR for signing to your favorite public CA. Based on my experience, some CAs are easier to obtain ECDSA-signed certificates than others. Today, Digicert seems to be one of the better public CAs for obtaining EC TLS certificates.

Complete the Request

Once the CA has issued the certificate, import the certificate into the local computer certificate store on the same client or server where the original CSR was created. The certificate can then be exported and imported on additional VPN servers if required.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Protocol Recommendations for RRAS

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

Always On VPN Certificate Requirements for IKEv2

Always On VPN Certificate Requirements for IKEv2Internet Key Exchange version 2 (IKEv2) is one of the VPN protocols supported for Windows 10 Always On VPN deployments. When the VPN server is Windows Server 2016 with the Routing and Remote Access Service (RRAS) role configured, a computer certificate must first be installed on the server to support IKEv2. There are some unique requirements for this certificate, specifically regarding the subject name and Enhanced Key Usage (EKU) configuration. In addition, some deployment scenarios may require a certificate to be provisioned to the client to support IKEv2 VPN connections.

Server Certificate

The IKEv2 certificate on the VPN server must be issued by the organization’s internal private certification authority (CA). It must be installed in the Local Computer/Personal certificate store on the VPN server. The subject name on the certificate must match the public hostname used by VPN clients to connect to the server, not the server’s hostname. For example, if the VPN server’s hostname is VPN1 and the public FQDN is vpn.example.net, the subject field of the certificate must include vpn.example.net, as shown here.

Always On VPN Certificate Requirements for IKEv2

In addition, the certificate must include the Server Authentication EKU (1.3.6.1.5.5.7.3.1and the IP security IKE intermediate EKU (1.3.6.1.5.5.8.2.2).

Always On VPN Certificate Requirements for IKEv2

Client Certificate

Client certificate requirements vary depending on the type of VPN tunnel and authentication method being used.

User Tunnel

No certificates are required on the client to support IKEv2 when using MSCHAPv2, EAP-MSCHAPv2, or Protected EAP (PEAP) with MSCHAPv2. However, if the option to verify the server’s identity by validating the certificate is selected when using PEAP, the client must have the certificates for the root CA and any subordinate CAs installed in its Trusted Root Certification and Intermediate Certificate Authorities certificate stores, respectively.

Always On VPN Certificate Requirements for IKEv2

User Tunnel with Certificate Authentication

Using certificate authentication for the user tunnel is the recommended best practice for Always On VPN deployments. A client certificate must be installed in the Current User/Personal store to support PEAP authentication with smart card or certificate authentication. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

Device Tunnel

A computer certificate must be installed in the Local Computer/Personal certificate store to support IKEv2 machine certificate authentication and the Always On VPN device tunnel. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

More information about configuring the Always On VPN device tunnel can be found here.

Additional Information

Always On VPN with Trusted Platform Module (TPM) Certificates

Always On VPN Protocol Recommendations for Windows Server 2016 RRAS

Always On VPN and Windows Server RRAS

Always On VPN Training

%d bloggers like this: