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 de certificação.
Os navegadores precisam de certificados emitidos por autoridades certificadoras confiáveis para confirmar se as informações transmitidas são enviadas ao servidor correto e criptografadas durante o trânsito.
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 criptograficamente protegidos (certificados) para verificar se uma entidade (por exemplo, um site) é quem afirma ser.
Antes de emitir um certificado, as CAs são responsáveis por confirmar se os nomes no certificado estão vinculados à pessoa ou entidade que o solicitou.
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 contém um conjunto de autoridades de certificação 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 de certificação raiz
Uma autoridade de certificação raiz (ou certificado ITS) é o certificado 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 certificado ITS) é usada para assinar outros certificados em uma cadeia de certificados.
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 de certificação emissora (ou certificado ITS) usada para assinar o certificado mais abaixo em uma cadeia de certificados.
Esse certificado é chamado de certificado de assinante ou de entidade final ou secundário. Neste documento, também usaremos 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 secundário, 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 criarão uma cadeia de certificados diferente 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 garantida pelo GS Root R2, o certificado de uma CA raiz conhecida e amplamente confiável, adquirida pelo Google no GMO GlobalSign para facilitar a transição para nossas próprias CAs raiz autoassinadas do Google Trust Services (GTS).

Praticamente todos os clientes TLS (como navegadores da Web, smartphones e servidores de aplicativos) confiam 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 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 grande 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 a maioria dos sistemas legados. No entanto, o Google adquiriu uma assinatura cruzada do GMO GlobalSign usando a GlobalSign Root CA - R1, uma das CAs raiz mais antigas e confiáveis disponíveis.

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

Isso também se aplica a clientes que adotaram 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 o seguinte for aplicável:

  • 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 aplicou 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 se aplicarem, os clientes precisarão 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 que você mantenha os repositórios de certificados raiz sincronizados com o pacote de CA raiz selecionado acima de modo a preparar seus serviços para futuras alterações na CA raiz. No entanto, elas serão anunciadas com antecedência. Consulte as seções Como receber atualizações nessa fase de migração? e Como posso receber avisos de migrações futuras com antecedência? para mais instruções sobre notificações.

Resumo técnico

Conforme anunciado em 15 de março de 2021 no blog de segurança do Google, o GS Root R2, o certificado da CA raiz da Plataforma Google Maps usada desde o início de 2018, vai expirar em 15 de dezembro de 2021. Por isso, o Google migrará para a CA GTS Root R1 Cross recém-criada ainda este ano. Isso significa que nossos serviços serão transferidos gradualmente para certificados TLS secundários 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 recebê-lo por meio de atualizações normais de software, e a GlobalSign Root CA - R1 precisa estar disponível mesmo em sistemas legados mais antigos.

No entanto, será necessário verificar os sistemas pelo menos se os dois pontos a seguir se aplicarem:

  • 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 aplicou 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 fornece orientações gerais para testar se o sistema 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 posso 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 serão atualizadas durante todo o processo de migração sempre que encontrarmos tópicos que podem ser de interesse geral.

Como posso 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.

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

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

Sim, a migração da CA raiz ocorrerá em todos os Serviços e APIs do Google, mas o cronograma poderá variar de acordo com o serviço. No entanto, se os certificados raiz usados pelos aplicativos cliente da Plataforma Google Maps contiverem todas as CAs listadas no pacote de CAs raiz confiáveis do Google, seus serviços não serão afetados pela migração, e mantê-los sincronizados também protegerá você contra futuras alterações da CA raiz.

Confira mais insights 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 fornece 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, não será afetado pela expiração do GS Root R2.
  • Se você conseguir estabelecer uma conexão TLS com o endpoint de teste do GTS Root R1, seu aplicativo provavelmente ainda 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:

  • o seu serviço for executado em um sistema operacional conhecido e se você tiver mantido vinculados o sistema operacional e as bibliotecas que seu serviço usa e não tiver seu próprio repositório 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 devem 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 Receber o curl para ver instruções sobre como chamar o curl.

Consulte a seção Receber o OpenSSL para ver instruções sobre como chamar o openssl.

Você também encontrará 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.r1demo.pki.goog/; \
openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.r1xdemo.pki.goog/; \
openssl s_client -connect good.r1xdemo.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.r1demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.r1xdemo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1xdemo.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 será lançada nos próximos meses 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ê poderá evitar que seus apps se tornem obsoletos no futuro se mantiver 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, os testes poderão ser revertidos temporariamente enquanto as falhas são resolvidas.
  4. Com base nas entradas das iterações anteriores, outros Serviços do Google serão 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 alterações serão 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 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 poderão 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 empregam nomes alternativos de entidade (SANs) de DNS. Portanto, o processamento do certificado de um cliente precisa ser compatível com SANs que podem incluir um único caractere curinga à etiqueta mais à esquerda no nome, como *.googleapis.com.

Para outros requisitos, consulte a seção Quais são os requisitos recomendados para um cliente TLS se comunicar com o Google? nas Perguntas frequentes sobre GTS.

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á 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 GS Root R1. No entanto, seu repositório de certificados raiz provavelmente conterá a GlobalSign Root CA - R1, uma das CAs raiz mais antigas e confiáveis.

No caso dos aplicativos para dispositivos móveis que chamam serviços da Web da Plataforma Google Maps diretamente do dispositivo do usuário final, siga as diretrizes da 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 Google 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 utiliza recursos avançados de segurança, como a fixação de certificados.

Você 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?, é recomendável importar todos os certificados do pacote de CAs raiz confiáveis do Google no seu próprio repositório de certificados raiz.

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

Para saber mais 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 para o futuro, recomendamos que verifique se o repositório de certificados raiz contém todos os certificados do pacote e mantenha ambos sincronizados.

Isso é especialmente importante se os serviços são executados em uma versão do sistema operacional sem suporte ou não for possível aplicar patches por outros motivos ao seu sistema operacional e às bibliotecas ou manter seu próprio repositório de certificados raiz.

Confira a pergunta Como posso receber avisos de migrações futuras com antecedência? para saber como receber atualizações sobre futuras migrações da CA raiz. Manter seus certificados raiz sincronizados com a lista selecionada protegerá os serviços contra futuras interrupções devido a mudanças da CA e manterá os serviços em execução depois da expiração da GTS Root R1 Cross e da GlobalSign Root CA - R1.

Além disso, confira a pergunta Estou criando um produto que se conecta aos Serviços do Google. Quais certificados de CA preciso classificar como confiável? nas Perguntas frequentes sobre GTS para mais recomendações.

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

Caso contrário, você correrá o risco de corromper seu aplicativo quando inscrevermos um novo certificado ou alternarmos as CAs intermediárias. Isso pode acontecer a qualquer momento e sem aviso prévio e se aplica igualmente a certificados de servidor individuais, como os veiculados por maps.googleapis.com, bem como qualquer uma das 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 poderá verificar automaticamente essas cadeias, contanto que a autoridade de certificação 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 compatíveis da 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 devem 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 compatíveis para cada versão recente do iOS nas páginas de suporte. No entanto, todas as versões 5 e posteriores do iOS são compatíveis com a GlobalSign Root CA - R1.

As CAs raiz do GTS, incluindo a GTS Root R1, são compatíveis a partir da versão 12.1.3 do iOS.

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

Quando meu navegador ou sistema operacional 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 com suporte já seja compatível com 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 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, recomendamos que você faça as atualizações do sistema disponíveis regularmente.

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

Solução de problemas

Onde encontro as ferramentas necessárias?

Receber o curl

Se a sua distribuição do SO não fornecer curl, faça o download em https://curl.haxx.se/. É 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 fornecer openssl, faça o download da origem em https://www.openssl.org/ (em inglês) e compile a ferramenta. Consulte https://www.openssl.org/community/binaries.html para ver uma 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.

Receber Wireshark, Tshark ou Tcpdump

Embora a maioria das distribuições do Linux ofereça o wireshark, a ferramenta de linha de comando correspondente tshark e a tcpdump, as versões pré-compiladas das duas primeiras podem ser encontradas em https://www.wireshark.org (em inglês).

O código-fonte de Tcpdump e LibPCAP pode ser encontrado em https://www.tcpdump.org.

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 na página do 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-as para receber keytool.. O uso de keytool, por sua vez, não deve 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 aplicáveis ao 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, entre em contato 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 instruções gerais de solução de 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.r1demo.pki.goog/; \
    openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.r1xdemo.pki.goog/; \
    openssl s_client -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;
    

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

Registrar um caso de suporte

Siga as instruções em Como criar um caso de suporte em 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 suficientemente grande 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 posso encontrar 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 posso 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 de encerramento da conexão.
  • As linhas que começam com > exibem a solicitação HTTP de saída enviada por curl.
  • As linhas que começam com "<" exibem a resposta HTTP recebida do servidor.
  • Se o protocolo era HTTPS, a presença de linhas ">" ou "<" sugerem 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 fornecido 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 contêm 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 com êxito 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 esteja formatada em PEM (por exemplo, a saída de openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null), é possível imprimir o certificado exibido 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.r1xdemo.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.r1xdemo.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 ilustra a provável disponibilidade dos certificados raiz mais críticos 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 do AOSP sempre que as imagens não estiverem 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 amplamente utilizadas, o conjunto atual de certificados raiz confiáveis provavelmente fornecerá serviço ininterrupto por vários anos, excedendo a vida útil da maioria 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 aplicativos. Isso é feito por meio do agrupamento dos certificados com o aplicativo e da criação de uma configuração de segurança de rede personalizada, conforme 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 proveniente 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 aplicada ao dispositivo.

iOS Trust Store

Embora a Apple não mostre diretamente o conjunto padrão de certificados raiz confiáveis para o usuário do celular, a empresa tem links para os conjuntos de CAs raiz confiáveis para as versões 5 e posteriores do iOS dos artigos de suporte da Apple:

No entanto, qualquer outro certificado instalado no dispositivo iOS estará visível em Configurações > Geral > Perfil. Se nenhum outro certificado for instalado, o item de menu Perfil não será exibido.

Esta tabela ilustra 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 posso atualizá-los?

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, 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 OpenSSL

Para aplicativos que usam o OpenSSL, é possível verificar o local configurado dos componentes instalados, incluindo o repositório de certificado padrão 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 depende do 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 posso atualizá-los? para garantir que o pacote de certificados raiz do sistema esteja atualizado.

Consulte a seção Receber o OpenSSL para ver instruções sobre 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 significativo, 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 significativo, e certdir pelo caminho do banco de dados de certificados usado no seu ambiente.

Veja 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 etc., 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 utilizadas para decodificar todo o certificado em formato legível. Consulte a seção Como imprimir certificados PEM em formato legível para mais informações.

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 geralmente (em inglês) 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 ver 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 compatível com meu sistema?

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

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

Consulte a seção Receber o OpenSSL para ver instruções sobre 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 fornecer uma senha de 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 exportá-lo.

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 exportá-lo.

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.

Veja 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 Receber o OpenSSL para ver instruções sobre 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 ver instruções sobre como gerar o keytool.

Como faço para ver quais certificados 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á contiver arquivos PEM armazenados, tente abrir os arquivos em qualquer editor de texto, porque ele terá um formato de arquivo de texto simples.

O arquivo PEM pode ser devidamente rotulado, fornecendo informações legíveis sobre a autoridade de certificação 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 será exclusiva para cada CA.

No entanto, mesmo que você não tenha as ferramentas acima, como cada certificado no pacote de CAs raiz confiáveis do Google está devidamente rotulado, é possível fazer a correspondência das CAs raiz do pacote com as do repositório dos certificados raiz com Issuer ou comparando as strings de certificado de arquivo PEM.

Os navegadores da Web podem usar o próprio repositório de certificados raiz ou confiar no 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.

Para ver instruções específicas para dispositivos móveis, consulte a pergunta Como posso 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ê pode encontrar informações úteis em várias comunidades de perguntas e respostas do Stack Exchange (em inglês), além de em sites como o AdamW no Linux e muito mais e o blog de confirmação (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 (em inglês) do Open Web Application Security Project (OWSP) e o informativo Folha de referência sobre fixação (em inglês). Para ver instruções específicas do Android, consulte o documento de treinamento oficial Práticas recomendadas de privacidade e segurança com HTTPS e SSL do Android. Para mais informações sobre a fixação de chaves públicas e certificados no Android, a postagem do blog de Matthew Dolan pode ser útil: Segurança do Android: fixação de SSL (em inglês).

O documento de treinamento Configuração de segurança de rede, que traz práticas recomendadas de segurança e privacidade do Android, e a postagem do blog JeroenHD. Android 7 Nougat e autoridades de certificação (em inglês) oferecem 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 ver uma lista abrangente de CAs raiz confiáveis pelo AOSP. Para ver as versões com base em bifurcações oficiais do Android, como o LineageOS, consulte os respectivos repositórios disponibilizados pelo fornecedor do SO.