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 (e.g., 192.168.1.100)
  • If you used -sanDns in your CSR: Use the hostname (e.g., 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://statics.teams.cdn.office.net/production-windows-x64/enterprise/webview2/lkg/MSTeams-x64.msix"
    

    OR

    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 you encounter any of the following common errors during validation, use these troubleshooting approaches:

Important

Reminder to 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 (e.g., 192.168.1.100)
  • If you used -sanDns in your CSR: Use the hostname (e.g., 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

Quick Test:

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

If the test succeeds: Your certificate has validation issues. Verify that:

  • SAN configuration matches your connection method
  • CA root certificate is installed in the client's trusted store

If the test fails: See Connection errors below.

Certificate revocation errors

Symptoms: Slow HTTPS responses or timeouts

Quick Test:

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: Your CA's certificate revocation list (CRL) distribution point is unreachable. Check that firewall allows access to CRL URLs.

If the test fails: See Connection errors below.

Connection errors

Symptoms: Connection refused, Could not resolve host

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