¿Puedo usar un Comodo Wildcard-Subdomain Cert para RDP en Win10?

Seguí

  • Uso del certificate de CA para la connection a Escritorio remoto
  • Configurar certificate SSL personalizado para RDP en Windows Server 2012 en modo Administración remota?

para proteger RDP con un certificate adecuado en lugar de uno firmado por Windows uno. Todo esto funciona bien. Hasta que corra

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="MY_HASH" 

Este command sólo da como resultado "Parámetro no válido".

El mismo command funciona bien con el hash de la original (auto-firmado Windows) cert. Así que supongo que algo debe estar mal con mi cert. Parece que se instala correctamente en la tienda cert (con key privada y en la subsección "Remotedesktop").

Mirando los detalles del cert en el snapin de la certificación MMC mi cert importado tiene un signo de exclamación amarillo al lado de:

Key Usage = Firma digital, encryption de key (a0)

y el campo adicional

Limitaciones de base = Tipo de solicitante: unidad final

Mientras que el cert auto-firmado que Windows genera para la connection RDP tiene:

Key Usage = Encriptación de keys, encryption de datos (30)

¿Hay alguna manera de cambiar esto, o es simplemente no es posible utilizar este cert para RDP?


Algunas informaciones adicionales:

  • El cert es un CERO COMODO PositiveSSL Wildcard,
  • Convertido el cert de la forma original de PEM a PKCS7 y de PKCS7 a PKCS # 12 / PFX usando OpenSSL antes de importarlo al almacén cert de Windows,
  • Otra diferencia entre los certs es que el Windows uno es un sha1 uno mientras que el cerdo de Comodo es un sha256 uno,
  • Es una estación de trabajo Win10,
  • La estación de trabajo no es miembro de ningún dominio, sino una installation independiente.

Me temo que debo responder a mi propia pregunta y la respuesta parece ser No. Usando el command openssl x509 -in cert.crt -purpose -noout -text que el openssl x509 -in cert.crt -purpose -noout -text original entregado por Comodo ya carece de las banderas necesarias en el campo Key Usage . No tiene la característica Data Encipherment .

El cerdo Comodo se parece a esto:

  X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication 

Aunque el cert firmado por Windows tiene los siguientes indicadores:

  X509v3 extensions: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Key Usage: Key Encipherment, Data Encipherment 

No sé si todavía necesita la respuesta para este problema, pero si alguien todavía lo necesita aquí lo tiene.

Realmente no necesita los attributes especificados por usted.

Siguiendo los pasos de esta publicación, se realizará la installation de cualquier CRT (comodín o Normal) en un controller de equipo / dominio.

No probé sin el AD CS, pero creo que funciona.

Lo único que debes hacer es convertir el CRT / p7b en cer y luego en pfx (pkcs12) usando la key y el package. A continuación, importarlo manualmente en su sistema operativo.

https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/ – esta es la publicación.

https://www.sslshopper.com/ssl-converter.html – aquí puede encontrar cómo convertir los certificates.

Por cierto, puede omitir la parte de la secuencia de commands de WMI y utilizar el siguiente command de powershell con derechos administrativos:

wmic / namespace: \ raíz \ cimv2 \ TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash = "SU-THUMBPRINT-GOES-HERE"

Funcionó para mí en Windows Server 2016 / Windows 10.

¡Espero eso ayude! 🙂