Share via


HTTPS Support for Linux reference for Microsoft Connected Cache

This article provides more detail for the Linux HTTPS setup flow on Connected Cache.

Prerequisites

Client connection methods

Try the following to determine the appropriate connection method to your Connected Cache server, for the purposes of setting up HTTPS support.

  • Check Delivery Optimization Policy Configuration

    If your network uses DHCP Option 235 to advertise the Connected Cache server:

    resolvectl status | grep -A 10 "Link"
    

    Look for DHCP-provided DNS or domain information that might reference your Connected Cache server.

  • Check network configuration files

    Depending on your Linux distribution, network configuration may contain static Connected Cache references:

    # For systems using NetworkManager
    cat /etc/NetworkManager/system-connections/*
    
    # For systems using netplan (Ubuntu 18.04+)
    cat /etc/netplan/*.yaml
    
    # For traditional /etc/network/interfaces
    cat /etc/network/interfaces
    
  • Test connectivity to Connected Cache server

    The following command checks TCP connectivity to port 80 on the Connected Cache server:

    nc -zv [insert-mcc-server-ip-or-hostname] 80
    

    Expected output: Connection to [server] 80 port [tcp/http] succeeded!

    To get more detailed information:

    curl -v -I http://[insert-mcc-server-ip-or-hostname]/
    

Port 443 Availability

  • Alternative command to check port 443 availability:

    sudo netstat -tulpn | grep :443
    
  • Check which process is currently using port 443:

    sudo lsof -i :443
    

Firewall configuration details

Use the following to check if your firewall is intercepting HTTPS traffic to your Connected Cache server (for example, via TLS inspection)

Common Linux distributions:

Ubuntu/Debian (UFW):

# Check firewall status
sudo ufw status

# Allow port 443
sudo ufw allow 443/tcp

# Reload firewall
sudo ufw reload

# Verify rule was added
sudo ufw status numbered

RHEL/CentOS/Fedora (firewalld):

# Check firewall status
sudo firewall-cmd --state

# Allow port 443 temporarily (until reboot)
sudo firewall-cmd --add-port=443/tcp

# Allow port 443 permanently
sudo firewall-cmd --permanent --add-port=443/tcp

# Reload firewall
sudo firewall-cmd --reload

# List all rules
sudo firewall-cmd --list-all

iptables (Traditional):

# Check current rules
sudo iptables -L -n -v

# Add rule for port 443
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Save rules (location varies by distribution)
# For Ubuntu/Debian:
sudo iptables-save | sudo tee /etc/iptables/rules.v4

# For RHEL/CentOS:
sudo service iptables save

SELinux considerations

If you're running RHEL/CentOS/Fedora with SELinux enabled, you may need to configure SELinux policies:

# Check SELinux status
sestatus

# Allow HTTP/HTTPS traffic
sudo setsebool -P httpd_can_network_connect 1

# If using custom ports, add them to SELinux
sudo semanage port -a -t http_port_t -p tcp 443

Generate CSR

Scenario-Based Parameter Examples

Review scenario-based parameter examples and make edits to your generateCsr.sh command accordingly:

Single Office - IP Address Only

Scenario: Small branch office where clients are configured to connect to Connected Cache using a static IP address (for example, via DOCacheHost policy set to "192.168.1.100").

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-branch-office" \
    -subjectCommonName "192.168.1.100" \
    -subjectCountry "US" \
    -subjectState "TX" \
    -subjectOrg "Contoso Corp" \
    -sanIp "192.168.1.100"

Enterprise Standard - DNS Hostname

Scenario: Enterprise environment where clients connect via standardized hostname (mcc-server.contoso.com).

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 4096 \
    -csrName "mcc-enterprise-prod" \
    -subjectCommonName "mcc-server.contoso.com" \
    -subjectCountry "US" \
    -subjectState "Washington" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-server.contoso.com"

DHCP Discovery Environment

Scenario: Environment using DHCP Option 235 for Connected Cache discovery where clients might connect using the server's actual hostname or DHCP-provided name.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-dhcp-discovery" \
    -subjectCommonName "cache-server.corporate.local" \
    -subjectCountry "US" \
    -subjectState "FL" \
    -subjectOrg "Corporate IT Services" \
    -sanDns "cache-server.corporate.local,mcc-auto.corporate.local,fileserver.corporate.local"

Hybrid Environment - Mixed Client Connections

Scenario: Mixed environment during migration where some legacy clients still use IP addresses while newer clients use DNS names. Covers both connection methods.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-hybrid-migration" \
    -subjectCommonName "mcc-cache.contoso.com" \
    -subjectCountry "US" \
    -subjectState "CA" \
    -subjectOrg "Contoso Inc" \
    -sanDns "mcc-cache.contoso.com,cache.contoso.local" \
    -sanIp "10.0.1.50,192.168.100.10"

Multi-Site with Regional Naming

Scenario: Large organization with multiple Connected Cache nodes using consistent naming convention (mcc-region-site format). This example is for a Seattle datacenter node.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 4096 \
    -csrName "mcc-seattle-dc1" \
    -subjectCommonName "mcc-sea-dc1.corp.contoso.com" \
    -subjectCountry "US" \
    -subjectState "Washington" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-sea-dc1.corp.contoso.com,mcc-seattle.contoso.com"

Development/Testing Environment

Scenario: Development environment with relaxed naming requirements. Supports localhost testing and lab network access.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-dev-lab" \
    -subjectCommonName "localhost" \
    -subjectCountry "US" \
    -subjectState "Dev" \
    -subjectOrg "IT Development" \
    -sanDns "localhost,mcc-dev.lab.local,devserver.local" \
    -sanIp "127.0.0.1,192.168.10.100,10.10.10.50"

High-Security with Elliptic Curve

Scenario: Security-conscious organization requiring modern ECC cryptography for better performance and compliance with newer security standards.

./generateCsr.sh \
    -algo EC \
    -keySizeOrCurve secp384r1 \
    -csrName "mcc-secure-prod" \
    -subjectCommonName "mcc-secure.defense.gov" \
    -subjectCountry "US" \
    -subjectState "VA" \
    -subjectOrg "Department of Defense" \
    -sanDns "mcc-secure.defense.gov"

Cloud/Virtual Machine Deployment

Scenario: Connected Cache node deployed on a cloud VM or virtual machine with both public and private connectivity. Clients from on-premises connect via private IP/hostname, while cloud-based clients may use the public DNS name.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-cloud-hybrid" \
    -subjectCommonName "mcc-eastus.cloudapp.azure.com" \
    -subjectCountry "US" \
    -subjectState "WA" \
    -subjectOrg "Contoso Corporation" \
    -sanDns "mcc-eastus.cloudapp.azure.com,mcc-cloud.contoso.local,mcc-vm01.contoso.com" \
    -sanIp "10.0.1.10,172.16.0.50"

Docker Container Environment

Scenario: Connected Cache running in Docker container where clients connect to the host machine's IP but certificate needs to account for container networking.

./generateCsr.sh \
    -algo RSA \
    -keySizeOrCurve 2048 \
    -csrName "mcc-docker-host" \
    -subjectCommonName "mcc-docker.company.local" \
    -subjectCountry "US" \
    -subjectState "CA" \
    -subjectOrg "Company IT" \
    -sanDns "mcc-docker.company.local,localhost" \
    -sanIp "192.168.1.100,172.17.0.1,127.0.0.1"

Sign CSR

Convert to .crt file type

  • If you receive .cer:

    mv xxxx.cer xxxx.crt
    

    Or with OpenSSL:

    openssl x509 -in xxxx.cer -out xxxx.crt
    
  • If you receive .der:

    openssl x509 -inform DER -in xxxx.der -out xxxx.crt
    

Verify certificate contents

After conversion, verify the certificate is correct:

openssl x509 -in xxxx.crt -text -noout

Look for:

  • Subject: Should match your CSR subject
  • Subject Alternative Name: Should contain all your configured SANs
  • Validity: Not Before and Not After dates
  • Signature Algorithm: Should match your chosen algorithm (RSA, EC, etc.)

Additional resources