O Windows 7 pode acessar um farm de RD que usa certificados SHA512 / 4096 bits?

1

Eu tenho um farm Server 2012 RD que funciona bem se configurado com os certificados autoassinados gerados pelo Gerenciador do Servidor, mas não com certificados de nossa autoridade de certificação interna.

Com os certificados auto-assinados, nossos clientes remotos podem se conectar, mas obviamente recebem avisos de segurança devido aos certificados não confiáveis. Os clientes confiam em nossa CA raiz, portanto, devemos eliminá-los usando certificados de nossa CA interna.

No entanto, quando eu configuro o farm para usar certificados de nossa autoridade de certificação interna (que executa o AD CS no Server 2008 R2), os clientes podem fazer logon no site da RD, mas não podem abrir sessões RDP. Eles obtêm erros como o seguinte no Windows 7 (nenhum dos clientes é mais novo que 7, então eu não tentei 8):

Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance.

ou

Your computer can't connect to the remote computer because the Remote Desktop Gateway and the remote computer are unable to exchange policies. This could happen due to one of the following reasons:

  1. The remote computer is not capable of exchanging policies with the Remote Desktop Gateway.
  2. The remote computer's configuration does not permit a new connection.
  3. The connection between the Remote Desktop Gateway and the remote computer ended.

Contact your network administrator for assistance.

Por sua vez, estes aparecerão nos registros do servidor:

(Source: Schannel; Event ID: 36874) [sic] An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

(Source: Schannel; Event ID: 36888) A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

Nossa CA raiz e CA de emissão estão usando hashes SHA512 e chaves públicas de 4096 bits. Percebo que os certificados autoassinados do Gerenciador de Servidores que fazem funcionam usando chaves SHA256 e 2048 bits, por isso estou pensando se a criptografia mais strong não é suportada pelo RDP no Windows 7.

(Eu não posso testar isso facilmente, pois não posso fazer com que a CA distribua um certificado usando o SHA256, estou achando que a própria chave pública da CA é grande demais. Mesmo se tivesse, o cliente ainda precisaria SHA512 para validar a CA de emissão em relação à CA raiz.)

O mais estranho é que funciona com nossos certificados , exceto para "Agente de Conexão RD - Habilitar Single Sign On." Se eu deixar esse definido para o certificado auto-assinado, mas usar o nosso para os outros três, tudo funciona basicamente bem (além dos usuários terem que digitar sua senha três vezes).

Nesse caso, o Internet Explorer no cliente confia em um dos nossos certs sem problemas, embora tenha o SHA512. Isso faz parecer estranho que a criptografia mais strong atrapalhasse o RDP - eu teria assumido que ambos usariam um provedor integrado ao Windows.

    
por Kevin 04.11.2013 / 11:28

1 resposta

1

Tentativamente, parece-me que a resposta é: não, o Windows 7 não pode acessar um farm RD (pelo menos um Server 2012) se o certificado "Agente de Conexão RD - Habilitar Logon Único" estiver usando um certificado assinado usando um hash SHA512.

Eu configurei uma nova autoridade raiz e uma autoridade de emissão de uma maneira muito semelhante a como as existentes eram configuradas, exceto que eu fornecia chaves de 2048 bits e hashes SHA256. Eu apliquei um certificado dessa nova autoridade de emissão como o certificado "Agente de Conexão de Área de Trabalho Remota - Ativar Logon Único" e o problema desapareceu.

A única diferença real nas configurações da CA além da força da criptografia foi que a nova autoridade de emissão foi configurada no Server 2012 em vez do Server 2008 R2, mas espero que isso não faça nenhuma diferença .

Ainda gostaria de receber uma resposta mais definitiva.

    
por 06.11.2013 / 04:59