Os navegadores Chromium TLS1.2 falham com o certificado emitido pelo ADCS no Server 2012 R2

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:

1. 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?
2. O que preciso definir para permitir que o Server 2012 R2 use certificados emitidos internamente?
3. 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!