Perguntas frequentes sobre a migração da CA raiz da Plataforma Google Maps

Este documento contém as seguintes seções:

Para uma visão geral mais detalhada sobre a migração em andamento da CA raiz do Google, consulte O que está acontecendo?.

Terminologia

Veja abaixo uma lista com os termos mais importantes que você precisa conhecer para acompanhar este documento. Se quiser uma visão geral mais abrangente da terminologia relacionada, consulte as Perguntas frequentes sobre o Google Trust Services.

Certificado SSL/TLS
Um certificado vincula uma chave criptográfica a uma identidade.
Os certificados SSL/TLS são usados para autenticar e estabelecer conexões seguras com sites. Eles são emitidos e assinados criptograficamente por entidades conhecidas como autoridades certificadoras.
Os navegadores precisam de certificados emitidos por autoridades certificadoras confiáveis para saber se as informações transmitidas são enviadas ao servidor correto e criptografadas durante o processo.
Secure Sockets Layer (SSL)
O Secure Sockets Layer foi o protocolo mais amplamente implantado para criptografar comunicações pela Internet. O protocolo SSL não é mais considerado seguro e não deve ser usado.
Transport Layer Security (TLS)
O Transport Layer Security é o sucessor do SSL.
Autoridade de certificação (CA)
Uma autoridade de certificação é como um órgão emissor de passaportes digital para dispositivos e pessoas. Ela emite documentos protegidos por criptografia (certificados) para verificar se uma entidade (por exemplo, um site) é quem afirma ser.
Antes de emitir um certificado, as autoridades certificadoras (CAs, na sigla em inglês) confirmam se os nomes no certificado estão vinculados à pessoa ou entidade que o pediu.
O termo "Autoridade certificadora" pode se referir a organizações como o Google Trust Services e a sistemas que emitem certificados.
Repositório de certificados raiz
Um repositório de certificados raiz inclui um conjunto de autoridades certificadoras em que um fornecedor de software de aplicativo confia. A maioria dos navegadores da Web e sistemas operacionais têm o próprio repositório de certificados raiz.
Para ser incluída em um repositório, a autoridade certificadora precisa cumprir requisitos rigorosos estabelecidos pelo fornecedor de software de aplicativo.
Normalmente, isso inclui conformidade com padrões do setor, como os requisitos da CA/do fórum do navegador.
Autoridade certificadora raiz
Uma autoridade certificadora raiz, ou melhor, o certificado que ela fornece é o mais confiável em uma cadeia de certificados.
Os certificados de CA raiz geralmente são autoassinados. As chaves privadas associadas a eles são armazenadas em instalações altamente seguras e mantidas em um estado off-line para protegê-las contra acesso não autorizado.
Autoridade de certificação intermediária
Uma autoridade de certificação intermediária, ou melhor, o certificado que ela oferece, é usado para assinar outros certificados em uma cadeia.
As CAs intermediárias existem principalmente para possibilitar a emissão de certificados on-line, permitindo que o certificado de CA raiz permaneça off-line.
As CAs intermediárias também são conhecidas como CAs subordinadas.
Autoridade de certificação emissora
Uma autoridade certificadora emissora, ou melhor, o certificado que ela oferece, é usado para assinar um outro de nível mais baixo em uma cadeia de certificados.
Esse é chamado de certificado de assinante ou de entidade final ou secundário. Neste documento, também usamos o termo certificado do servidor.
Cadeia de certificados
Os certificados são vinculados ao emissor por uma assinatura criptográfica. Uma cadeia de certificados é composta por um certificado de folha, todos os certificados do emissor e um certificado raiz.
Assinatura cruzada
Os clientes dos fornecedores de software de aplicativo precisam atualizar o repositório de certificados raiz para incluir novos certificados de CA que sejam considerados confiáveis pelos produtos deles. Leva algum tempo até que os produtos que contêm os novos certificados de CA sejam amplamente utilizados.
Para aumentar a compatibilidade com clientes mais antigos, os certificados de CA podem ter "assinatura cruzada" com outra CA mais antiga. Isso cria efetivamente um segundo certificado de CA para a mesma identidade (nome e par de chaves).
Dependendo das CAs incluídas no repositório de certificados raiz, os clientes vão criar outra cadeia até uma raiz em que confiam.

Informações gerais

O que está acontecendo?

Visão geral

Em 2017, o Google começou um projeto de vários anos para emitir e usar os próprios certificados raiz, ou seja, assinaturas criptográficas que são a base da segurança TLS de Internet utilizada pelo HTTPS.

Após a primeira fase, a segurança TLS dos serviços da Plataforma Google Maps foi assegurada pela GS Root R2, uma CA raiz conhecida e bastante confiável. Ela pertencia à GMO GlobalSign e foi adquirida pelo Google para facilitar a transição para nossas CAs raiz próprias autoassinadas do GTS.

Praticamente todos os clientes TLS (como navegadores da Web, smartphones e servidores de apps) já confiavam nesse certificado raiz e, portanto, conseguiram estabelecer uma conexão segura com os servidores da Plataforma Google Maps durante a primeira fase da migração.

No entanto, uma CA não pode emitir por padrão certificados válidos além do prazo de validade do próprio certificado. Quando o GS Root R2 expirar em 15 de dezembro de 2021, o Google vai migrar os próprios serviços para uma nova CA, a GTS Root R1 Cross, usando um certificado emitido pela própria CA raiz do Google, o GTS Root R1.

A maioria dos sistemas operacionais modernos e das bibliotecas de cliente TLS já confia nas CAs raiz do GTS, o que garante uma transição tranquila para grande parte dos sistemas legados, e o Google adquiriu uma assinatura cruzada da GMO GlobalSign usando a GlobalSign Root CA - R1, uma das CAs raiz mais antigas e confiáveis.

Portanto, a maioria dos clientes da Plataforma Google Maps já reconhecem uma ou ambas as CAs raiz confiáveis e não devem ser afetados pela segunda fase da migração.

Isso também é válido para os clientes que tomaram medidas durante a primeira fase da migração em 2018, desde que tenham seguido nossas instruções de instalar todos os certificados do pacote de CAs raiz confiáveis do Google.

Verifique seus sistemas, se alguma das ações a seguir for verdadeira:

  • Seus serviços executam plataformas não padrão ou legadas e/ou você mantém seu próprio repositório de certificados raiz.
  • Você não tomou nenhuma medida em 2017 e 2018, durante a primeira fase da migração da CA raiz do Google, ou não instalou o conjunto completo de certificados do pacote de CAs raiz confiáveis do Google.

Se as informações acima forem verdadeiras, seus clientes vão precisar ser atualizados com os certificados raiz recomendados para garantir o uso ininterrupto da Plataforma Google Maps durante essa fase da migração.

Veja mais detalhes técnicos abaixo. Para instruções gerais, consulte a seção Como verificar se meu repositório de certificados raiz precisa ser atualizado.

Também recomendamos manter os repositórios de certificados raiz sincronizados com o pacote selecionado de CAs raiz acima. Assim, você prepara seus serviços para futuras mudanças na CA raiz. No entanto, elas serão anunciadas com antecedência. Consulte as seções Como receber atualizações sobre essa fase de migração? e Como receber avisos de migrações futuras com antecedência? para conferir mais detalhes sobre as notificações.

Resumo técnico

Como anunciado em 15 de março de 2021 no blog sobre segurança do Google (link em inglês), a GS Root R2, a CA raiz da Plataforma Google Maps usada desde o início de 2018, expirou em 15 de dezembro de 2021. Por isso, o Google está migrando para a CA GTS Root R1 Cross criada neste mesmo ano. Isso significa que nossos serviços estão sendo transferidos gradualmente para certificados TLS de folha emitidos por essa nova CA.

Quase todos os clientes e sistemas TLS modernos já estão pré-configurados com o certificado GTS Root R1 ou precisam receber esse documento com atualizações normais de software, e a GlobalSign Root CA - R1 precisa estar disponível mesmo em sistemas legados mais antigos.

No entanto, é necessário verificar os sistemas pelo menos se os dois pontos a seguir forem verdadeiros:

  • Seus serviços executam plataformas não padrão ou legadas e/ou você mantém seu próprio repositório de certificados raiz.
  • Você não tomou nenhuma medida em 2017 e 2018, durante a primeira fase da migração da CA raiz do Google, ou não instalou o conjunto completo de certificados do pacote de CAs raiz confiáveis do Google.

A seção Como verificar se meu repositório de certificados raiz precisa ser atualizado dá orientações gerais para testar se o sistema vai ser afetado.

Encontre mais detalhes na pergunta Por que é necessário manter meu repositório de certificados raiz sincronizado com o pacote de CAs raiz confiáveis do Google?

Como receber atualizações sobre esse processo de migração?

Marque o problema público 186840968 com uma estrela para receber atualizações sobre ele. As perguntas frequentes também vão ser atualizadas durante todo o processo de migração sempre que encontrarmos tópicos que podem ser de interesse geral.

Como receber avisos de migrações futuras com antecedência?

Sugerimos que você acompanhe o Blog de segurança do Google. Também faremos o possível para atualizar a documentação específica do produto com regularidade, seguindo o anúncio público no blog.

Faça também a inscrição para receber notificações da Plataforma Google Maps, já que postamos atualizações no fórum regularmente sobre mudanças que provavelmente vão afetar um número maior de clientes.

Usamos vários Serviços do Google. A migração da CA raiz afeta todos eles?

Sim, a migração da CA raiz ocorre em todos os Serviços e APIs do Google, mas o cronograma pode variar de acordo com o serviço. No entanto, se os certificados raiz usados pelos aplicativos cliente da Plataforma Google Maps tiverem todas as CAs listadas no pacote de CAs raiz confiáveis do Google, seus serviços não serão afetados pela migração. Além disso, manter tudo sincronizado também protege contra futuras mudanças na CA raiz.

Confira mais informações nas perguntas Por que é necessário manter meu repositório de certificados raiz sincronizado com o pacote de CAs raiz confiáveis do Google? e Quais tipos de aplicativo correm o risco de serem corrompidos?.

A seção Como verificar se meu repositório de certificados raiz precisa ser atualizado abaixo também mostra instruções gerais para testar o sistema.

Como verificar se meu repositório de certificados raiz precisa ser atualizado

Teste o ambiente do aplicativo nos endpoints de teste listados abaixo:

  • Se você conseguir estabelecer uma conexão TLS com o endpoint de teste da GTS Root R1 Cross, a expiração da GS Root R2 não vai afetar você.
  • Se for possível estabelecer uma conexão TLS com o endpoint de teste da GTS Root R1, seu aplicativo provavelmente ainda vai estar protegido contra a expiração da GTS Root R1 Cross e da GlobalSign Root CA – R1 em 2028.

Geralmente, seu sistema será compatível com essa alteração da CA raiz se:

  • Seu serviço for executado em um sistema operacional conhecido e se você tiver mantido vinculados o sistema operacional e as bibliotecas que o serviço usa e não tiver um repositório próprio de certificados raiz ou
  • Você tiver seguido nossas recomendações anteriores e instalado todas as CAs raiz do pacote de CAs raiz confiáveis do Google

Os clientes possivelmente afetados precisam instalar imediatamente os certificados do pacote de CAs raiz confiáveis do Google para evitar interrupções futuras no serviço.

Encontre mais detalhes na pergunta Por que é necessário manter meu repositório de certificados raiz sincronizado com o pacote de CAs raiz confiáveis do Google?

Existe uma ferramenta simples para verificar o repositório de certificados raiz?

As duas ferramentas de linha de comando curl e openssl podem ser úteis nas suas investigações. Ambas estão disponíveis na maioria das plataformas e oferecem opções abrangentes para testar a configuração.

Consulte a seção Onde encontrar o curl para ver instruções sobre como gerar o curl.

Os comandos openssl mostrados abaixo são para a versão 1.1.1 ou mais recente. As versões anteriores à 1.1.1 não têm suporte. Se você estiver usando uma versão anterior, faça upgrade ou modifique esses comandos conforme necessário. Consulte a seção Receber o OpenSSL para instruções sobre como chamar o comando openssl.

Você também encontra mais ferramentas úteis na seção abaixo Onde posso encontrar as ferramentas necessárias?

Para instruções concretas sobre testes, consulte a seção Como verificar se meu repositório de certificados raiz precisa ser atualizado.

Como testar o repositório padrão de certificados raiz

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Verificar o pacote de CAs raiz confiáveis do Google

Faça o download do pacote de CAs raiz confiáveis do Google e siga estas etapas:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Como e quando a migração da CA raiz do Google continuará?

  1. A primeira fase (migração para o GS Root R2) foi anunciada em janeiro de 2017, iniciada no fim desse mesmo ano e concluída no primeiro semestre de 2018.
  2. A segunda fase (migração para a GTS Root R1 Cross) foi anunciada em março de 2021 e lançada antes da expiração do GS Root R2 em 15 de dezembro de 2021.

As programações das fases posteriores de migração serão anunciadas com bastante antecedência às datas de expiração dos certificados.

No entanto, você pode evitar que seus apps se tornem obsoletos no futuro. Basta manter o repositório de certificados raiz sincronizado com a lista selecionada de CAs raiz no pacote de CAs raiz confiáveis do Google.

Confira mais informações na pergunta Por que devo manter meus certificados raiz sincronizados com o pacote de CAs raiz confiáveis do Google?

Plano de lançamento geral de cada Serviço do Google

  1. O lançamento gradual começa em um único data center.
  2. O processo será estendido gradualmente a outros data centers até que haja cobertura global.
  3. Se ocorrerem problemas graves em qualquer fase, será possível reverter temporariamente os testes enquanto as falhas são resolvidas.
  4. Com base nos resultados das iterações anteriores, outros Serviços do Google vão ser incluídos no lançamento até que todos eles sejam migrados para os novos certificados.

Quem será afetado, quando e onde?

Um número cada vez maior de desenvolvedores da Plataforma Google Maps começará a receber os novos certificados à medida que novos data centers forem migrados. As mudanças vão ser localizadas, já que as solicitações do cliente tendem a ser encaminhadas para servidores em data centers geograficamente próximos.

Como não podemos garantir quem vai ser afetado, quando e onde, recomendamos que todos os nossos clientes já verifiquem e preparem os serviços antes das possíveis fases de migração de CAs raiz do Google.

Consulte a seção Como verificar se meu repositório de certificados raiz precisa ser atualizado para mais orientações.

O que procurar

Os clientes que não estiverem configurados com o certificado raiz necessário não podem confirmar a conexão TLS com a Plataforma Google Maps. Nessa situação, os clientes costumam emitir um aviso de que a validação do certificado falhou.

Dependendo da configuração do TLS, os clientes podem emitir uma nova solicitação para a Plataforma Google Maps ou não prosseguir com o processo.

Quais são os requisitos mínimos para um cliente TLS se comunicar com a Plataforma Google Maps?

Os certificados da Plataforma Google Maps usam nomes alternativos de entidades (SANs, na sigla em inglês) de DNS. Portanto, o processamento do certificado de um cliente precisa oferecer suporte a SANs que podem incluir um único caractere curinga na etiqueta mais à esquerda do nome, como *.googleapis.com.

Para outros requisitos, consulte a seção What are the recommended requirements for a TLS client to communicate with Google? (Quais são os requisitos recomendados para um cliente TLS se comunicar com o Google?) nas perguntas frequentes sobre o GTS (link em inglês).

Quais tipos de aplicativo correm o risco de serem corrompidos?

O aplicativo usa o repositório de certificados raiz do sistema sem restrições impostas pelo desenvolvedor.

Aplicativos de serviços da Web da Plataforma Google Maps

Se você estiver usando um sistema operacional conhecido (por exemplo, Ubuntu, Red Hat, Windows 10 ou Server 2019, OS X) que ainda tenha suporte e receba atualizações regulares, seu repositório de certificados raiz padrão já vai incluir o certificado GTS Root R1.

Se você estiver usando uma versão legada do SO que não recebe mais atualizações, é possível que você ainda não tenha o certificado GTS Root R1. No entanto, seu repositório de certificados raiz provavelmente vai incluir a GlobalSign Root CA - R1, uma das CAs raiz mais antigas e confiáveis.

Noos apps para dispositivos móveis que chamam serviços da Web da Plataforma Google Maps diretamente do dispositivo do usuário final, siga as diretrizes na pergunta Os apps para dispositivos móveis correm o risco de serem corrompidos?.

Aplicativos da Plataforma Google Maps do lado do cliente

Os aplicativos da API Maps JavaScript geralmente usam os certificados raiz do navegador da Web que executa o app. Consulte a seção Os aplicativos JavaScript correm o risco de serem corrompidos? para mais detalhes.

Em aplicativos nativos para dispositivos móveis que usam o SDK do Maps para Android, o SDK do Maps para iOS e o SDK do Places para Android ou iOS, as mesmas regras se aplicam aos apps que chamam os serviços da Web da Plataforma Google Maps.

Confira a pergunta Os apps para dispositivos móveis correm o risco de serem corrompidos? para mais detalhes.

O app usa o próprio pacote de certificados ou recursos avançados de segurança, como a fixação de certificados.

Você vai precisar atualizar o pacote de certificados por conta própria. Como abordado na pergunta Por que é necessário manter meu repositório de certificados raiz sincronizado com o pacote de CAs raiz confiáveis do Google?, recomendamos importar todos os certificados do pacote de CAs raiz confiáveis do Google para seu repositório.

Se você estiver fixando certificados ou chaves públicas para os domínios do Google a que o aplicativo está conectado, adicione esses itens à lista de entidades confiáveis no seu aplicativo.

Para mais detalhes sobre a fixação de certificados ou de chaves públicas, consulte os recursos externos listados na pergunta Precisa de mais informações?.

Por que é necessário manter meu repositório de certificados raiz sincronizado com o pacote de CAs raiz confiáveis do Google?

A lista selecionada de CAs raiz no pacote de CAs raiz confiáveis do Google inclui todas as CAs que podem ser usadas pelos Serviços do Google em um futuro próximo.

Portanto, se você quiser preparar seu sistema, verifique se o repositório de certificados raiz contém todos os certificados do pacote e mantenha ambos sincronizados.

Isso é ainda mais importante se os serviços são executados em uma versão do sistema operacional sem suporte, se não é possível implementar patches ao seu sistema operacional e às bibliotecas por outros motivos ou você mantém um repositório próprio de certificados raiz.

Confira a pergunta Como receber avisos de migrações futuras com antecedência? para saber como receber atualizações sobre futuras migrações da CA raiz. Manter a sincronia entre o repositório de certificados raiz e a lista selecionada vai proteger os serviços contra futuras interrupções devido a mudanças da CA e vai manter os serviços em execução após a expiração da GTS Root R1 Cross e da GlobalSign Root CA - R1.

Além disso, confira a pergunta I'm building a product that connects to Google services. What CA certificates do I need to trust? (Estou criando um produto que se conecta aos Serviços do Google. Quais certificados de CA são confiáveis?) nas perguntas frequentes sobre o GTS para mais recomendações (link em inglês).

Por que não instalar nenhum certificado de CA secundário ou intermediário?

Caso contrário, você vai correr o risco de corromper seu aplicativo quando inscrevermos um novo certificado ou mudarmos as CAs intermediárias. Isso pode acontecer a qualquer momento e sem aviso prévio e serve igualmente para certificados de servidor individuais (como os veiculados por maps.googleapis.com) e nossas CAs intermediárias (como a GTS Root R1 Cross).

Para proteger seus serviços contra esse problema, instale apenas certificados raiz do pacote de CAs raiz confiáveis do Google e use o certificado raiz sozinho para verificar a confiabilidade de toda a cadeia de certificados vinculados a ele.

Qualquer implementação de biblioteca TLS moderna pode verificar automaticamente essas cadeias, desde que a CA raiz seja confiável.

Os aplicativos JavaScript correm o risco de serem corrompidos?

Os certificados raiz do GTS já estão incorporados e são confiáveis para a maioria dos navegadores mais recentes. A assinatura cruzada do GMO GlobalSign garante uma migração tranquila, mesmo para os usuários finais em navegadores legados. Isso inclui todos os navegadores com suporte para API Maps JavaScript.

Todos os navegadores mais recentes permitem que os usuários finais verifiquem e editem quais certificados são confiáveis. Embora o local exato seja diferente com cada navegador, a lista de certificados normalmente pode ser encontrada em Configurações.

Os apps para dispositivos móveis correm o risco de serem corrompidos?

Os dispositivos Android e iOS da Apple que ainda recebem atualizações regulares do fabricante também precisam ser preparados para a migração do certificado. A maioria dos modelos de smartphones Android mais antigos inclui pelo menos o certificado da GlobalSign Root CA - R1, embora a lista de certificados confiáveis possa variar de acordo com o fabricante, o modelo do dispositivo e a versão do Android.

No entanto, o suporte para as CAs raiz do GTS, incluindo a GTS Root R1, ainda pode ser limitado em versões do Android anteriores à 10.

Para dispositivos iOS, a Apple disponibiliza uma lista de CAs raiz confiáveis para cada versão recente do iOS nas páginas de suporte. No entanto, todas as versões 5 e posteriores do iOS têm suporte para GlobalSign Root CA - R1.

As CAs raiz do GTS, incluindo a GTS Root R1, têm suporte a partir da versão 12.1.3 do iOS.

Consulte a seção Como verificar os certificados raiz confiáveis no meu smartphone? para mais detalhes.

Quando meu navegador ou sistema operacional vai incluir os certificados raiz do Google Trust Services?

Nos últimos anos, o Google trabalhou extensivamente com todos os principais terceiros para manter pacotes de certificados raiz amplamente utilizados e confiáveis. Por exemplo, fabricantes de sistemas operacionais, como Apple e Microsoft, além das nossas próprias equipes do Android e do ChromeOS do Google; desenvolvedores de navegadores, como Mozilla, Apple, Microsoft, além da nossa equipe do Chrome; e fabricantes de hardware, como smartphones, conversores, TVs, consoles de jogos, impressoras, entre outros.

Portanto, é muito provável que qualquer sistema atual já ofereça suporte para as novas CAs raiz do GTS do Google, incluindo a GTS Root R1. Até mesmo os sistemas legados têm maior probabilidade de oferecer suporte à GlobalSign Root CA - R1, que vai ser usada para assinar de forma cruzada os certificados emitidos pelo Google ao longo dos próximos anos.

Como o cronograma de inclusão de certificados de terceiros não fica sob controle do Google, faça regularmente as atualizações do sistema disponíveis.

Alguns terceiros, como o Programa de Certificados de CA do Mozilla, divulgaram os próprios cronogramas de inclusão de certificados.

Solução de problemas

Onde encontro as ferramentas necessárias?

Onde encontrar o curl

Se a sua distribuição do SO não oferecer curl, faça o download em https://curl.haxx.se/ (link em inglês). É possível fazer o download do código-fonte e compilar a ferramenta por conta própria ou de um binário pré-compilado, se houver um disponível para sua plataforma.

Receber o OpenSSL

Se a sua distribuição do SO não oferecer openssl, faça o download da origem em https://www.openssl.org/ e compile a ferramenta. Acesse https://www.openssl.org/community/binaries.html (ambos os links em inglês) para consultar a lista de binários criados por terceiros. É importante ressaltar que nenhuma dessas compilações recebe o suporte ou o endosso em qualquer nível da equipe do OpenSSL.

Onde encontrar Wireshark, Tshark ou Tcpdump

Embora a maioria das distribuições do Linux ofereça wireshark, a ferramenta de linha de comando relacionada tshark e tcpdump, as versões pré-compiladas das duas primeiras para outros SOs estão disponíveis em https://www.wireshark.org.

O código-fonte de Tcpdump e LibPCAP pode ser encontrado em https://www.tcpdump.org (ambos os links em inglês).

A documentação dessas ferramentas úteis está disponível em inglês no guia do usuário do Wireshark, na página do manual do Tshark e no manual do Tcpdump, respectivamente.

Receber um keytool do Java

A ferramenta de linha de comando keytool precisa ser enviada com todas as versões do Java Development Kit (JDK) ou do Java Runtime Environment (JRE). Instale essas versões para receber keytool. O uso de keytool, por sua vez, provavelmente não vai ser necessário para a verificação do certificado raiz, a menos que seu aplicativo seja criado usando Java.

O que fazer em caso de falha temporária na produção?

A recomendação principal é instalar os certificados raiz necessários do pacote de CAs raiz confiáveis do Google no repositório de certificados raiz que o aplicativo usa.

  1. Trabalhe em conjunto com os administradores do sistema para fazer upgrade do repositório local de certificados raiz.
  2. Consulte estas perguntas frequentes para ver as opções relevantes para seu sistema.
  3. Se você precisar de uma ajuda mais específica para a plataforma ou o sistema, entre em contato com os canais de suporte técnico oferecidos pelo provedor do sistema.
  4. Para orientações gerais, fale com nossa equipe de suporte, conforme descrito na seção Entrar em contato com o suporte da Plataforma Google Maps. Observação: se o problema for específico da plataforma, a equipe fará o possível para ajudar.
  5. Marque o problema público 186840968 com uma estrela para receber atualizações sobre a migração.

Entrar em contato com o suporte da Plataforma Google Maps

Solução de problemas inicial

Consulte a seção Como verificar se meu repositório de certificados raiz precisa ser atualizado para saber como resolver problemas.

A seção Gerenciar certificados confiáveis também traz informações úteis caso você precise importar ou exportar certificados raiz.

Se o problema não for resolvido e você entrar em contato com o suporte da Plataforma Google Maps, tenha em mãos as seguintes informações:

  1. Onde estão localizados os servidores afetados?
  2. Quais endereços IP do Google seu serviço está chamando?
  3. Quais APIs foram afetadas por esse problema?
  4. Quando exatamente o problema começou?

  5. Saídas dos seguintes comandos:

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Confira a pergunta Onde encontro as ferramentas necessárias? para mais instruções.

Registrar um caso de suporte

Siga as instruções na seção Criar um caso de suporte do artigo Suporte e recursos da Plataforma Google Maps.

Ao entrar em contato com o suporte, além dos dados listados na seção Solução de problemas inicial, informe também o seguinte:

  • Quais são seus endereços IP públicos?
  • Qual é o endereço IP público do seu servidor DNS?
  • Se possível, uma captura de pacote tcpdump ou Wireshark da negociação de TLS que apresentou a falha com https://maps.googleapis.com/ no formato PCAP, com um tamanho de snapshot grande o suficiente para capturar todo o pacote sem truncar (por exemplo, usando -s0 em versões mais antigas de tcpdump).
  • Se possível, trechos dos registros do serviço mostrando o motivo exato da falha de conexão de TLS, de preferência com informações completas da cadeia de certificados do servidor.

Confira a pergunta Onde encontro as ferramentas necessárias? para mais instruções.

Postar no problema público 186840968

Ao postar um comentário no problema público 186840968, inclua as informações listadas na seção Solução de problemas inicial.

Como determinar o endereço público do meu DNS?

No Linux, execute o comando a seguir:

dig -t txt o-o.myaddr.l.google.com

No Windows, é possível usar o nslookup no modo interativo:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Como interpretar a saída do curl

Você consegue informações muito úteis ao executar curl com as sinalizações -vvI. Veja a seguir algumas instruções para interpretar a saída:

  • As linhas que começam com "*" mostram a saída da negociação de TLS, além das informações sobre encerramento da conexão.
  • As linhas que começam com > mostram a solicitação HTTP de saída enviada por curl.
  • As linhas que começam com "<" mostram a resposta HTTP recebida do servidor.
  • Se o protocolo era HTTPS, a presença de linhas ">" ou "<" sugere que um handshake de TLS foi processado.

Biblioteca TLS e pacote de certificados raiz usados

Quando você executa curl com as sinalizações -vvI, também imprime o repositório de certificados usado, mas a saída exata varia de acordo com o sistema, conforme mostrado abaixo.

O resultado gerado por uma máquina Red Hat Linux com curl vinculada ao NSS pode conter estas linhas:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

A saída gerada por uma máquina Ubuntu ou Debian Linux pode conter estas linhas:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

A saída gerada por uma máquina Ubuntu ou Debian Linux usando o arquivo PEM do certificado raiz do Google oferecido pela sinalização --cacert pode conter estas linhas:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

User agent

As solicitações de resultados incluem o cabeçalho user agent que pode enviar informações úteis sobre curl e seu sistema.

Um exemplo de uma máquina Red Hat Linux:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Falha no handshake de TLS

As linhas, como as deste exemplo de código, indicam que a conexão foi encerrada no meio do handshake de TLS devido a um certificado de servidor não confiável. A ausência da saída de depuração começando com > ou < também são fortes indicadores de uma tentativa de conexão malsucedida:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

Handshake de TLS bem-sucedido

Um handshake de TLS bem-sucedido é indicado pela presença de linhas de aparência semelhante ao exemplo de código abaixo. O pacote de criptografia usado para a conexão precisa ser listado, assim como os detalhes do certificado de servidor aceito. Além disso, a presença de linhas que começam com > ou < indica que o tráfego HTTP de payload está sendo transmitido pela conexão criptografada por TLS:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

Como imprimir os certificados de servidor recebidos em um formato legível

Presumindo que a saída use o formato PEM (por exemplo, a saída de openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null), é possível imprimir o certificado mostrado seguindo as etapas abaixo:

  • Copie todo o certificado codificado em Base 64, incluindo o cabeçalho e o rodapé:

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • Depois, faça o seguinte:

    openssl x509 -inform pem -noout -text
````

  • Cole o conteúdo do buffer de cópia no terminal.

  • Pressione a tecla Enter.

Para exemplo de entrada e a saída, consulte a seção Como imprimir certificados PEM em formato legível.

Como é a aparência dos certificados do Google de assinatura cruzada no OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

Gerenciar seus certificados confiáveis

Como posso verificar os certificados raiz confiáveis no meu smartphone?

Certificados confiáveis do Android

Como mencionado na pergunta Os apps para dispositivos móveis correm o risco de serem corrompidos?, a partir da versão 4.0, o Android permite que os usuários de dispositivos móveis verifiquem a lista de certificados confiáveis em Configurações. Esta tabela mostra o caminho exato do menu Configurações:

Versão do Android Caminho do menu
1.x, 2.x, 3.x N/A
4.x, 5.x, 6.x, 7.x Configurações > Segurança > Credenciais confiáveis
8.x, 9 Configurações > Segurança e local > Criptografia e credenciais > Credenciais confiáveis
10+ Configurações > Segurança > Avançado > Criptografia e credenciais > Credenciais confiáveis

A tabela abaixo mostra a provável disponibilidade dos certificados raiz mais essenciais por versão do Android, com base na verificação manual usando imagens do sistema do Dispositivo virtual Android (AVD, na sigla em inglês) disponíveis, recorrendo ao histórico de versões do repositório Git de certificados de CA (link em inglês) do AOSP sempre que as imagens não estão mais disponíveis:

Versão do Android GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (válido até 15 de dezembro de 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Normalmente, não é possível atualizar o repositório de certificados raiz do sistema Android sem uma atualização de firmware ou com acesso root ao dispositivo. No entanto, na maioria das versões do Android que ainda são bastante usadas, o conjunto atual de certificados raiz confiáveis provavelmente vai oferecer serviço ininterrupto por vários anos, excedendo a vida útil de grande parte dos dispositivos atuais.

A partir da versão 7.0, o Android oferece aos desenvolvedores de aplicativos um método seguro para adicionar certificados confiáveis que só são usados pelos respectivos apps. Isso é feito com o agrupamento dos certificados usando o aplicativo e a criação de uma configuração de segurança de rede personalizada, como descrito no documento de treinamento Configuração de segurança de rede, com as práticas recomendadas do Android para segurança e privacidade.

No entanto, como os desenvolvedores de aplicativos terceirizados não podem influenciar a configuração de segurança de rede do tráfego que vem do APK do Google Play Services, essas ações provavelmente serviriam somente como uma solução parcial.

Em dispositivos legados mais antigos, a única opção disponível seria usar CAs adicionadas pelo usuário final ou instaladas por uma política de grupo corporativo implementada no dispositivo.

Loja de confiança do iOS

Embora a Apple não mostre diretamente o conjunto padrão de certificados raiz confiáveis ao usuário do smartphone, a empresa tem links que levam aos conjuntos de CAs raiz confiáveis para a versão 5 do iOS e outras mais recentes nos artigos de suporte da Apple:

No entanto, qualquer outro certificado instalado no dispositivo iOS fica visível em Ajustes > Geral > Perfil. Se nenhum outro certificado for instalado, o item de menu Perfil não vai aparecer.

Esta tabela mostra a disponibilidade dos certificados raiz mais essenciais por versão do iOS, com base nas fontes acima:

Versão do iOS GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (válido até 15 de dezembro de 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Onde meus certificados raiz do sistema são armazenados e Como fazer a atualização deles?

O local do repositório padrão de certificados raiz varia de acordo com o sistema operacional e a biblioteca SSL/TLS usada. No entanto, na maioria das distribuições Linux, os certificados raiz padrão podem ser encontrados em um dos seguintes caminhos:

  • /usr/local/share/ca-certificates: versões do Debian, Ubuntu, além de versões mais antigas do RHEL e CentOS
  • /etc/pki/ca-trust/source/anchors e /usr/share/pki/ca-trust-source: Fedora, versões mais recentes do RHEL e do CentOS
  • /var/lib/ca-certificates: OpenSUSE

Outros caminhos de certificado podem incluir:

  • /etc/ssl/certs: Debian, Ubuntu
  • /etc/pki/tls/certs: RHEL, CentOS

Alguns dos certificados nesses diretórios são links simbólicos para arquivos em outros diretórios.

Repositório de certificados raiz do OpenSSL

Para aplicativos que usam o OpenSSL (link em inglês), é possível verificar o local configurado dos componentes instalados, inclusive o repositório padrão de certificados usando o seguinte comando:

openssl version -d

O comando imprime OPENSSLDIR, que corresponde ao diretório de nível superior em que estão a biblioteca e as configurações:

OPENSSLDIR: "/usr/lib/ssl"

O repositório de certificados raiz está localizado no subdiretório certs.

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

Se o OpenSSL usa o repositório padrão de certificados raiz do sistema, como no exemplo acima, verifique a seção Onde meus certificados raiz do sistema são armazenados e Como fazer a atualização deles? para saber como atualizar o pacote de certificados raiz do sistema.

Consulte a seção Onde encontrar o OpenSSL para saber como gerar o openssl.

Repositório de certificados raiz do Java

Os aplicativos Java podem usar o próprio repositório de certificados raiz, que, em sistemas Linux, normalmente está localizado em /etc/pki/java/cacerts ou /usr/share/ca-certificates-java, e que pode ser gerenciado usando a ferramenta de linha de comando keytool do Java.

Para importar um certificado individual para seu repositório de certificados do Java, execute o seguinte comando:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

Basta substituir cert.pem pelo arquivo de certificado correspondente a cada certificado raiz recomendado, alias por um alias de certificado exclusivo, mas relevante, e certs.jks pelo arquivo do banco de dados de certificados usado no seu ambiente.

Para mais informações, consulte os seguintes artigos da Oracle e do Stack Overflow:

Repositório de certificados raiz do Mozilla NSS

Os aplicativos que utilizam o Mozilla NSS (em inglês) também podem, por padrão, usar um banco de dados de certificados do sistema, normalmente localizado em /etc/pki/nssdb, ou um repositório padrão específico do usuário em ${HOME}/.pki/nssdb.

Para atualizar o banco de dados NSS, use a ferramenta certutil.

Para importar um arquivo de certificado individual para o banco de dados NSS, emita o seguinte comando:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

Basta substituir cert.pem pelo arquivo de certificado correspondente a cada certificado raiz recomendado, cert-name por um apelido de certificado relevante e certdir pelo caminho do banco de dados de certificados usado no seu ambiente.

Confira mais informações no manual oficial de certutil do NSS Tools (em inglês) e a documentação do sistema operacional.

Repositório de certificados raiz do Microsoft .NET

Os desenvolvedores .NET do Windows podem consultar os seguintes artigos da Microsoft para atualizar o repositório de certificados raiz:

Formatos de arquivo de certificado

O que é um arquivo PEM?

O formato de arquivo de texto padrão Privacy-Enhanced Mail (PEM) é usado para armazenar e enviar certificados criptográficos, chaves, entre outros itens, todos formatados com um padrão de jure no RFC 7468.

O formato do arquivo é legível, mas as informações de dados de certificado binários codificados em Base64 não são. No entanto, a especificação PEM permite a emissão de um texto explicativo (links em inglês) antes ou depois do corpo do certificado codificado. Além disso, muitas ferramentas usam esse recurso para oferecer um resumo em texto simples dos elementos de dados mais relevantes em um certificado.

Ferramentas como openssl também podem ser usadas para decodificar todo o certificado em um formato legível. Consulte a seção Como imprimir certificados PEM em formato legível para mais detalhes.

O que é um arquivo ".crt"?

As ferramentas que permitem a exportação de certificados no formato PEM geralmente (em inglês) usam a extensão de arquivo ".crt" para indicar que o arquivo utiliza codificação de texto.

O que é um arquivo DER?

As regras de codificação diferenciadas (DER, na sigla em inglês) são um formato binário padronizado para a codificação de certificados. Os certificados em arquivos PEM (em inglês) geralmente são codificados no formato DER em Base64.

O que é um arquivo ".cer"?

Um arquivo exportado com um sufixo ".cer" pode conter um certificado codificado em PEM, mas normalmente tem um certificado binário criado no formato DER. Por convenção (em inglês), os arquivos ".cer" geralmente contêm apenas um certificado.

Meu sistema se recusa a importar todos os certificados do arquivo roots.pem

Alguns sistemas, como keytool do Java, podem importar apenas um único certificado de um arquivo PEM, mesmo que tenham vários. Confira a pergunta Como extrair certificados individuais de roots.pem? para saber como o arquivo pode ser dividido.

Como extrair certificados individuais de roots.pem?

É possível dividir roots.pem nos certificados componentes usando o seguinte script bash simples:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Esse processo cria uma série de arquivos PEM semelhantes aos listados abaixo:

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

Os arquivos PEM individuais, como 02265526.pem, podem ser importados separadamente ou convertidos em um formato de arquivo aceito pelo repositório de certificados.

Como converter um arquivo PEM em um formato com suporte no meu sistema?

É possível utilizar a ferramenta de linha de comando openssl do kit de ferramentas do OpenSSL (link em inglês) para converter arquivos entre os formatos de certificado mais usados. Confira abaixo as instruções para converter um arquivo PEM nos formatos de certificado mais usados.

Para uma lista completa das opções disponíveis, consulte a documentação oficial de utilitários da linha de comando do OpenSSL (link em inglês).

Consulte a seção Onde encontrar o OpenSSL para saber como gerar o openssl.

Como converter um arquivo PEM no formato DER?

Usando openssl, você pode emitir o comando a seguir para converter um arquivo PEM no formato DER:

openssl x509 -in roots.pem -outform der -out roots.der
Como converter um arquivo PEM em PKCS #7?

Usando openssl, você pode emitir o comando a seguir para converter um arquivo PEM em PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Como converter um arquivo PEM em PKCS #12 (PFX)?

Usando openssl, você pode emitir o comando a seguir para converter um arquivo PEM em PKCS #12:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

É necessário definir uma senha para o arquivo ao criar um arquivo PKCS #12. Guarde essa senha em um lugar seguro se você não importar o arquivo imediatamente para seu sistema.

Como listar, imprimir e exportar certificados do repositório de certificados raiz

Como posso exportar um certificado do Java KeyStore como um arquivo PEM?

Com keytool, você pode emitir o comando a seguir para listar todos os certificados no seu repositório, junto com o alias que pode ser usado para exportar cada um:

keytool -v -list -keystore certs.jks

Basta substituir certs.jks pelo arquivo do banco de dados de certificados usado no seu ambiente. Esse comando também mostra o alias de cada certificado, que será necessário se você quiser fazer a exportação dele.

Para exportar um certificado individual no formato PEM, emita o seguinte comando:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

Basta substituir certs.jks pelo arquivo do banco de dados de certificados usado no seu ambiente e informar um alias e alias.pem correspondentes ao certificado que você quer exportar.

Para mais informações, consulte o manual Referência da Java Platform, Standard Edition Tools: keytool.

Como faço para exportar certificados do repositório de certificados raiz do NSS como um arquivo PEM?

Com certutil, você pode emitir o seguinte comando para listar todos os certificados no seu repositório, junto com o apelido que pode ser usado para exportar cada um:

certutil -L -d certdir

Basta substituir certdir pelo caminho do banco de dados de certificados usado no seu ambiente. Esse comando também mostra o apelido de cada certificado, que será necessário se você quiser fazer a exportação dele.

Para exportar um certificado individual no formato PEM, emita o seguinte comando:

certutil -L -n cert-name -a -d certdir > cert.pem

Basta substituir certdir pelo caminho do banco de dados de certificados usado no seu ambiente e informar um cert-name e cert.pem correspondentes ao certificado que você quer exportar.

Confira mais informações no manual oficial de certutil do NSS Tools (em inglês) e a documentação do sistema operacional.

Como imprimir certificados PEM em formato legível

Nos exemplos a seguir, presumimos que você tenha o arquivo GTS_Root_R1.pem com o seguinte conteúdo:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
Como imprimir arquivos de certificado usando o OpenSSL

Ao emitir o comando

openssl x509 -in GTS_Root_R1.pem -text

a saída deverá ser semelhante a:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

Consulte a seção Onde encontrar o OpenSSL para saber como gerar o openssl.

Imprimir certificados usando o keytool do Java

Ao emitir o comando

keytool -printcert -file GTS_Root_R1.pem

a saída deverá ser semelhante a:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Consulte a seção Receber um keytool do Java para mais instruções sobre como gerar o keytool.

Como faço para ver quais certificados raiz estão instalados no meu repositório?

Isso varia de acordo com o sistema operacional e a biblioteca SSL/TLS. No entanto, as ferramentas que permitem importar e exportar certificados do repositório e para ele normalmente disponibilizam uma opção para listar os certificados instalados.

Além disso, se você tiver exportado os certificados raiz confiáveis para arquivos PEM ou se o repositório de certificados já incluir arquivos PEM armazenados, tente abrir os arquivos em qualquer editor de texto porque ele vai ter um formato de texto simples.

O arquivo PEM pode ser devidamente rotulado, oferecendo informações legíveis sobre a autoridade certificadora associada (exemplo do pacote de CAs raiz confiáveis do Google):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

O arquivo também pode conter apenas a parte do certificado. Nesses casos, o nome do arquivo, como GTS_Root_R1.pem, pode descrever a qual CA o certificado pertence. A string do certificado entre os tokens -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- também vai ser exclusiva para cada CA.

No entanto, mesmo que você não tenha as ferramentas acima, como todos os certificados no pacote de CAs raiz confiáveis do Google devidamente rotulados, é possível associar as CAs raiz do pacote àquelas do repositório de certificados raiz usando Issuer ou comparando as strings de certificado de arquivos PEM.

Os navegadores da Web podem usar um repositório próprio de certificados raiz ou usar o padrão fornecido pelo sistema operacional. No entanto, todos os navegadores mais recentes permitem o gerenciamento ou a visualização do conjunto de CAs raiz em que eles confiam. Confira a pergunta Os aplicativos JavaScript correm o risco de serem corrompidos? para mais detalhes.

Se quiser instruções específicas para dispositivos móveis, consulte a pergunta Como verificar os certificados raiz confiáveis no meu smartphone?.

Apêndice

Precisa de mais informações?

Consulte sempre as documentações do sistema operacional, das linguagens de programação do aplicativo e das bibliotecas externas que o app usa.

Outras fontes de informações, incluindo estas perguntas frequentes, podem estar desatualizadas ou incorretas e não devem ser consideradas confiáveis. Porém, você encontra informações úteis em várias comunidades de perguntas e respostas do Stack Exchange, além de sites como o AdamW on Linux and more e o blog "confirm" (links em inglês), entre outros.

Confira também as Perguntas frequentes sobre o Google Trust Services.

Para mais detalhes sobre tópicos avançados, como fixação de certificados, consulte o artigo Certificados e fixação de chaves públicas, do Open Web Application Security Project (OWSP), e o informativo Folha de referência sobre fixação (links em inglês). Para conferir instruções específicas do Android, consulte o documento de treinamento oficial em práticas recomendadas de segurança e privacidade no Android, Segurança com HTTPS e SSL. Para mais detalhes sobre a fixação de chaves públicas e de certificados no Android, a postagem do blog de Matthew Dolan pode ser útil: Segurança do Android: fixação de SSL (link em inglês).

O documento de treinamento em práticas recomendadas de segurança e privacidade do Android, Configuração de segurança de rede, e a postagem do blog JeroenHD Android 7 Nougat e autoridades certificadoras dão mais informações sobre o gerenciamento de outros certificados confiáveis no Android.

Consulte o repositório Git certificados de CA (em inglês) para uma lista abrangente de CAs raiz confiáveis pelo AOSP. Para conferir as versões com base em bifurcações não oficiais do Android, como o LineageOS, consulte os repositórios disponibilizados pelo fornecedor do SO.