Troubleshooting DirectAccess: Fixing IP-HTTPS Connection Issues in Windows Clients

Table of Contents

DirectAccess is a powerful feature that provides seamless connectivity for remote users to internal network resources. However, clients may sometimes encounter difficulties connecting to the DirectAccess Server, particularly when utilizing Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) connections. This article delves into common issues preventing these crucial connections, primarily focusing on certificate revocation check failures, and provides detailed resolution steps to restore full functionality.

Understanding IP-HTTPS Connectivity Challenges¶

IP-HTTPS serves as a robust fallback mechanism when other DirectAccess connectivity methods, such as Teredo or 6to4, are unavailable. It establishes a secure connection over TCP port 443 (SSL/TLS), making it highly resilient to network restrictions often encountered in public Wi-Fi environments. Despite its robustness, IP-HTTPS connections can fail if critical certificate validation steps, specifically the certificate revocation check, are not successfully completed. This failure prevents the secure tunnel from being established, leaving clients unable to access internal resources.

Symptoms of IP-HTTPS Revocation Failures¶

The primary symptom indicating a certificate revocation issue in DirectAccess IP-HTTPS connections is a specific error message. When clients attempt to establish connectivity, the netsh interface http show interface command will reveal an error code that directly points to a revocation problem. This error is a clear indicator that the system cannot verify the validity of the certificates involved in the IP-HTTPS tunnel.

The output from the command will typically display:

Error: 0x80092013

Translates to: CRYPT_E_REVOCATION_OFFLINE

This error message explicitly states that the revocation server, which hosts the Certificate Revocation List (CRL), was inaccessible or offline during the certificate validation process. Consequently, the DirectAccess client is unable to confirm that the server’s certificate has not been revoked, leading to the connection failure. Understanding this specific error is the first step towards effective troubleshooting.

Root Causes of Revocation Check Failures¶

Certificate revocation check failures stem from several underlying issues, all of which prevent the DirectAccess client from successfully validating the authenticity and current status of the certificates used for IP-HTTPS. Pinpointing the exact cause is crucial for applying the correct resolution. These causes primarily revolve around the accessibility and validity of the Certificate Revocation List (CRL).

The common reasons for encountering the CRYPT_E_REVOCATION_OFFLINE error include:

1. CRL Location (CDP) is Unreachable: The client cannot download the CRL file because the distribution point is not accessible from its current network context. This might be due to network blocks, incorrect proxy settings, or the server hosting the CRL being offline.
2. CRL Location (CDP) is Unpublished: The Certificate Authority (CA) has not properly configured or published the CRL Distribution Point (CDP) in the certificates or to an accessible location. Without a published CDP, clients have no pathway to retrieve revocation information.
3. CRL Has Expired: The published CRL has passed its validity period, and a new, updated CRL has not been generated and published by the Certificate Authority. An expired CRL is treated as unavailable, as it cannot provide current revocation status.
4. Client is Picking from an Old Cache: Even if a new and valid CRL is available, the client might be using a stale, cached version of the CRL or certificate chain information. This prevents it from recognizing the updated status and can lead to persistent revocation errors.

Each of these scenarios requires a distinct approach to resolution, ranging from network configuration adjustments to CA management tasks and client-side cache clearing.

Resolution Steps for IP-HTTPS Connection Issues¶

Addressing IP-HTTPS connection issues due to revocation failures requires a systematic approach, tackling each potential cause with specific actions. The following sections provide detailed resolution steps tailored to each of the identified root causes. Careful execution of these steps will help restore DirectAccess connectivity for your Windows clients.

Resolving Unreachable CRL Location (CDP)¶

When the Certificate Revocation List (CRL) distribution point (CDP) cannot be reached, clients are unable to perform the necessary revocation checks. This issue often stems from network configuration problems, particularly involving proxy settings or accessibility of the CRL host. It is essential to verify that the CRL is downloadable from the system context, as DirectAccess and other system services operate under this context.

Investigating Proxy Settings¶

Incorrect or inaccessible proxy settings in the system context are a frequent cause of CRL unreachability. DirectAccess clients, when attempting to download the CRL, use the system’s internet settings. If these settings point to an unreachable proxy or require authentication that cannot be provided by the system context, the download will fail. You can query these settings using specific registry values:

cmd.exe /c reg query HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyEnable
cmd.exe /c reg query HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyServer
cmd.exe /c reg query HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyOverride
cmd.exe /c reg query HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v AutoConfigURL
cmd.exe /c reg query HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyEnable
cmd.exe /c reg query HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyServer
cmd.exe /c reg query HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyOverride
cmd.exe /c reg query HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v AutoConfigURL

These registry queries target the .DEFAULT user profile and the S-1-5-18 (Local System) SID, which are critical for system-level network operations. Understanding the output of these queries is vital for diagnosing proxy-related issues.

Interpreting Proxy Settings:

• If ProxyEnable equals 1 in either .DEFAULT or S-1-5-18, it means “Do Not Automatically Detect Settings.” In this configuration, connections are attempted only through the proxy defined in ProxyServer or AutoConfigURL. If these defined proxies are unavailable or require authentication, CRL downloads will fail.
• If ProxyEnable equals 0, it signifies “Automatically Detect Settings.” While this setting usually indicates reliance on WPAD or other auto-detection methods, it’s important to note that direct modification of this value in HKEY_USERS is generally ineffective. Changes made to HKU\<UserSID> are often overwritten when system services become active.

To modify system proxy settings effectively for troubleshooting, especially when ProxyEnable is 0 and you suspect an issue with automatic detection, you must operate under the System Account (NT AUTHORITY\System). This requires an elevated command prompt and the use of a tool like psexec.exe.

Run the following command from an elevated Command Prompt:

psexec.exe -s -i cmd.exe /c reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings /v ProxyEnable /t REG_DWORD /d 0 /f

This command launches a cmd.exe process under the System account, which then modifies the ProxyEnable setting within the HKCU (HKEY_CURRENT_USER) hive for the System account. Setting ProxyEnable to 0 for the System account can force it to attempt direct connections or use auto-detection, bypassing a problematic static proxy configuration. This is often necessary when troubleshooting, as the system context needs to be able to reach the internet without user-specific proxy complications.

Setting	Value 0	Value 1
ProxyEnable	Automatically Detect Settings	Do Not Automatically Detect Settings
	Attempts direct connection or auto-config	Uses ProxyServer or AutoConfigURL only

Common Reasons for CRL Unreachability Beyond Proxy¶

Even with correct proxy settings, the CRL location can remain unreachable due to several other factors:

1. System context proxy is applied but unreachable and requires user authentication: If a proxy is configured but requires credentials, the system context cannot provide these, leading to failed connections.
2. Hotspot logon is pending: In environments like public Wi-Fi, an initial web page authentication might be required before full internet access is granted. The system context cannot complete this.
3. CRL Location is unavailable on the Internet: The web server hosting the CRL might be down, misconfigured, or simply not publicly accessible.
4. CRL Location requires authentication before access is granted: Similar to proxy authentication, if the web server hosting the CRL requires HTTP authentication, the system context will fail to provide it.
5. CRL Location is reachable, but the CRL files are not allowed to be served: The web server might be online, but its configuration prevents the .crl files from being downloaded due to incorrect file system permissions or MIME type settings.

To address the last point, you must check File System Permissions on the .crl and .delta.crl files on the web server hosting the CRL. Ensure that the “Everyone” group or “Authenticated Users” (or the specific service account for IIS) has at least “Read” access to these files. Without proper permissions, the web server cannot deliver the CRL to clients.

Additionally, ensure that DoubleEscaping is enabled for the CDP location on the IIS server. This is often required for URLs containing special characters that are double-encoded.

Set-WebConfiguration -Filter system.webServer/security/requestFiltering -PSPath 'IIS:\Sites\<SiteName>' -Value @{allowDoubleEscaping=$true}

Replace <SiteName> with the actual name of your IIS website hosting the CRLs. This command allows IIS to properly handle URLs that contain encoded characters within the CDP path, preventing download failures.

Addressing Unpublished CRL Location (CDP)¶

A common reason for revocation check failures is that the Certificate Revocation List (CRL) distribution point (CDP) is not properly published within the certificates issued by the Certification Authority (CA). If the CDP is not correctly included in the certificate’s extension, clients will not know where to look for the CRL. This section outlines the steps to configure and publish the CDP on your Microsoft Certification Authority.

Follow these meticulous steps to ensure the CRL location is correctly published:

1. Click Start, navigate to Administrative Tools, and then select Certification Authority to open the CA management console.
2. In the console tree, right-click on your CA’s name (e.g., corp-DC1-CA), and then click Properties. This action opens the CA’s configuration dialog.
3. Go to the Extensions tab, which displays the configured extensions for certificates issued by this CA. Click Add… to specify a new CDP location.
4. In the Location field, type the full HTTP URL for your public-facing CRL distribution point. This URL must be accessible from the internet where DirectAccess clients will be connecting. A typical format is http://<Public-IIS-URL>/crld/.
5. Next, you need to insert variables to ensure the URL dynamically points to the correct CRL file. In the Variable dropdown, select <CAName>, then click Insert. This variable will be replaced by the CA’s name.
6. Repeat the process for <CRLNameSuffix>, clicking Insert after selection. This variable includes suffixes like (2) for subsequent CRLs.
7. Finally, select <DeltaCRLAllowed> from the Variable dropdown and click Insert. This indicates whether a delta CRL is supported.
8. After inserting all variables, ensure the Location string ends with .crl. For example, the final string might look like http://<Public-IIS-URL>/crld/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl. Click OK to confirm this location.
9. Back on the Extensions tab, with your newly added HTTP CDP selected, enable the following options:
   • Include in CRLs. Clients use this to find Delta CRL locations. This ensures that the base CRL points to delta CRLs if they are used.
   • Include in the CDP extension of issued certificates. This is crucial, as it embeds the CDP URL into every certificate issued by the CA, allowing clients to discover where to find the CRL.
10. Click Add… again to define an internal location for publishing the CRL. This is where the CA will physically publish the CRLs.
11. In the Location field, type the internal UNC path where the CA will publish the CRLs, typically a shared folder on an IIS server. For example, \\<IIS-ServerName>\crldist$\.
12. Insert the same variables as before: <CAName>, <CRLNameSuffix>, and <DeltaCRLAllowed>.
13. Ensure the Location string ends with .crl. For example, \\<IIS-ServerName>\crldist$\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl. Click OK.
14. For this internal UNC path, enable the following checkboxes:
    • Publish CRLs to this location.
    • Publish Delta CRLs to this location.
15. Click OK to close the CA Properties dialog. You will be prompted to restart Active Directory Certificate Services. Click Yes to apply the changes.
16. Close the Certification Authority console.

After restarting the services, the CA will begin publishing CRLs to the specified locations, and all newly issued certificates will contain the correct CDP extension, enabling clients to find and download the CRLs for revocation checks.

Managing Expired CRLs¶

An expired Certificate Revocation List (CRL) is as problematic as an unreachable one, as it cannot provide current revocation status for certificates. If the CA fails to publish a new CRL before the previous one expires, clients will treat all certificates as potentially revoked or unable to be validated, leading to CRYPT_E_REVOCATION_OFFLINE errors. Regular monitoring of CRL expiration dates is a critical administrative task for any Public Key Infrastructure (PKI).

If you discover that your CRL has expired, the immediate resolution is to republish a new, valid CRL. This action forces the Certificate Authority to generate an updated list of revoked certificates with a new expiration date and publish it to all configured distribution points.

To republish the CRL, use the Certutil command-line utility:

Certutil -crl

Execute this command from an elevated command prompt on the Certification Authority server. This command instructs the CA to immediately generate and publish a new base CRL and, if configured, a new delta CRL. Once published, clients accessing the CDP will download the fresh CRL, allowing them to perform successful revocation checks.

It is highly recommended to establish a regular schedule for CRL publication, ensuring that new CRLs are generated and published well in advance of the current CRL’s expiration. This proactive measure prevents service interruptions caused by expired revocation information. Automating this process through scripts or CA configuration settings can significantly enhance the reliability of your PKI.

Clearing Client Cache for CRLs¶

Even when the Certificate Revocation List (CRL) is reachable and valid, DirectAccess clients might still encounter revocation errors if they are operating with outdated cached information. Clients locally cache various certificate-related data, including Time Validated Objects (TVOs) and URL cache entries. A stale cache can lead to clients using an old, potentially expired or superseded CRL, causing validation failures despite a fresh CRL being available on the server.

To resolve issues stemming from an old client cache, it is necessary to clear these cached entries, forcing the client to re-download the latest revocation information.

Clearing Time Validated Objects (TVO) Cache¶

The TVO cache stores information about the validity status of certificates and their chains, including revocation status. If this cache holds stale data, the client may incorrectly believe a certificate is revoked or unvalidated.

To clear the TVO cache and force a resynchronization, use the following Certutil command from an elevated command prompt on the client machine:

Certutil -setreg chain\ChainCacheResyncFiletime @now

This command sets the ChainCacheResyncFiletime registry value to the current time, effectively invalidating the existing TVO cache. The @now keyword instructs Certutil to use the current timestamp, prompting the system to re-evaluate and re-cache certificate chain information upon the next validation attempt. This ensures that the client processes the most up-to-date certificate and revocation data.

Clearing URL Cache¶

The URL cache stores downloaded CRL files and other certificate-related content from their respective distribution points. If an old or corrupted CRL file is lingering in this cache, it can prevent the client from downloading and using a new, valid CRL.

To clear the entire URL cache for certificate-related objects, execute this Certutil command from an elevated command prompt on the client:

Certutil -urlcache * delete

The * wildcard specifies that all entries in the certificate URL cache should be deleted. This action removes all cached CRLs, Authority Information Access (AIA) files, and other URL-retrieved certificate components. Upon the next certificate validation attempt, the client will be forced to download fresh copies of these resources from their configured distribution points, ensuring it uses the most current revocation information. Clearing both TVO and URL caches provides a comprehensive refresh of the client’s certificate validation environment.

Deep Dive: DirectAccess and Certificate Revocation¶

To fully appreciate the troubleshooting steps, it’s beneficial to understand the underlying mechanisms of DirectAccess connectivity and the role of Certificate Revocation Lists (CRLs). These components are fundamental to the secure operation of DirectAccess and the reliability of IP-HTTPS connections.

DirectAccess Connectivity Methods¶

DirectAccess clients employ a hierarchy of connectivity methods to establish tunnels to the DirectAccess server, enabling access to internal network resources. The choice of method depends on the client’s network environment and the server’s configuration. These methods include Teredo, 6to4, and IP-HTTPS, each serving a specific purpose in ensuring persistent connectivity.

When a DirectAccess client possesses a public IPv4 address, it first attempts to connect using the 6to4 interface. However, many Internet Service Providers (ISPs) provide what appears to be a public IP address but is, in reality, behind one or more Network Address Translators (NATs), effectively a pseudo-public IP. In such scenarios, the client cannot establish a direct 6to4 connection.

If the client is behind a NAT device, it will then try to use Teredo, which is designed to tunnel IPv6 over IPv4 through NATs. Nevertheless, many corporate networks, hotels, airports, and coffee shops block Teredo traffic at their firewalls due to security policies or lack of support. This often renders Teredo ineffective in diverse public network environments.

In situations where both 6to4 and Teredo fail, the client falls back to IP-HTTPS. IP-HTTPS establishes an IP-based connection over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) tunnel using TCP port 443. This method is highly reliable because SSL outbound traffic on port 443 is almost universally allowed across firewalls, making it a robust backup connection that is nearly always reachable. Understanding this failover mechanism highlights why IP-HTTPS is critical and why its failures disproportionately impact client connectivity.

Understanding Certificate Revocation Lists (CRLs)¶

Certificate Revocation Lists (CRLs) are foundational elements in public key infrastructure (PKI), playing a vital role in maintaining the security and trustworthiness of digital certificates. They serve as a mechanism to distribute information about certificates that have been revoked before their scheduled expiration date. Revocation can occur for various reasons, such as a compromise of the certificate’s private key, changes in an individual’s employment status, or misissuance.

CRLs are essentially digitally signed lists of unexpired certificates that are no longer considered valid. When a client needs to verify the authenticity of a certificate, it retrieves the current CRL from a designated distribution point. Clients can cache these CRLs for a period, based on the configured lifetime of the CRL, to expedite future validation checks. A Microsoft Enterprise Certificate Authority typically publishes CRLs to two primary locations: an HTTP URL (e.g., http://CAName/certenroll/CRLName) for internet accessibility and an LDAP path for domain-joined clients (e.g., LDAP:///CN=CAName,...). Proper and timely publication of CRLs is therefore paramount for reliable certificate validation.

Basic Certificate Chain Validation Process¶

When a cryptographic application or system, such as CryptoAPI in Windows, builds and validates a certificate chain, a systematic three-phase process unfolds. This process ensures that a presented certificate can be traced back to a trusted root authority and that none of the certificates in the chain have been revoked. Any failure in these phases, particularly during revocation checking, can lead to security warnings or connection failures, as seen with DirectAccess.

1. Chain Building: Initially, CryptoAPI attempts to construct all possible certificate chains using certificates already present in the local cache or certificate stores. If none of these chains successfully terminate in a self-signed certificate, CryptoAPI then retrieves issuer certificates specified in the Authority Information Access (AIA) extension of the current certificate. This retrieval process continues iteratively until a complete chain, ending in a self-signed certificate residing in a trusted root store, is successfully built.
2. Revocation Checking: Once a complete chain is built and ends in a trusted self-signed certificate, revocation checking is performed for each certificate within the chain. This involves downloading and consulting the Certificate Revocation List (CRL) or querying an Online Certificate Status Protocol (OCSP) responder for each certificate. The system verifies that none of the certificates in the path have been marked as revoked.
3. Root CA Validation: Finally, the entire chain is validated from the leaf certificate all the way up to the root Certificate Authority (CA) certificate. This includes ensuring that the root CA certificate itself is present in the local trusted root store and that its revocation status can also be confirmed, if applicable. Only if all these steps pass successfully is the certificate deemed valid and trustworthy.

Certificate Revocation Checking and CRL Distribution Points in DirectAccess¶

The integrity of DirectAccess connections heavily relies on robust certificate revocation checks, especially for IP-HTTPS and the Network Location Server (NLS). These checks ensure that the certificates used for secure communication have not been compromised or invalidated. Failure at any point in these checks can severely impede DirectAccess functionality.

A certificate revocation check is absolutely mandatory for the IP-HTTPS connection established between the DirectAccess client and the DirectAccess server. If this crucial check fails, DirectAccess clients will be unable to form IP-HTTPS-based connections, thereby losing their primary fallback method for remote access. Consequently, an Internet-based CRL distribution point location must be meticulously included within the IP-HTTPS certificate and must remain publicly accessible for all DirectAccess clients connected to the internet. This ensures that clients can always retrieve the necessary revocation information regardless of their location.

Similarly, a certificate revocation check is also a prerequisite for the IP-HTTPS-based connection to the Network Location Server (NLS). The NLS determines whether the client is inside or outside the corporate network. If the NLS certificate revocation check fails, DirectAccess clients cannot properly access the NLS URL, even if DirectAccess rules are present in the Name Resolution Policy Table (NRPT). Therefore, an intranet-based CRL distribution point location must be embedded in the NLS server certificate and must be available to DirectAccess clients when they are connected to the intranet. This ensures seamless NLS resolution and accurate network location detection.

Finally, certification revocation checks are equally critical for the IPsec tunnels established between the DirectAccess client and the DirectAccess server. These tunnels, which carry the actual network traffic, rely on certificates for authentication and encryption. Any revocation issue with these certificates would prevent the secure IPsec tunnels from forming, ultimately blocking access to internal resources.

Ensuring all CDP locations are correctly configured, published, and accessible, both internally and externally, is fundamental to a healthy and reliable DirectAccess deployment.

Share Your Experience¶

We hope this comprehensive guide assists you in troubleshooting and resolving DirectAccess IP-HTTPS connection issues related to certificate revocation. Understanding these underlying mechanisms and applying the detailed resolution steps can significantly improve your DirectAccess client connectivity.

Have you encountered similar issues? Do you have additional tips or insights that could benefit other administrators? Share your experiences and questions in the comments below. Your contributions help the community grow!