Posso usar um certificado Comodo Wildcard-Subdomain para RDP no Win10?

3

eu segui

para proteger o RDP com um certificado adequado em vez do Windows autoassinado. Isso tudo funciona bem. Até eu correr

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

Este comando só resulta em "Par inválido".

O mesmo comando funciona bem com o hash do certificado original (Windows autoassinado). Então, acho que algo deve estar errado com o meu certificado. Parece estar corretamente instalado na loja cert (com chave privada e sob a subseção "Remotedesktop").

Observando os detalhes do certificado no snap-in do MMC de certificação, meu certificado importado tem um ponto de exclamação amarelo ao lado de:

Key Usage = Digital signature, key encryption (a0)

e o campo adicional

Base Limitations = Type of requester: end unit

Enquanto o certificado auto-assinado gerado pelo Windows para a conexão RDP:

Key Usage = Key encryption, data encryption (30)

Existe alguma maneira de mudar isso, ou simplesmente não é possível usar este certificado para o RDP?

Algumas informações adicionais:

  • O certificado é um certificado Wildcard COMODO PositiveSSL,
  • Eu converti o certificado do formulário PEM original para PKCS7 e de PKCS7 para PKCS # 12 / PFX usando o OpenSSL antes de importá-lo para a loja cert Windows,
  • Outra diferença entre os certs é que o Windows é sha1, enquanto o Comodo cert é sha256,
  • É uma estação de trabalho Win10,
  • A estação de trabalho não é membro de nenhum domínio, mas de uma instalação independente.
por s1lv3r 04.01.2016 / 13:55

2 respostas

3

Eu tenho medo de responder minha própria pergunta e a resposta parece ser Não . Usando o comando openssl x509 -in cert.crt -purpose -noout -text , o certificado original entregue pelo Comodo já não possui os flags necessários no campo Key Usage . Não possui o recurso Data Encipherment .

O Comodo cert é assim:

        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

Enquanto o certificado auto-assinado do Windows possui os seguintes sinalizadores:

    X509v3 extensions:
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication
        X509v3 Key Usage: 
            Key Encipherment, Data Encipherment
    
por 04.01.2016 / 20:08
1

Eu não sei se você ainda precisa da resposta para esse problema, mas se alguém ainda precisar dele, você o terá.

Você realmente não precisa dos atributos especificados por você.

Seguindo os passos deste post, você terá sucesso na instalação de qualquer CRT (Wildcard ou Normal) em um computador / controlador de domínio.

Eu não testei sem o AD CS, mas acho que funciona.

A única coisa que você precisa fazer é converter o CRT / p7b para cer e, em seguida, para pfx (pkcs12) usando a chave e o pacote. Em seguida, importe-o manualmente para o seu sistema operacional.

link - este é o post.

link - aqui você pode encontrar como converter os certificados.

A propósito, você pode pular a parte do script WMI e usar o seguinte comando do powershell com direitos administrativos:

wmic /namespace:\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="YOUR-THUMBPRINT-GOES-HERE"

Funcionou para mim no Windows Server 2016 / Windows 10.

Espero que ajude! :)

    
por 18.04.2017 / 20:05