Validar la configuración HTTPS para la caché conectada de Microsoft en Linux

En este artículo se proporcionan instrucciones sobre cómo validar la compatibilidad con HTTPS en los nodos de Caché conectado de Microsoft para empresas y educación que se ejecutan en Linux.

Prueba de descargas de contenido HTTP y HTTPS

Antes de realizar las pruebas, debe identificar cómo se conectan los clientes al servidor de caché conectada. Este es el mismo método de conexión que configuró en el nombre alternativo del firmante (SAN) del certificado durante la generación de CSR.

Los siguientes comandos curl prueban la recuperación de contenido HTTP y HTTPS:

• Prueba HTTPS:

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

  Salida correcta esperada:

  * 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]
  

• Prueba HTTP:

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

  Salida correcta esperada:

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

Validación del lado del servicio

Realice las siguientes pruebas en el equipo host de Linux:

• Pruebe la conectividad con wget:

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

  Resultado esperado:HTTP/1.1 200 OK indica una conexión HTTPS correcta.

• Compruebe los detalles del certificado:

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

  Resultado esperado: Los detalles del certificado, incluidos los valores de asunto, emisor y SAN, deben coincidir con la configuración.

• Compruebe el estado y los registros del contenedor:

  # 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)
  

  Resultado esperado: El contenedor debe estar en estado "Up" y los registros deben mostrar la actividad TLS/SSL sin errores.

• Prueba del protocolo de enlace SSL/TLS:

  Pruebe el protocolo de enlace SSL/TLS sin validar el certificado:

      # 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
  

Validación del lado cliente

Realice los siguientes comandos en un dispositivo cliente (no en el equipo host de Linux).

Requisito previo: Asegúrese de que el host está destinado a través de la directiva. Actualice la dirección IP de caché conectada (el valor de la directiva "DOCacheHost") a lo que sea relevante para su entorno:

$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

• Solicitar la descarga de la aplicación de Teams desde la caché conectada a través de HTTPS:

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

  Resultado esperado: La descarga se completa sin errores y debe ser más rápida que las descargas típicas de Internet.

• Compruebe que el contenido se está almacenando realmente en caché (no solo retrocediendo a la red CDN):

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

  Resultado esperado:BytesFromCacheServer debe ser mayor que 0, lo que indica que el almacenamiento en caché se ha realizado correctamente.

• Si la caché conectada Linux clientes windows del servidor, pruebe lo siguiente desde esas máquinas:

  # 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]/"
  

• Pruebe si el puerto 443 es accesible:

      # 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]
  

Solución de problemas

Si se produce un error en un paso de validación, use las siguientes pruebas para aislar la causa. Cada prueba omite una parte del proceso de conexión. Si la prueba se realiza correctamente, sabe que la parte omitida es el problema.

Errores de validación de certificados

Síntomas:SSL certificate problem, certificate subject name does not match

Prueba de diagnóstico: El siguiente comando usa la marca para omitir completamente la -k validación de certificados. Esto indica a curl que se conecte sin comprobar el certificado del servidor. De este modo, puede determinar cuál es el problema: el certificado o algo más.

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

Si la prueba se realiza correctamente: El servidor y la red funcionan correctamente. El problema es con el propio certificado. Compruebe que:

• La configuración de SAN coincide con el método de conexión (dirección IP o nombre de host)
• El certificado raíz de ca se instala en el almacén de confianza del cliente.

Si se produce un error en la prueba: El problema no es el certificado. Consulte Errores de conexión a continuación.

Errores de revocación de certificados

Síntomas: Tiempos de espera o respuestas HTTPS lentos

Prueba de diagnóstico: El siguiente comando usa la marca para omitir la --ssl-no-revoke comprobación de la lista de revocación de certificados (CRL). Normalmente, el cliente se pone en contacto con el punto de distribución CRL de la entidad de certificación para comprobar que el certificado no se ha revocado. Si ese punto de conexión no es accesible, provoca lentitud o tiempos de espera.

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

Si la prueba se realiza correctamente: La conexión funciona cuando se omite la comprobación de revocación, lo que confirma que el cliente no puede llegar al punto de distribución CRL. Compruebe que el firewall permite el acceso a las direcciones URL de CRL que aparecen en el certificado.

Si se produce un error en la prueba: El problema no es la comprobación de revocación. Consulte Errores de conexión a continuación.

Errores de conexión

Síntomas:Connection refused, Could not resolve host

Si no se puede conectar en absoluto (en lugar de conectarse pero ver errores de certificado), el problema suele estar relacionado con la red o el firewall.

Para errores de conexión HTTPS:

• Comprobación de que las reglas de firewall están configuradas correctamente

• Compruebe que ningún otro servicio usa el puerto 443:

  sudo ss -tulpn | grep :443
  

• Compruebe que el contenedor de caché conectada se está ejecutando:

  sudo docker ps | grep mcc
  

Para errores de conexión HTTP: Compruebe que el servicio de caché conectada se está ejecutando y que el puerto 80 es accesible.

sudo ss -tulpn | grep :80

Para problemas de resolución de DNS: Comprobación de la resolución del nombre de host y la conectividad de red

nslookup [mcc-connection]
# OR
dig [mcc-connection]

Interferencia de proxy corporativo

Síntomas: Se produce un error en la validación de certificados a pesar de la configuración correcta.

Solución: Asegúrese de que el proxy corporativo no intercepta el tráfico HTTPS al servidor de caché conectada. Considere la posibilidad de deshabilitar la inspección de TLS para el tráfico interno de la caché conectada.

Recursos adicionales

• Introducción a HTTPS en Linux
• HTTPS en Linux referencia
• Solución de problemas de caché conectada