Share via

Validate HTTPS Configuration for Microsoft Connected Cache on Linux

This article provides instructions on how to validate HTTPS Support on Microsoft Connected Cache for Enterprise and Education nodes running on 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

The following curl commands test both HTTP and HTTPS content retrieval:

  • HTTPS Test:

    curl -v -o /dev/null "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 -v -o /dev/null "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 Linux host machine:

  • Test connectivity with wget:

    wget --server-response --spider --header="host: swda01-mscdn.manage.microsoft.com" "https://[mcc-connection]/[test-url]"

    Expected result: HTTP/1.1 200 OK indicates successful HTTPS connection.

  • Verify certificate details:

    echo | openssl s_client -connect [mcc-connection]:443 -servername [mcc-connection] 2>/dev/null | openssl x509 -text -noout

    Expected result: Certificate details including subject, issuer, and SAN values should match your configuration.

  • Check container status and logs:

    # Check if the Connected Cache container is running
sudo docker ps | grep mcc

# View recent container logs for HTTPS activity
sudo docker logs --tail 50 $(sudo docker ps -q --filter ancestor=mcr.microsoft.com/mcc/linux)

    Expected result: Container should be in "Up" status and logs should show TLS/SSL activity without errors.

  • Testing SSL/TLS handshake:

    Test the SSL/TLS handshake without validating the certificate:

        # Basic connection test
    openssl s_client -connect [mcc-server]:443

    # Test with SNI (Server Name Indication)
    openssl s_client -connect [mcc-server]:443 -servername [hostname]

    # View certificate details during connection
    echo | openssl s_client -connect [mcc-server]:443 2>/dev/null | openssl x509 -noout -text

Client-side validation

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

Prerequisite: Ensure that the host is targeted via policy. Update the Connected Cache IP address (the value for the "DOCacheHost" policy) to whatever is relevant for your 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.

  • If your Connected Cache Linux server Windows clients, test the following from those machines:

    # Test TCP connection
Test-NetConnection -ComputerName [mcc-server] -Port 443

# Test HTTPS connection
Invoke-WebRequest -Uri "https://[mcc-server]/" -UseBasicParsing

# View certificate details
$cert = [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
Invoke-WebRequest -Uri "https://[mcc-server]/"

  • Test if port 443 is accessible:

        # Using telnet
    telnet [mcc-server-ip] 443

    # Using nc (netcat)
    nc -zv [mcc-server-ip] 443

    # Using nmap (if installed)
    nmap -p 443 [mcc-server-ip]

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 -v -k -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

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 -v --ssl-no-revoke -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

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 are configured correctly

  • Check that no other service is using port 443:

    sudo ss -tulpn | grep :443

  • Verify the Connected Cache container is running:

    sudo docker ps | grep mcc

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

sudo ss -tulpn | grep :80

For DNS resolution issues: Verify hostname resolution and network connectivity

nslookup [mcc-connection]
# OR
dig [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.

Additional resources

  • Last updated on