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

Informações gerais

Solução de problemas

Gerenciar seus certificados confiáveis

Apêndice

Informações gerais

O que está acontecendo?

Visão geral

O Google está elaborando um plano de vários anos para emitir e usar os próprios certificados raiz, ou seja, as assinaturas criptográficas que são a base da segurança de Internet TLS/SSL usada por HTTPS.

Atualmente, a segurança TLS da Plataforma Google Maps é garantida por um certificado raiz emitido pela GeoTrust Global CA, uma autoridade de certificação (CA, na sigla em inglês) amplamente conhecida e recomendada, pertencente à Symantec. Praticamente todos os clientes TLS (como navegadores da Web, smartphones e servidores de aplicativos) estão cientes desse certificado raiz e, portanto, podem usá-lo para garantir uma conexão segura com os servidores da Plataforma Google Maps.

No início de 2020, o Google planeja migrar todos os serviços da Plataforma Google Maps para um certificado raiz emitido pela autoridade de certificação do Google, o Google Trust Services (GTS).

Durante esse processo, no início de 2018, a Plataforma Google Maps migrou para outro certificado raiz amplamente recomendado do GlobalSign (GS, na sigla em inglês). Para facilitar a transição, o Google comprou os direitos de uso desse certificado raiz (e da CA que o GlobalSign usou para emiti-lo).

A grande maioria dos clientes TLS já reconhece o certificado raiz GlobalSign, portanto, o uso da Plataforma Google Maps não será afetado por essa alteração inicial.

No entanto, é possível que alguns clientes não tenham o certificado raiz GlobalSign, principalmente em alguns casos específicos, como dispositivos incorporados ou usuários que trabalham com navegadores ou sistemas operacionais muito desatualizados. Esses clientes precisarão ser atualizados com o certificado para proteger as conexões da Plataforma Google Maps. O Google não consegue identificar esses clientes. Por isso, os proprietários precisam realizar as verificações necessárias nos próprios aplicativos. O Google Trust Services fornece endpoints de teste HTTPS no site do GTS para facilitar essa tarefa. Veja abaixo mais detalhes técnicos.

Esse mesmo processo provavelmente se aplicará à maioria dos sistemas a partir do início da migração para os certificados raiz do GTS. Se os usuários seguirem as recomendações deste documento, devem ter uma migração tranquila, mesmo com sistemas específicos.

Resumo técnico

Conforme anunciado no portal de suporte ao cliente do plano Premium da Plataforma Google Maps em 16 de março de 2017, e também no Blog de segurança do Google, o Google criou seu próprio CA raiz, oGTS. Junto com outros serviços do Google, a Plataforma Google Maps fará a transição gradual para os certificados TLS assinados pelas CAs raiz do GTS.

Como parte desse processo, o Google adquiriu a GS Root R2 CA existente, amplamente recomendada. A plataforma do Google Maps começou a migrar do certificado raiz do GeoTrust para esse certificado no final de 2017, finalizando o processo no início de 2018.

Quase todos os clientes TLS são pré-configurados com o certificado GS Root R2 ou o recebem pelas atualizações regulares de software. No entanto, se um aplicativo se conectar à Plataforma Google Maps a partir de clientes que não reconheçam esse certificado, os desenvolvedores de aplicativos precisam testar os clientes e, se necessário, atualizá-los com o certificado.

O certificado GS Root R2 está disponível no site do GTS, juntamente com todos os certificados raiz do GTS. Para fins de teste, o site do GTS também fornece endpoints com certificados TLS assinados por cada CA. Em especial, se seu cliente puder estabelecer uma conexão TLS com o endpoint de teste GS Root R2, ele passará a usar esse certificado e não será afetado pela próxima alteração.

O Google usará a CA do GS Root R2 pelo menos até o fim de 2018. Depois disso, a Plataforma Google Maps poderá fazer a transição diretamente para a CA GTS ou poderá voltar a usar CAs raiz de terceiros, incluindo a GS Root R3.

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

Marque o problema público 67842936 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.

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, você precisa garantir que seu aplicativo seja compatível com o grupo de certificados raiz recomendados listado no arquivo PEM de amostra do Google. Dessa forma, ele estará pronto para a migração do certificado raiz, independentemente da API ou do serviço do Google que ele pode chamar. Consulte a pergunta Devo instalar todos os certificados raiz do arquivo PEM de amostra do Google? para saber mais detalhes.

Como posso verificar se meu repositório de certificados precisa de atualização?

Teste o ambiente do aplicativo nos endpoints de teste listados com cada uma das CAs raiz no site do GTS. Se você conseguir estabelecer uma conexão TLS com o endpoint de testes do GS Root R2 e o sandbox do teste de certificado do Google, ela ficará válida pelo menos até o final de 2018.

Portanto, recomendamos a instalação imediata de todos os certificados do arquivo PEM de amostra do Google para garantir o funcionamento do sistema no futuro, a menos que você queira manter seu ambiente de produção sempre atualizado com os patches mais recentes.

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

A ferramenta de linha de comando curl, disponível na maioria das plataformas, oferece várias opções para testar a configuração. Consulte a seção Receber o curl para ver instruções sobre como obter o curl.

Testar seu repositório de certificados padrão
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
Verificar o pacote da CA raiz do Google
Faça o download do arquivo PEM de amostra do Google e siga as etapas abaixo:
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

Como a migração ocorrerá?

Quando a migração ocorrerá?

A primeira fase de migração (para os certificados emitidos por CAs intermediárias ancoradas no GS Root R2) começou no final de 2017 e foi concluída no primeiro semestre de 2018.

As programações de fases posteriores de migração serão anunciadas nos próximos anos com bastante antecedência à expiração do certificado GS Root R2 2021.

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

  • O lançamento gradual começa em um único data center.
  • O processo será estendido gradualmente a outros data centers até que haja cobertura global.
  • Se ocorrerem problemas graves em qualquer fase, os testes poderão ser revertidos temporariamente enquanto as falhas forem resolvidas.
  • 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. Não é possível determinar com certeza quem será afetado, quando e onde. Por isso, recomendamos que todos os nossos clientes preparem os sistemas para as etapas futuras, com antecedência às próximas fases da migração de CA raiz do Google.

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 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?

Consulte a seção Quais são os requisitos mínimos para um cliente Transport Layer Security (TLS) se comunicar com a Plataforma Google Maps? nas Perguntas frequentes sobre o GTS.

Ali estão os únicos requisitos da Plataforma Google Maps.

Quais tipos de aplicativos correm o risco de serem corrompidos?

O aplicativo usa o armazenamento de certificados 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 7+ ou Server 2008+, OS X) que ainda esteja em funcionamento e receba atualizações regulares, seu repositório de certificados padrão já deverá incluir o certificado GS Root R2.

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 R2. Por exemplo, o Windows XP SP2 o inclui, enquanto o Windows XP SP1, não. Os dispositivos legados precisam ser testados para garantir que usam o certificado.

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 aplicativos 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 aplicativo. Consulte a seção Os aplicativos da API Google Maps JavaScript correm o risco de serem corrompidos? para mais detalhes.

Em aplicativos nativos para dispositivos móveis (tanto Android quanto iOS) que usam os SDKs do Google Maps ou do Places, as mesmas regras se aplicam aos aplicativos que chamam os serviços da Web da Plataforma Google Maps.

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

O aplicativo 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 discutido na pergunta Devo instalar todos os certificados raiz do arquivo PEM de amostra do Google?, é recomendável importar todos os certificados raiz do arquivo PEM de amostra do Google para seu repositório de certificados.

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 do 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?.

Devo instalar todos os certificados raiz do arquivo PEM de amostra do Google?

Se quiser preparar seu sistema de uma vez, recomendamos a instalação de todos os certificados do arquivo PEM de amostra do Google, principalmente se você não fizer atualizações do sistema operacional com regularidade e frequência ou se, por exemplo, mantiver os próprios pacotes de certificado para o aplicativo.

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

Instale e use somente os certificados raiz do arquivo PEM de amostra do Google para verificar a autenticidade de toda a cadeia de certificados ancorada ao certificado que você escolher. Isso se aplica igualmente a certificados de servidor individuais (por exemplo, aqueles fornecidos pelo host maps.googleapis.com), bem como a nossas CAs intermediárias (por exemplo: GIAG3, GTS CA 1O1 ou GIAG4).

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 da API Google Maps JavaScript correm o risco de serem corrompidos?

A CA raiz GlobalSign R2 é compatível e usada pela maioria dos navegadores modernos. Portanto, é provável que esses navegadores continuem conectados aos serviços do Google por algum tempo. Quando o navegador é mantido de forma ativa, é quase certo que ele também será compatível com todas as outras CAs raiz do Google.

No entanto, como a API Google Maps JavaScript só funciona com navegadores compatíveis, recomendamos usar uma das opções listadas e manter o navegador atualizado para evitar problemas de uso.

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

Os dispositivos Android e Apple que ainda recebem atualizações regulares do fabricante do dispositivo também devem ser preparados para a migração do certificado. A maioria dos modelos de smartphone Android mais antigos já inclui pelo menos o GS Root R2 e o GS Root R3, embora a lista de certificados confiáveis possa variar de acordo com o fabricante do dispositivo, o modelo do dispositivo e a versão Android. As versões mais recentes do Android Open Source Project (AOSP) usadas nos dispositivos das marcas Google Nexus e Pixel também usam o GS Root R4 por padrão. O suporte para as CAs raiz do GTS ainda é mínimo para as versões lançadas do Android.

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 do iOS e posteriores são compatíveis com GS Root R2 e R3, enquanto as versões 7 e posteriores também têm o GS Root R4. Assim como nas versões atuais do Android, as CAs raiz do GTS ainda não são compatíveis por padrão.

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?

O Google está trabalhando com todos as principais empresas que disponibilizam os pacotes de certificados raiz mais usados 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.

Como o cronograma de inclusão de certificados de terceiros está além do 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 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 sua distribuição do SO não fornecer openssl, faça o download da origem em https://www.openssl.org/ 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 o Wireshark e o tcpdump

A maioria das distribuições do Linux oferece as duas ferramentas. Para outros SOs, as versões pré-compiladas de wireshark podem ser encontradas em https://www.wireshark.org. O código-fonte de tcpdump e LibPCAP pode ser encontrado em https://www.tcpdump.org.

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 de certificado raiz, a menos que seu aplicativo seja criado usando Java.

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

A principal recomendação é instalar os certificados raiz necessários do arquivo PEM de amostra do Google no repositório que o aplicativo usa. Você também encontra informações úteis na seção Gerenciar seus certificados confiáveis.
  1. Peça a ajuda dos administradores do sistema para fazer o upgrade do armazenamento do certificado local.
  2. Consulte estas perguntas frequentes para ver as opções aplicáveis ao seu sistema.
  3. Se você precisar de assistência 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.
  5. Marque o problema público 67842936 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 pergunta Como posso verificar se meu repositório de certificados precisa de atualização? para ver as 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, esteja pronto para fornecer 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. Resultados dos seguintes comandos:
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
    

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

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 corretamente e garantir resultados confiáveis?

Você consegue informações muito úteis ao executar curl com as sinalizações -vvI. Veja a seguir algumas instruções para interpretar o resultado:
  • As linhas que começam com * mostram o resultado 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 o um handshake de TLS foi processado.
Biblioteca TLS e pacote de certificados raiz usados

Quando você executa curl com os sinalizadores -vvI, também imprime o armazenamento do certificado usado, mas o resultado exato pode variar de acordo com o sistema, conforme mostrado abaixo.

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

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

O resultado gerado por uma máquina Ubuntu ou Debian Linux pode conter estas linhas:

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

O resultado gerado 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/<username>/Downloads/roots.pem
  CApath: /etc/ssl/certs
User-agent

As solicitações de resultados contêm o cabeçalho user agent que pode fornecer 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 libssh2/1.4.2
> Host: cert-test.sandbox.google.com
> Accept: */*
>
Falha no handshake de TLS
As linhas como estas mostradas abaixo indicam que a conexão foi encerrada durante o handshake do TLS por causa de um certificado de servidor não confiável. A ausência do resultado 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 a estas mostradas 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:
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
Como faço para imprimir os certificados de servidor recebidos em um formato legível?
Presumindo que o resultado esteja formatada em PEM (por exemplo, o resultado de openssl s_client ... -showcerts), é possível imprimir o certificado exibido seguindo as etapas abaixo:
  1. Copie todo o certificado codificado em Base 64, incluindo o cabeçalho e o rodapé:
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. Cole o conteúdo do buffer de cópia no terminal.
  4. Pressione a tecla Enter.
Para ver exemplos de entradas e resultados, consulte a pergunta Como imprimir certificados PEM de forma legível?.

Como são os certificados do Google no OpenSSL?

Novo certificado ancorado na CA raiz do GlobalSign – R2

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

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 aplicativos para dispositivos móveis correm o risco de serem corrompidos?, desde a 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. A tabela abaixo 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 e credenciais 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 Android Virtual Device (AVD) disponíveis, recorrendo ao histórico de versões do repositório Git de certificados de CA do AOSP sempre que as imagens de sistema não estiverem mais disponíveis:

Versão do Android GS Root R2 GS Root R3 GS Root R4 GTS
2.3, 3.2, 4.x, 5.0
5.1, 6.x, 7.x, 8.x, 9
10

Em geral, não é possível atualizar o armazenamento de certificados do sistema Android sem atualizar o firmware ou acessar o dispositivo com root. No entanto, é provável que o conjunto atual de certificados raiz confiáveis na maioria das versões do Android forneça um 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 ou instaladas por uma política de grupo corporativo aplicada ao dispositivo.

Loja de confiança do iOS

Embora a Apple não mostre diretamente o conjunto padrão de certificados raiz confiáveis para o usuário do dispositivo móvel, a empresa tem links para os conjuntos de CAs raiz compatíveis com as versões 5 e posteriores do iOS nas Listas de artigos da Apple de certificados raiz confiáveis disponíveis no iOS e iOS 5 e iOS 6: lista de certificados raiz disponíveis.

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.

A tabela abaixo ilustra a disponibilidade dos certificados raiz mais críticos por versão do iOS, com base nas fontes acima:

Versão do iOS GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11, 12.0
12.1.3+

Onde está meu repositório de certificados do sistema e como posso atualizá-lo?

O local do repositório de certificados padrão 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 (Debian, Ubuntu e versões mais antigas do RHEL e do CentOS), /etc/pki/ca-trust/source/anchors e /usr/share/pki/ca-trust-source (Fedora e versões mais recentes do RHEL e do CentOS) ou /var/lib/ca-certificates (OpenSUSE). Outros caminhos de certificado são /etc/ssl/certs (Debian, Ubuntu) ou /etc/pki/tls/certs (RHEL, CentOS). Alguns dos certificados nesses diretórios são links simbólicos para arquivos em outros diretórios.

OpenSSL

Para aplicativos que usam o OpenSSL, é possível verificar o local configurado dos componentes instalados, incluindo o armazenamento 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 a biblioteca e as configurações são encontradas:
OPENSSLDIR: "/usr/lib/ssl"
O repositório de certificados se encontra no subdiretório certs.
$ ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

Se o OpenSSL utilizar o repositório padrão do sistema, como no exemplo acima, consulte a seção geral Onde está meu repositório de certificados do sistema e como posso atualizá-lo? 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 obter o openssl.

NSS da Mozilla

Os aplicativos que utilizam Mozilla NSS também podem, por padrão, usar um banco de dados de certificados do sistema, normalmente localizado em /etc/pki/nssdb ou uma loja padrão específica do usuário em ${HOME}/.pki/nssdb. Para atualizar o NSS, confira a documentação oficial do sistema operacional e a documentação sobre a ferramenta certutil para saber como adicionar novos certificados.

Microsoft .NET

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

Java

Os aplicativos Java podem usar o próprio repositório de certificados, que, em sistemas Linux, normalmente está localizado em /etc/pki/java/cacerts ou /usr/share/ca-certificates-java. Para saber como atualizar seu armazenamento de certificados Java usando a ferramenta de linha de comando Oracle keytool, consulte estes artigos do Stack Overflow e da Oracle:

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., formalizados como um padrão de eliminação 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 antes ou depois do corpo do certificado codificado. Além disso, muitas ferramentas usam esse recurso para fornecer 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 formato legível. Consulte a seção Como imprimir certificados PEM de forma legível? para mais informações.

O que é um arquivo ".crt"?

As ferramentas que permitem a exportação de certificados no formato PEM geralmente usam a extensão de arquivo ".crt" para indicar que o arquivo usa 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 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, os arquivos ".cer" geralmente contêm apenas um certificado.

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

Alguns sistemas só aceitam a importação de arquivos PEM que contêm um único certificado. Consulte 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}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
Esse processo cria uma série de arquivos PEM individuais semelhantes aos listados abaixo:
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
Os arquivos PEM issuer=….pem podem ser importados individualmente ou convertidos em um formato de arquivo aceito pelo repositório de certificados.

Como faço para converter um arquivo PEM em um formato compatível com o meu sistema?

É possível utilizar a ferramenta de linha de comando openssl do OpenSSL 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.

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

Como converter um arquivo PEM no formato DER?

Usando openssl, você pode emitir o comando a seguir para converter um arquivo de 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 de PEM 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 de PEM 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 archive. Guarde essa senha em um lugar seguro se você não importar o arquivo imediatamente para seu sistema.

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

Confira a documentação da ferramenta certutil do Mozilla NSS e a discussão do site da comunidade Red Hat exportar o certificado do cert8.db como um arquivo .pem.

Como imprimir certificados PEM de forma legível?

Nos exemplos a seguir, presumimos que você tenha o arquivo GlobalSign_Root_CA_-_R2.pem com o seguinte conteúdo:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Imprimir certificados usando o OpenSSL

Ao emitir o comando
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
você deve gerar estas linhas a seguir antes do certificado:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

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

Imprimir certificados usando o keytool do Java

Ao emitir o comando
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
você deve gerar o seguinte resultado:
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

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

Como 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 e para o repositório 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 armazenamento 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 da autoridade de certificação associada (exemplo do arquivo PEM de amostra do Google):

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

O arquivo também pode conter apenas a parte do certificado. Nesses casos, o nome do arquivo, como GlobalSign_Root_CA_-_R2.pem, pode descrever a qual CA o certificado pertence. Como a string de certificado entre os tokens -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- é exclusiva de cada CA, compare as strings dos arquivos PEM se não conseguir identificar as CAs.

Em outras palavras, é possível comparar cada certificado do arquivo PEM de amostra do Google com os arquivos PEM extraídos do repositório de certificados. Cada certificado do pacote de CA raiz do Google é rotulado de forma única. Assim, é possível verificar quais dos certificados já estão no repositório e identificar quais ainda precisam ser adicionados, mesmo que os arquivos PEM não tenham sido rotulados.

Para receber 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 aplicativo 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, além de sites como o AdamW no Linux e muito mais e o blog de confirmação, entre outros. Consulte também as Perguntas frequentes do GTS e o artigo Como usar certificados X.509 e SSL para fazer comunicações seguras.

Para mais detalhes sobre tópicos avançados, como a fixação de certificados, use o artigo sobre o Projeto de segurança de aplicativos da Web (OWASP, na sigla em inglês) e o folheto informativo. Para ver instruções específicas do Android, consulte o documento de treinamento oficial Práticas recomendadas de segurança e privacidade 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: Android Security: SSL Pinning.

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 JeeroenHD. Android 7 Nougat and certificate authorities (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 para ver uma lista abrangente de CAs raiz confiáveis pelo AOSP. Para ver as versões com base em ramificações oficiais do Android, como o LineageOS, consulte os respectivos repositórios disponibilizados pelo fornecedor do SO.