Share via

Validate HTTPS Configuration for Microsoft Connected Cache on Windows

This article provides instructions on how to validate HTTPS Support on Microsoft Connected Cache for Enterprise and Education nodes running on Windows with WSL (Windows Subsystem for Linux).

Test HTTP and HTTPS content downloads

Before testing, you need to identify how clients connect to your Connected Cache server. This is the same connection method you configured in your certificate's Subject Alternative Name (SAN) during CSR generation.

Important

Replace [mcc-connection] and [test-url] in all commands below

To determine your [mcc-connection]:

  • If you used -sanIp in your CSR: Use the IP address (example: 192.168.1.100)
  • If you used -sanDns in your CSR: Use the hostname (example: mcc-server.contoso.com)

[test-url] is the full path of a test Intune Win32 application: ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Then, run the following curl commands on your Windows host machine (the Connected Cache server) to test both HTTP and HTTPS content retrieval:

  • HTTPS Test

        curl.exe -v -o NUL "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

    Expected successful output:

    * Connected to [your-server] ([ip-address]) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: [your-certificate-subject]
< HTTP/1.1 200 OK
< Content-Length: [file-size]

  • HTTP Test

        curl.exe -v -o NUL "http://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

    Expected successful output:

    * Connected to [your-server] ([ip-address]) port 80 (#0)
< HTTP/1.1 200 OK
< Content-Length: [file-size]

Service-side validation

Perform the following tests on your Windows host machine:

  • Test connectivity with PowerShell:

        Invoke-WebRequest -Uri "https://[mcc-connection]/[test-url]" -Headers @{"host"="swda01-mscdn.manage.microsoft.com"} -Method Head

    Expected result: StatusCode: 200 indicates successful HTTPS connection.

  • Check Delivery Optimization logs for HTTPS activity:

      # Search for HTTPS connections in recent logs
  Select-String -Path "C:\Windows\Logs\DeliveryOptimization\*.log" -Pattern "https://" | Select-Object -First 5

  # Search for your specific Connected Cache server connections
  Select-String -Path "C:\Windows\Logs\DeliveryOptimization\*.log" -Pattern "[mcc-connection]" | Select-Object -First 5

    Expected result: Log entries showing HTTPS URLs and your Connected Cache server address indicate clients are using HTTPS successfully.

Client-side validation

Perform the following commands on a client device (not your Windows host machine).

Prerequisite: Ensure that host machine is targeted via policy. Update the Connected Cache IP address (the value for the "DOCacheHost" policy) to whatever is relevant for their environment:

   $parentKeyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization"
   if (!(Test-Path $parentKeyPath))
     {
        New-Item -Path $parentKeyPath -ItemType RegistryKey -Force -ErrorAction Stop | Out-Null
     }
   Set-ItemProperty -Path $parentKeyPath -Name "DOCacheHost" -Value "[mcc-connection]" -ErrorAction Stop

  • Request Teams app download from Connected Cache via HTTPS:

        Add-AppxPackage "https://installer.teams.static.microsoft/production-windows-x64/25177.2002.3761.5185/MSTeams-x64.msix"

    Expected result: Download completes without error and should be faster than typical internet downloads.

  • Check that content is actually being cached (not just falling back to CDN):

        Get-DeliveryOptimizationStatus | Select-Object DownloadMode, TotalBytesDownloaded, BytesFromCacheServer

    Expected result: BytesFromCacheServer should be greater than 0, indicating successful caching.

Troubleshooting

If a validation step fails, use the following tests to isolate the cause. Each test bypasses one part of the connection process. If the test succeeds, you know that the bypassed part is the problem.

Important

Replace [mcc-connection] and [test-url] in all commands below

To determine your [mcc-connection]:

  • If you used -sanIp in your CSR: Use the IP address (example: 192.168.1.100)
  • If you used -sanDns in your CSR: Use the hostname (example: mcc-server.contoso.com)

[test-url] is the full path of a test Intune Win32 application: ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Certificate validation errors

Symptoms: SSL certificate problem, certificate subject name does not match

Diagnostic test: The following command uses the -k flag to skip certificate validation entirely. This tells curl to connect without verifying the server's certificate. This way, you can determine what's the problem: the certificate or something else.

   curl.exe -v -k -o NUL "https://[mcc-connection]/[test-url]"

If the test succeeds: The server and network are working correctly. The problem is with the certificate itself. Verify that:

  • SAN configuration matches your connection method (IP address or hostname)
  • CA root certificate is installed in the client's trusted store

If the test fails: The issue isn't the certificate. See Connection errors below.

Certificate revocation errors

Symptoms: Slow HTTPS responses or timeouts

Diagnostic test: The following command uses the --ssl-no-revoke flag to skip certificate revocation list (CRL) checking. Normally, the client contacts your CA's CRL distribution point to verify the certificate hasn't been revoked. If that endpoint is unreachable, it causes slowness or timeouts.

   curl.exe -v --ssl-no-revoke -o NUL "https://[mcc-connection]/[test-url]"

If the test succeeds: The connection works when revocation checking is skipped, which confirms the client can't reach the CRL distribution point. Check that your firewall allows access to the CRL URLs listed in your certificate.

If the test fails: The issue isn't revocation checking. See Connection errors below.

Connection errors

Symptoms: Connection refused, Could not resolve host

If you can't connect at all (as opposed to connecting but seeing certificate errors), the issue is typically related to network or firewall.

For HTTPS connection errors:

  • Verify firewall rules and port forwarding are configured correctly

  • Check that no other service is using port 443:

        netstat -an | findstr :443

For HTTP connection errors: Verify that Connected Cache service is running and port 80 is accessible

   netstat -an | findstr :80

For DNS resolution issues: Verify hostname resolution and network connectivity

   nslookup [mcc-connection]

Corporate proxy interference

Symptoms: Certificate validation fails despite correct configuration.

Solution: Ensure that corporate proxy doesn't intercept HTTPS traffic to your Connected Cache server. Consider disabling TLS inspection for internal Connected Cache traffic.

Resources

  • Last updated on