tl; dr: TLS 1.2 entre o Server 2012 R2 e navegadores baseados em Chromium falha ao usar certificados emitidos pelo AD CS. Funciona bem no Server 2016+ e no 2012 R2 com Firefox/IE/Cygwin-curl.
Temos vários servidores Web Server 2012 R2 internos que estamos tentando migrar de certificados emitidos publicamente para aqueles emitidos por nossa CA integrada ao AD e eliminar configurações de criptografia menos seguras, incluindo CBC MAC. O Server 2012 R2 não oferece suporte a ECDHE_RSA com GCM, o que significa que estamos tentando usar um certificado baseado em ECDH. No entanto, enfrentamos um problema semelhante quando permitimos conjuntos de criptografia com CBC-MAC, como TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 com um certificado RSA emitido pela mesma CA. Usando nosso certificado curinga público emitido pela GlobalSign, podemos nos conectar com todos os navegadores.
A autoridade de certificação corporativa e a autoridade de certificação raiz offline são confiáveis e verificamos que isso está funcionando corretamente. Os certificados que usam vários modelos diferentes emitidos para servidores de 2016 e 2019 funcionam sem problemas em todos os navegadores. Os modelos baseados em ECDH e RSA funcionam igualmente bem em 2016+.
Criptografia do modelo de certificado ECDH:
Criptografia do modelo de certificado RSA:
Os certificados RSA e ECDH nos servidores 2012 R2 são aceitos pelo Firefox (uma vez que tenha sido informado para confiar neles por meio de política e configuração manual security.enterprise_roots.enabled), pré-Chromium Edge, IE e Cygwin curle wget. Confirmei que estamos usando cifras modernas no registro, redefinindo-as com IISCrypto e verifiquei se há cifras compatíveis disponíveis oferecidas pelo servidor com OpenSSL e nmap. Da mesma forma, confirmei que os clientes são realmente capazes de se conectar usando essas cifras.
O Firefox mostra que está se conectando com TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, que de acordo com Qualys é compatível com a versão do Chrome que estamos usando.
Com o ECDH
PORT STATE SERVICE
443/tcp open https
| ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Cada vez que tentamos conectar com o Chrome, um par de eventos 36874/36888 é registrado informando que não havia conjuntos de cifras compatíveis no cliente.
Uma lista dos conjuntos de cifras com os quais enfrentamos o problema ao usar um certificado emitido pela CA Enterprise, a maioria dos quais foi habilitada apenas para teste (avisos recortados):
PORT STATE SERVICE
443/tcp open https
| ciphers:
| SSLv3:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
|_ least strength: C
Minhas perguntas são:
- Por que os navegadores baseados em Chromium não conseguem negociar um conjunto de cifras quando existem conjuntos de cifras compatíveis oferecidos pelo servidor?
- O que preciso definir para permitir que o Server 2012 R2 use certificados emitidos internamente?
- Existe uma maneira melhor de lidar com o que estou tentando fazer, além de atualizar os servidores de aplicativos para 2016/2019? Neste ponto, parece que desabilitar completamente o TLS e colocar tudo atrás de um proxy LB/reverso pode ser uma ideia melhor, mesmo que sejam soluções de servidor único.
EDIT: Abri um bug com o Chromium e eles confirmaram que os conjuntos de cifras oferecidos pelo servidor devem ser aceitos pelo Chrome. Eles agora estão investigando depois que eu forneci o log de rede capturado via CHROME://Net-Export. Isso pode estar relacionado a um bug antigo do Chrome/2012 . Assim que o Google informar qual é o problema, atualizarei esta postagem novamente. No entanto, neste ponto, parece que não há nada de errado com a configuração do nosso lado.
Obrigado por olhar!
