All posts tagged CA

Troubleshooting Always On VPN Error 853

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Using Windows Server Network Policy Server (NPS) servers is a common choice for authenticating Microsoft Windows 10 Always On VPN user tunnel connections. The NPS server is joined to the domain and configured with a Network Policy that defines the authentication scheme used by clients for authentication when establishing an Always On VPN connection. Protected Extensible Authentication Protocol (PEAP) using client authentication certificates recommended for most Always On VPN deployment scenarios.

Can’t Connect

Users establishing an Always On VPN user tunnel connection using PEAP and client authentication certificates may encounter a scenario in which a VPN connection attempt fails with the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.”

Error 853

In addition, the Application event log records an event ID 20227 from the RasClient source that includes the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code is 853.”

Missing NTAuth Certificate

Error code 853 is commonly caused by a missing issuing Certification Authority (CA) certificate in the NTAuth store on the NPS server. The NPS server must have the issuing CA certificate included in this store to perform authentication using client certificates. You can see the contents of the NTAuth certificate store by opening an elevated command window on the NPS server and running the following command.

certutil.exe -enterprise -viewstore NTAuth

Install Certificate

To install the issuing CA server’s certificate into the NTAuth store, copy the CA certificate to the NPS server, open an elevated command window, then run the following command.

certutil.exe -enterprise -addstore NTAuth <issuing CA certificate>

Once complete, view the store again, and you’ll see the issuing CA certificate listed in the NTAuth certificate store.

Additional Information

Troubleshooting Always On VPN Error Code 858

Troubleshooting Always On VPN Error Code 864

Always On VPN and Windows Server 2019 NPS Bug

Always On VPN Network Policy Server (NPS) Load Balancing

Microsoft Network Policy Server (NPS) Reason Codes

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

28 Comments

by Richard M. Hicks on January 6, 2020 • Permalink

Posted by Richard M. Hicks on January 6, 2020

https://directaccess.richardhicks.com/2020/01/06/always-on-vpn-device-tunnel-with-azure-vpn-gateway/

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

A Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

8 Comments

by Richard M. Hicks on November 11, 2019 • Permalink

Posted by Richard M. Hicks on November 11, 2019

https://directaccess.richardhicks.com/2019/11/11/microsoft-intune-ndes-connector-setup-wizard-ended-prematurely/

Always On VPN Device Tunnel and Certificate Revocation

Recently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Updates for Windows Server

Microsoft has released fixes to support device tunnel certificate revocation for the following operating systems.

Windows Server 2019 – KB4505658 (build 17763.652)

Windows Server 2016 – KB4503294 (build 14393.3053)

Windows Server 2012/R2 – Will not be updated.

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

34 Comments

by Richard M. Hicks on June 20, 2019 • Permalink

Posted by Richard M. Hicks on June 20, 2019

https://directaccess.richardhicks.com/2019/06/20/always-on-vpn-device-tunnel-and-certificate-revocation/

Always On VPN Users Prompted for Certificate

When 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.

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.

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

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

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

On the VPN client, follow the steps outlined previously to configure certificate selection.
In addition to choosing a certificate issuer, select Extended Key Usage (EKU).
Uncheck All Purpose.
Select Client Authentication and the following EKUs.
Click Add.
Click Add once more.
Enter the name of the custom EKU policy created previously.
Enter the custom EKU object identifier copied previously from the custom policy.
Click Ok twice.
Uncheck AnyPurpose and the following EKUs.
Click Ok four times to save the configuration.

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

16 Comments

by Richard M. Hicks on May 28, 2019 • Permalink

Posted in Always On VPN, AOVPN, authentication, certificates, enterprise mobility, GitHub, Mobility, ProfileXML, public key infrastructure, Remote Access, Security, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, XML

Posted by Richard M. Hicks on May 28, 2019

https://directaccess.richardhicks.com/2019/05/28/always-on-vpn-users-prompted-for-certificate/

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

When 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.”

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.

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

25 Comments

by Richard M. Hicks on May 20, 2019 • Permalink

Posted in Always On VPN, AOVPN, authentication, certificates, Encryption, Enterprise, enterprise mobility, Mobility, Remote Access, routing and remote access service, RRAS, Security, troubleshooting, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019

Posted by Richard M. Hicks on May 20, 2019

https://directaccess.richardhicks.com/2019/05/20/always-on-vpn-clients-prompted-for-authentication-when-accessing-internal-resources/

Troubleshooting Always On VPN Error Code 0x80092013

Windows 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.”

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.”

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

2 Comments

by Richard M. Hicks on August 27, 2018 • Permalink

Tagged Always On VPN, AOVPN, CA, certificate, certificates, error, Mobility, PKI, RAS, RasClient, Remote Access, revocation, RRAS, security, SSTP, troubleshooting, VPN

Posted by Richard M. Hicks on August 27, 2018

https://directaccess.richardhicks.com/2018/08/27/troubleshooting-always-on-vpn-error-code-0x80092013/

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.

Expand Certificates – Local Computer.
Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
Click Next.
Select Proceed without enrollment policy.
Click Next.
From the Template drop-down list choose (No template) CNG key.
Click Next.
Click Details.
Click Properties.
On the General tab enter a name in the Friendly name field.
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.
Click on the Extensions tab.
1. Expand Extended Key Usage (application policies).
2. Highlight Server Authentication.
3. Click Add.
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.
Expand Key options.
1. Select the option to Make private key exportable.
Click Ok.
Click Next.
Enter a name for the file in the File Name field.
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

17 Comments

by Richard M. Hicks on August 20, 2018 • Permalink

Posted in Always On VPN, AOVPN, certificates, ECC, Elliptic Curve Cryptography, Encryption, enterprise mobility, Mobility, Remote Access, Security, SSL, SSL and TLS, TLS, Windows 10, Windows Server 2012 R2, Windows Server 2016

Tagged Always On VPN, AOVPN, CA, certificate, CNG, cryptography, CSR, EC, ECDSA, elliptic curve cryptography. cryptography, enterprise mobility, Mobility, Remote Access, security, SSL, SSTP, TLS, VPN, Windows, Windows 10

Posted by Richard M. Hicks on August 20, 2018

https://directaccess.richardhicks.com/2018/08/20/always-on-vpn-ecdsa-ssl-certificate-request-for-sstp/

Always On VPN SSL Certificate Requirements for SSTP

The 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.

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.

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.

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

34 Comments

by Richard M. Hicks on July 16, 2018 • Permalink

Posted by Richard M. Hicks on July 16, 2018

https://directaccess.richardhicks.com/2018/07/16/always-on-vpn-ssl-certificate-requirements-for-sstp/

Always On VPN Certificate Requirements for IKEv2

Internet 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.

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).

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.

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).

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).

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

165 Comments

by Richard M. Hicks on April 30, 2018 • Permalink

Posted in Always On VPN, AOVPN, certificates, enterprise mobility, Mobility, PKI, public key infrastructure, Remote Access, Security, Windows 10, Windows Server 2016

Posted by Richard M. Hicks on April 30, 2018

https://directaccess.richardhicks.com/2018/04/30/always-on-vpn-certificate-requirements-for-ikev2/

Search for:
DirectAccess Book
NetMotion Mobility

DirectAccess-like Remote Access for Windows, Mac, iPhone, iPad, and Android

Learn More!
Recent Posts
Always On VPN Resources
DirectAccess Resources

Awards

Consulting

Connect

Mailing List

RSS Feed

Archives

Categories

Tag Cloud

All posts tagged CA

Can’t Connect

Error 853

Missing NTAuth Certificate

Install Certificate

Additional Information

Share this:

Like this:

Limitations

Root CA Certificate

Export Certificate – GUI

Export Certificate – Command Line

Copy Public Key

Point-to-Site Configuration

VPN Client Configuration

Download VPN Configuration

Create a Test VPN Connection

Create an Always On VPN Connection

IKEv2 Security Configuration

Additional Information

Share this:

Like this:

Setup Wizard Ended Prematurely

Cryptographic Service Provider

Additional Information

Share this:

Like this:

Revocation Check Failure

Updates for Windows Server

Enable Revocation Check

Revoking Certificates

Additional Information

Share this:

Like this:

Multiple Certificates

Certificate Selection

Certificate Purpose

VPN Specific Certificate

Certificate Template

Client Configuration

Additional Information

Share this:

Like this:

Resolution

Additional Information

Share this:

Like this:

Error 0x80092013

Revocation Checking

Common Cause of Error 0x80092013

Resolving Error 0x80092013

Additional Information

Share this:

Like this:

Certificate Signing Request

Certreq

OpenSSL

Submit the Request

Complete the Request

Additional Information

Share this:

Like this:

SSTP Certificate

Certification Authority

Key Type

Forward Secrecy

Authenticated Encryption

SSL Offload

Summary

Additional Information

Share this:

Like this: