Certificado X.509 dando erro no Chrome, funciona no Firefox

Dado o OID .1.3.6.1.4.1.1.11129.2.4.2, descobri um artigo relevante do Let's Encrypt Engenharia profunda: codificação de SCTs em certificados

A Let's Encrypt lançou recentemente a incorporação SCT em certificados. Esse recurso permite que os navegadores verifiquem se um certificado foi enviado a um log de transparência de certificados.

Comecei a fazer algumas investigações sobre o assunto e acabei descobrindo que o Google tornou obrigatória a Transparência de Certificados no Chrome para todos os tipos de certificados X.509 a partir de 1º de maio de 2018.

Da aplicação de transparência de certificados no Google Chrome

Este aviso está sendo enviado a todos os operadores de CA conhecidos no Common CA Database [1] e se aplica a CAs que são atualmente, ou podem ser no futuro, confiáveis ​​em plataformas nas quais o Chrome opera (Mozilla NSS, Microsoft Windows, Apple iOS/ macOS, Google ChromeOS e Android).

Estamos escrevendo para reiterar a aplicação da Transparência de Certificados (CT) em abril de 2018 no Chrome. Como foi anunciado pela primeira vez [2] no Fórum CA/B, seguido por anúncios [3] no fórum mozilla.dev.security.policy, e posteriormente atualizado [4] no fórum ct-policy referenciado, o Chrome começará a impor que todos os certificados TLS emitidos após abril de 2018 estão em conformidade com a Política do Chromium CT [5] para serem confiáveis.

Desde janeiro de 2015, o Chrome exige que os certificados de validação estendida (EV) sejam compatíveis com CT para receber o status de EV. Em abril de 2018, esse requisito será estendido a todos os certificados confiáveis ​​publicamente emitidos recentemente - DV, OV e EV - e os certificados que não estiverem em conformidade com esta política não serão reconhecidos como confiáveis ​​quando avaliados pelo Chrome. Os certificados emitidos por CAs confiáveis ​​localmente ou corporativas que são adicionados por usuários ou administradores não estão sujeitos a esse requisito.

O que está acontecendo e quando?

O Chrome exigirá que todos os certificados de servidor TLS emitidos após 30 de abril de 2018 estejam em conformidade com a Política do Chromium CT. Após essa data, quando o Chrome se conectar a um site que atende a um certificado publicamente confiável que não está em conformidade com a Política do Chromium CT, os usuários começarão a ver um intersticial de página inteira indicando que sua conexão não é compatível com CT. Os sub-recursos veiculados em conexões https que não são compatíveis com CT não serão carregados e mostrarão um erro no Chrome DevTools. As CAs são fortemente encorajadas a trabalhar com seus clientes para garantir que seus certificados TLS estejam prontos para cumprir a Política do Chromium CT por qualquer um dos três meios especificados na RFC 6962 Seção 3.3 [6] antes do final de março para garantir que quaisquer problemas com a implantação Os apoios do CT são resolvidos antes do prazo de execução.

Para atender às necessidades exclusivas de determinadas empresas, haverá políticas do Chrome para desativar a aplicação de CT em dispositivos gerenciados e para usuários gerenciados que fizeram login no Chrome em seus dispositivos pessoais. Além da capacidade existente de desativar a aplicação de CT por URL [7], o Chrome adicionará uma política que permite que as organizações desativem a aplicação de CT para CAs que emitem apenas certificados para essa organização.

Do Chrome requer CT após abril de 2018

O Chrome exigirá que todos os certificados de servidor TLS emitidos após 30 de abril de 2018 estejam em conformidade com a Política do Chromium CT.” Isso significa que os certificados SSL/TLS devem ser qualificados para CT atendendo a um dos seguintes critérios:

• Um carimbo de data/hora de certificado assinado (SCT) de um log qualificado no momento da verificação é apresentado por meio da extensão TLS OU é incorporado a uma resposta OCSP grampeada, onde há pelo menos um SCT de um log do Google, qualificado no momento da verificação e pelo menos um SCT de um registro que não seja do Google, qualificado no momento da verificação.

• É apresentada uma SCT incorporada de um registro qualificado no momento da verificação, onde há pelo menos uma SCT incorporada de um registro do Google, pelo menos uma SCT incorporada de um registro que não seja do Google e há o número mínimo de SCTs incorporados.

Então , da Transparência de Certificados, uma introdução

Carimbo de data e hora do certificado assinado

Os certificados normalmente serão enviados aos logs de CT pela CA que os emitiu, mas também é possível que um proprietário do site envie seus próprios certificados para um log. Um SCT é a resposta de um log de certificado quando você envia um certificado que é essencialmente uma promessa de que o certificado será adicionado ao log em um determinado período de tempo. É esse SCT que temos que entregar aos clientes quando eles fazem uma conexão TLS com nosso site e existem 3 maneiras de fazer isso.

Extensão x.509v3

O método preferencial para entregar um SCT para um operador de site é por meio de uma extensão X.509v3. Isso significa que sua CA incorporará o SCT em seu certificado antes de assiná-lo e emiti-lo para você, para que nenhum trabalho ou configuração seja necessário de sua parte. A CA construirá seu certificado e antes da última etapa de assiná-lo, eles o enviarão ao log do CT como um pré-certificado. O log responderá com o SCT para o pré-certificado, a CA o incorporará no certificado e o assinará, pronto para emissão para você.

Extensão TLS

O SCT também pode ser entregue por meio de uma extensão TLS do host para o cliente conectado. Isso ocorre durante o handshake TLS usando uma extensão chamada signature_certificate_timestamp, mas exige que o host atualize seu servidor e o configure para entregar o SCT. O benefício aqui é para a CA, que não precisa alterar a forma como emite certificados , mas esperar por implementações de servidor confiáveis ​​da extensão SCT TLS pode não ser ótimo para os operadores do site.

Grampeamento OCSP

Sou fã do OCSP Stapling e geralmente é usado para entregar informações de revogação sobre nosso certificado, mas também pode ser usado para entregar o SCT da CA para o operador do site. Há um benefício para o CA novamente, pois eles não precisam alterar seu processo de emissão, eles simplesmente assinam e emitem o certificado normalmente e disponibilizam o SCT via OCSP. Novamente, porém, isso é um problema para nós, pois nosso servidor precisa ser capaz de OCSP Staple de forma confiável e incluir o SCT no cliente durante o handshake.

Então, sobre meus dois sites, um (exemplo: www.digicert.com ) está tendo as extensões SCT X.509 diretamente no certificado e não precisa de modificações de configuração no lado do servidor.

No outro site (exemplo: multicert.com), o operador da CA opta por usar o grampeamento X.509 e, como tal, o servidor web Apache precisa de alterações de configuração.

Também localizei um artigo na Digicert sobre grampeamento OCSP para Apache

Então, para obter o site com trabalho de grampeamento OSCP, preciso:

• tem uma versão do Apache maior que 2.3.3

• a VM tendo comunicação com o servidor CA OCSP

• adicionando ao vhost:

  Fora da diretiva <virtualhost...>

   SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
  

  Dentro da diretiva <virtualhost...>

   SSLUseStapling on
  

  E reinicie o Apache.

Após essas alterações no site com o certificado X.509 emitido pela Multicert, o Chrome está dizendo que os certificados são válidos em ambos os sites.

Consulte também o Chrome Linux não está mostrando uma extensão X.509, SCT

Mais detalhes técnicos

Também me perguntaram como foi imposto o limite de tempo de 1º de maio de 2018 e o que estaria acontecendo com os certificados antigos. Na falta de detalhes mais palpáveis ​​online, baixei a fonte do Chromium de https://chromium.googlesource.com/chromium/src/ com o comando:

git clone https://chromium.googlesource.com/chromium/src 

Para aqueles interessantes na funcionalidade de Transparência de Certificados, o diretório mais interessante parece ser components/certificate_transparency/e o arquivo doc mais interessantenet/docs/certificate-transparency.md

Excertos interessantes denet/docs/certificate-transparency.md

Visão geral

Certificate Transparency (CT) é um protocolo projetado para corrigir várias falhas estruturais no ecossistema de certificados SSL/TLS. Descrito na RFC 6962 , ele fornece uma estrutura de dados pública, somente anexada, que pode registrar certificados emitidos por autoridades de certificação (CAs). Ao registrar certificados, torna-se possível para o público ver quais certificados foram emitidos por uma determinada CA. Isso permite que os operadores do site detectem quando um certificado foi emitido para seus domínios, permitindo que verifiquem a emissão não autorizada. Ele também permite que navegadores e armazenamentos de raiz, e a comunidade em geral, examinem os certificados que uma CA emitiu e garantam que a CA esteja em conformidade com suas práticas esperadas ou divulgadas.

Fundamentos

Dizemos que um certificado suporta Transparência de Certificado se vier com informações de CT que demonstrem que foi registrado em vários logs de CT. Essas informações de CT devem estar em conformidade com a política de transparência do certificado no Chrome . Às vezes, nos referimos a um site que "suporta" o CT como usando um certificado que é "qualificado para CT" ou "divulgado via CT".

Políticas do Chrome

O Chrome exigiu gradualmente a transparência do certificado para certificados cada vez mais confiáveis ​​publicamente nos últimos anos.

• Desde 1º de janeiro de 2015 , o Chrome exige que todos os certificados de validação estendida sejam divulgados por meio da transparência do certificado. Os certificados que não fossem divulgados adequadamente perderiam seu status de EV , mas nenhum aviso seria mostrado aos visitantes de sites que não estivessem em conformidade.

• Desde 1º de junho de 2016 , o Chrome exige que todos os novos certificados emitidos pelo conjunto de certificados raiz de propriedade da Symantec Corporation sejam divulgados por meio da Transparência de certificados. Os certificados que não foram divulgados, ou que não foram divulgados de forma consistente com a RFC 6962, seriam rejeitados como não confiáveis.

• Para todos os novos certificados emitidos após 30 de abril de 2018, o Chrome exigirá que o certificado seja divulgado por meio da Transparência do certificado . Se um certificado for emitido após essa data e nem o certificado nem o site suportarem CT, esses certificados serão rejeitados como não confiáveis ​​e a conexão será bloqueada. No caso de um carregamento de página principal, o usuário verá uma página de aviso de certificado de página inteira, com o código de erro net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. Se você receber esse erro, isso indica que sua CA não executou as etapas para garantir que seu certificado seja compatível com CT e você deve entrar em contato com a equipe de vendas ou suporte da CA para garantir que possa obter um certificado substituto que funcione.

Privacidade do domínio

Apoiar o CT divulgando o certificado a um CT Log significa que todo o conteúdo do certificado estará acessível e visível publicamente. Em particular, isso significa que os domínios para os quais um certificado se destina serão incluídos no log de Transparência do Certificado, bem como a organização à qual estão afiliados, se forem validados para um nível superior à Validação de Domínio ou emitidos por uma CA específica da organização .

Nota: Curiosamente, o RFC 6292 é definido como experimental

Quanto à data de início de 1º de maio de 2018, existem instâncias codificadas específicas no código do Chromium (que é comum ao Chrome), definindo a data limite que estará presente no código do Chrome/Chromium na transição anos. Então isso explica o comportamento diferente na emissão de certificados antes de 1º de maio de 2018.

De services/network/network_context.cc:

1525         // For old certificates (issued before 2018-05-01),
1526         // CheckCTRequirements() may return CT_NOT_REQUIRED, so we check the
1527         // compliance status here.
1528         // TODO(https://crbug.com/851778): Remove this condition once we require
1529         // signing certificates to have CanSignHttpExchanges extension, because
1530         // such certificates should be naturally after 2018-05-01.
1531         if (ct_verify_result.policy_compliance ==
1532                 net::ct::CTPolicyCompliance::CT_POLICY_COMPLIES_VIA_SCTS ||
1533             ct_verify_result.policy_compliance ==
1534                 net::ct::CTPolicyCompliance::CT_POLICY_BUILD_NOT_TIMELY) {
1535           ct_verify_result.policy_compliance_required = true;
1536           break;
1537         }

De components/certificate_transparency/chrome_ct_policy_enforcer.cc:

217   // ... AND there is at least one embedded SCT from a Google Log once or
218   //   currently qualified;
219   // AND there is at least one embedded SCT from a non-Google Log once or
220   //   currently qualified;
221   // ...
222   //
223   // Note: This policy language is only enforced after the below issuance
224   // date, as that's when the diversity policy first came into effect for
225   // SCTs embedded in certificates.
226   // The date when diverse SCTs requirement is effective from.
227   // 2015-07-01 00:00:00 UTC.
228   const base::Time kDiverseSCTRequirementStartDate =
229       base::Time::UnixEpoch() + base::TimeDelta::FromSeconds(1435708800);
230   if (issuance_date >= kDiverseSCTRequirementStartDate &&
231       !(has_embedded_google_sct && has_embedded_nongoogle_sct)) {
232     // Note: This also covers the case for non-embedded SCTs, as it's only
233     // possible to reach here if both sets are not diverse enough.
234     return CTPolicyCompliance::CT_POLICY_NOT_DIVERSE_SCTS;
235   }

Adendos: baseado em algo que descobri depois de fazer esta investigação, e que está detalhado em: Chrome Linux não está mostrando uma extensão X.509, SCT

Extensão SCT para https://www.digicert.com

Definição OCSP para https://www.multicert.com