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), open the local computer certificate store (certlm.msc) on any Windows server or client and follow the steps below.

  1. Expand Certificates – Local Computer.
  2. Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
  3. Click Next.
  4. Click Next.
  5. From the Template drop-down list choose (No template) CNG key.
  6. Click Next.
  7. Click Details.

    Always On VPN ECDSA SSL Certificate Request for SSTP

  8. Click Properties.
  9. On the General tab enter a name in the Friendly name field.
  10. 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

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

  12. Click Ok.
  13. Click Next.
  14. Enter a name for the file in the File Name field.
  15. Click Finish.

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 other. 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 in to 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.1). Optionally, but recommended, the certificate should also include 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.

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

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.

To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.

  1. Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
  2. On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.

Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.

Additional Resources

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

Enabling Secure Remote Administration for the NetMotion Mobility Console

During the initial setup of a NetMotion Mobility gateway server, the administrator must choose to allow either Secure (HTTPS) or Non-secure (HTTP) connections when using the web-based Mobility Console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Configuring HTTPS

Security best practices dictate HTTPS should be enabled to protect credentials used to log on to the gateway remotely. Immediately after selecting the Secure (https:) option, the administrator is prompted to enter server certificate information. Enter this information and click OK to continue and complete the rest of the configuration as necessary.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Self-Signed Certificate

When logging in to the Mobility console, the administrator is presented with a certificate error indicating there is a problem with the website’s security certificate. This is because the certificate is self-signed by the NetMotion Mobility gateway server and is not trusted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

PKI Issued Certificate

The recommended way to resolve this is to request a certificate from a trusted certification authority (CA). To do this, open the Mobility Management Tool on the Mobility gateway server and click on the Web Server tab.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click on the Server Certificate button and then click New in the Certificate Request section.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In the SAN (subject alternative name) field of the Optional Extension section enter the Fully Qualified Domain Name (FQDN) of the server using the syntax dns:fqdn. Include both the FQDN and the single-label hostname (short name) separated by a comma to ensure both names work without issue. For example:

dns:nm1.lab.richardhicks.net,dns:nm1

Enabling Secure Remote Administration for the NetMotion Mobility Console

Before requesting a certificate from a CA, the root and any intermediate CA certificates must first be imported. Click the Import button next to each, as required.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Copy in the Certificate Request section to copy the Certificate Signing Request (CSR) to the clipboard and then save it to a text file. Now submit the CSR to be signed by the CA using the certreq.exe command. Open an elevated command or PowerShell window and enter the following commands.

certreq.exe -attrib “CertificateTemplate:[TemplateName]” -submit [Path_to_CSR_file]

For example:

certreq.exe -attrib “CertificateTemplate:LabWebServer” -submit certreq.txt

Select a CA from the list and click OK, then save the certificate response when prompted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Response and specify the location of the certificate response file saved in the previous step.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Once complete, the newly issued certificate will be in place. Click Close to complete the process.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Yes when prompted to restart the Mobility console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Trusted Certificate

Opening the Mobility Console no longer produces a certificate error message with a certificate installed from a trusted CA.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In addition, if you followed the guidance above and included the single-label hostname in the SAN field, accessing the server using the short name will also work without issue.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Summary

Always select the option to use HTTPS to ensure the highest level of security and protection of credentials when remotely administering a NetMotion Mobility gateway server. For optimal security and to provide the best user experience, use a certificate issued and managed by a trusted CA to prevent certificate errors when opening the Mobility console.

Additional Information

NetMotion Mobility as an Alternative to DirectAccess

NetMotion Mobility Device Tunnel Configuration

Comparing NetMotion Mobility and DirectAccess Part 1 – Security

Comparing NetMotion Mobility and DirectAccess Part 2 – Performance

DirectAccess and NetMotion Mobility Webinar

 

SSL Certificate Considerations for DirectAccess IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPSDirectAccess uses IPv6 exclusively for communication between the client and server. IPv6 transition technologies are used to support DirectAccess communication over the IPv4 public Internet. One of those IPv6 transition technologies, IP-HTTPS, uses HTTP for encapsulation and SSL/TLS for authentication of the DirectAccess server.

SSL Certificates

When configuring DirectAccess, an SSL certificate must be provided for IP-HTTPS. There are three different types of SSL certificates that can be used.

Public SSL Certificate – Using an SSL certificate signed by a public certification authority (CA) is the recommended best practice for configuring DirectAccess IP-HTTPS. This provides the highest level of assurance for DirectAccess clients connecting via IP-HTTPS.

Private SSL Certificate – Using an SSL certificate issued by the organization’s internal CA is an acceptable alternative to using a public SSL certificate in most cases. This can reduce the cost associated with obtaining the certificate, especially for multisite deployments.

Self-Signed Certificate – Using a self-signed certificate is not recommended and should be avoided in most deployment scenarios. A self-signed certificate provides no real assurance for DirectAccess clients. Crucially, using a self-signed certificate will disable support for null SSL and TLS cipher suites. This reduces the overall scalability and performance of the remote access solution.

SSL Certificate Considerations for DirectAccess IP-HTTPS

Figure 1. Null cipher suites not supported when using a self-signed SSL certificate for IP-HTTPS.

Certificate Requirements

The SSL certificate must include the Server Authentication (1.3.6.1.5.5.7.3.1) Enhanced Key Usage (EKU) Object Identifier (OID). It should use an RSA key of 2048 bits and be signed with SHA256. Using stronger keys provides no additional protection and should not be used. In addition, SSL certificates using ECDSA keys is not recommended, as they do not support null cipher suites.

Summary

In most cases, using a public SSL certificate is ideal. However, issuing a certificate from a private CA is also acceptable. Using self-signed certificates can be used for non-production testing and in very small production deployments, but should generally be avoided.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

KEMP LoadMaster Load Balancer Certificate Format Invalid

When implementing a KEMP LoadMaster load balancer, one of the first configuration tasks performed is importing root and intermediate Certification Authority (CA) certificates. When doing this, it is not uncommon to encounter the following error message.

Certificate Format Invalid.

KEMP LoadMaster Load Balancer Certificate Invalid

To resolve this issue, .CER files must first be converted to .PEM format before being imported in to the LoadMaster. Using OpenSSL, .CER files can quickly be converted to .PEM with the following command.

openssl x509 -inform der -in example.cer -out example.pem

Optionally, .CER files can be converted to .PEM online here.

If the root and/or intermediate certificates are from an internal PKI, export the certificates using the Base-64 encoded x.509 (.CER) option. Certificates exported using this format can be imported directly in to the LoadMaster without first having to be converted to .PEM.

KEMP LoadMaster Load Balancer Certificate Format Invalid

Pro tip: When entering the Certificate Name, it is not necessary to enter a file extension. The name will be appended with .PEM automatically upon import.

KEMP LoadMaster Load Balancer Certificate Format Invalid

KEMP LoadMaster Load Balancer Certificate Format Invalid

Additional Resources

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

Maximize Your Investment in Windows 10 with KEMP LoadMaster Load Balancers

DirectAccess and the FREE KEMP LoadMaster Load Balancer

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Planning and Implementing DirectAccess Video Training Course on Pluralsight

Implementing DirectAccess with Windows Server 2016 Book

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6transition technology. When troubleshooting this issue, running ipconfig.exe show that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x800b0109 with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Error code 0x800b0109 translates to CERT_E_UNTRUSTEDROOT, indicating the client was unable to establish an IP-HTTPS connection because the certificate presented during the SSL handshake was issued by a certification authority that was not trusted. This commonly occurs when the DirectAccess server is configured with an SSL certificate issued by the internal PKI and DirectAccess clients are provisioned using offline domain join without using the /rootcacerts switch. This can also happen if DirectAccess is configured to use a self-signed certificate for IP-HTTPS, and the certificate is either renewed or DirectAccess is uninstalled and reinstalled.

Troubleshooting DirectAccess IP-HTTPS Error 0x800b0109

To resolve IP-HTTPS error code 0x800b0109, obtain the root certificate for the certificate authority that issued the SSL certificate used for IP-HTTPS and import it in to the DirectAccess client’s Trusted Root Certification Authorities local computer certificate store. Once complete, restart the IP helper service to reinitiate an IP-HTTPS connection.

Additional Information

Provisioning DirectAccess Clients using Windows Offline Domain Join

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

SSL Certificate Considerations for DirectAccess IP-HTTPS

Implementing DirectAccess with Windows Server 2016

%d bloggers like this: