Domande frequenti sulla migrazione della CA radice di Google Maps Platform

Il presente documento si articola nelle seguenti sezioni:

Per una panoramica più dettagliata della migrazione in corso della CA radice di Google, vedi Che cosa sta succedendo?

Terminologia

Di seguito abbiamo raccolto un elenco dei termini più importanti che devi avere con cui hai familiarità per questo documento. Per una panoramica più completa della terminologia, consulta Domande frequenti su Google Trust Services.

Certificato SSL/TLS
Un certificato associa una chiave di crittografia a un'identità.
I certificati SSL/TLS vengono utilizzati per autenticare e stabilire connessioni sicure ai siti web. I certificati vengono emessi e firmati tramite crittografia da persone giuridiche note come autorità di certificazione.
I browser si basano su certificati emessi da autorità di certificazione attendibili per sapere che le informazioni trasmesse siano inviate al server giusto e che mentre sono in transito.
SSL (Secure Sockets Layer)
Secure Sockets Layer è stato il protocollo più diffuso per la crittografia per le comunicazioni internet. Il protocollo SSL non è più considerato sicuro non devono essere utilizzati.
Transport Layer Security (TLS)
Transport Layer Security è il successore di SSL.
Autorità di certificazione (CA)
Un'autorità di certificazione è come un ufficio passaporti digitali per i dispositivi persone. Emette documenti protetti tramite crittografia (certificati) per attestare che un'entità (ad es. un sito web) è quella che sostiene di essere.
Prima di emettere un certificato, le CA hanno la responsabilità di verificare che i nel certificato siano collegati alla persona o alla persona giuridica che lo richiede.
Il termine Autorità di certificazione può riferirsi a organizzazioni come Google Trust Services e a sistemi che emettono certificati.
Archivio dei certificati radice
Un archivio di certificati radice contiene un insieme di autorità di certificazione ritenute attendibili da un fornitore di software per le applicazioni. La maggior parte dei browser web e dei sistemi operativi il proprio archivio di certificati radice.
Per essere inclusa in un archivio di certificati radice, l'autorità di certificazione deve soddisfare rigorosi requisiti stabiliti dal Fornitore di software applicativo.
In genere questi includono la conformità agli standard di settore come Requisiti del CA/Browser Forum.
Autorità di certificazione radice
Un'autorità di certificazione radice (o, più correttamente, il suo certificato) è il certificato più alto in una catena di certificati.
In genere i certificati CA radice sono autofirmati. Le chiavi private associate vengono conservati in strutture altamente sicure e conservati offline per proteggerli da accessi non autorizzati.
Autorità di certificazione intermedia
Un'autorità di certificazione intermedia (o, più correttamente, il suo certificato) è Un certificato utilizzato per firmare altri certificati in una catena di certificati.
Le CA intermedie esistono principalmente per consentire l'emissione dei certificati online, consentendo al certificato della CA radice di rimanere offline.
Le CA intermedie sono anche note come CA subordinate.
Autorità di certificazione emittente
Un'autorità di certificazione emittente, o più correttamente, il suo certificato, è utilizzato per firmare il certificato più in basso in un certificato o la catena di fornitura.
Questo certificato nella parte inferiore della pagina è comunemente chiamato certificato sottoscrittore, un certificato end-entity o un certificato foglia. In questo documento utilizzeremo anche il termine certificato server.
Catena di certificati
I certificati sono collegati (firmati in modo crittografico) al loro emittente. R la catena di certificati è composta da un certificato foglia, tutti i certificati dell'emittente e un certificato radice.
Firma incrociata
Fornitori di software per le applicazioni i client devono aggiornare i certificati radice per includere nuovi certificati CA affinché possano essere considerati attendibili dai prodotti. Ci vuole un po' di tempo prima che i prodotti contenenti i nuovi certificati CA vengano utilizzati su larga scala.
Per aumentare la compatibilità con i client meno recenti, è possibile "con segno croce" da un'altra CA consolidata precedente. Questo crea in modo efficace secondo certificato CA per la stessa identità (nome e coppia di chiavi).
In base alle CA incluse nell'archivio dei certificati radice, i client una diversa catena di certificati fino a una radice attendibile.

Informazioni generali

Che cosa sta succedendo?

Introduzione

Nel 2017, Google ha avviato un progetto pluriennale in cui pubblicare e utilizzare i propri radici certificati, le firme crittografiche che sono alla base di TLS internet della sicurezza utilizzata dal protocollo HTTPS.

Dopo la prima fase, la sicurezza TLS dei servizi Google Maps Platform garantito da GS Root R2, un rooting molto noto e dell'autorità di certificazione (CA), che Google ha acquisito da GMO GlobalSign per la transizione alle nostre CA radice auto-rilasciate di Google Trust Services (GTS).

Praticamente tutti i client TLS (come browser web, smartphone e server) hanno considerato attendibile questo certificato radice e sono stati pertanto in grado di stabilire una connessione sicura ai server di Google Maps Platform durante prima fase della migrazione.

Tuttavia, una CA in base alla progettazione non può emettere certificati validi oltre la per la scadenza del proprio certificato. Poiché GS Root R2 scade il giorno Il 15 dicembre 2021 Google eseguirà la migrazione dei propri servizi a una nuova CA, GTS Root R1 Cross, utilizzando un certificato emesso dalla CA radice di Google GTS Root R1.

Sebbene la maggior parte dei sistemi operativi moderni e delle librerie client TLS si fidano già delle CA radice GTS, per garantire anche una transizione senza problemi sistemi precedenti, Google ha acquisito un cross-sign da GMO GlobalSign GlobalSign Root CA - R1, una delle CA radice più vecchie e affidabili al momento disponibili.

Pertanto, la maggior parte dei clienti I clienti di Google Maps Platform (o entrambe) queste affidabili CA radice affidabili e che completamente influenzate dalla seconda fase della migrazione.

Questo vale anche per i clienti che hanno intrapreso un'azione durante la prima fase del migrazione nel 2018, ipotizzando che all'epoca avessero seguito le nostre istruzioni, installando tutti i certificati dal nostro pacchetto CA radice attendibile di Google.

Devi verificare i tuoi sistemi, se si applica quanto segue:

  • i tuoi servizi eseguono piattaforme non standard o legacy e/o mantieni proprio archivio di certificati radice
  • non avete preso provvedimenti nel 2017-2018, durante la prima fase del migrazione della CA radice oppure non hai installato il set completo di certificati da il pacchetto attendibile di CA radice di Google

Se si applica quanto sopra, potrebbe essere necessario aggiornare i tuoi clienti con certificati radice per garantire interruzioni L'utilizzo di Google Maps Platform durante questa fase della migrazione.

Vedi di seguito per ulteriori dettagli tecnici. Per istruzioni generali, consulta la sezione Come verificare se l'archivio di certificati radice richiede un aggiornamento.

Ti consigliamo inoltre di continuare a conservare gli archivi di certificati radice in esegui la sincronizzazione con il bundle CA radice sopra selezionato per proteggere i tuoi servizi da futuri modifiche alla CA radice. Tuttavia, verranno annunciati in anticipo. Vedi sezioni Come faccio a ricevere aggiornamenti su questa fase di migrazione? e Come faccio a ricevere un preavviso per le migrazioni future? per ulteriori istruzioni su come mantenersi informati.

Riepilogo tecnico

Come annunciato il 15 marzo 2021 sul Blog sulla sicurezza di Google, GS Root R2, la CA radice utilizzata da Google Maps Platform dall'inizio del 2018 scadrà il 15 dicembre 2021. Pertanto, nel corso di quest'anno eseguire la migrazione a un account CA GTS Root R1 Cross appena emesso. Ciò significa che i nostri servizi passerà gradualmente ai certificati foglia TLS emessi dalla nuova CA.

Quasi tutti i client e i sistemi TLS moderni sono già preconfigurati con GTS Root R1 o dovrebbe riceverlo tramite i normali aggiornamenti software e GlobalSign Root CA - R1 dovrebbero essere disponibili anche sui sistemi precedenti meno recenti.

Tuttavia, ti conviene verificare i tuoi sistemi almeno se entrambi i punti seguenti applica:

  • i tuoi servizi vengono eseguiti su piattaforme non standard o legacy e/o mantieni proprio archivio di certificati radice
  • non avete preso provvedimenti nel 2017-2018, durante la prima fase del migrazione della CA radice oppure non hai installato il set completo di certificati da il pacchetto attendibile di CA radice di Google

La sezione Come verificare se l'archivio dei certificati radice necessita di un aggiornamento fornisce informazioni generali per verificare se il tuo impianto è interessato.

Visualizza domanda Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice attendibile di Google? per tutti i dettagli.

Come faccio a ricevere aggiornamenti su questa fase di migrazione?

Aggiungi il problema pubblico 186840968 per aggiornamenti. Queste Domande frequenti vengono anche aggiornate durante tutto il processo di migrazione, ogni volta che incontrano argomenti che possono essere di interesse generale.

Come faccio a ricevere un preavviso per le migrazioni future?

Ti consigliamo di seguire le Blog sulla sicurezza di Google. Cercheremo inoltre di aggiornare al più presto la documentazione specifica del prodotto, in base alle annuncio sul blog.

Iscriviti anche a Notifiche di Google Maps Platform, poiché pubblichiamo regolarmente sul forum aggiornamenti sulle modifiche che potrebbero interessano un numero maggiore di clienti.

Utilizziamo diversi servizi Google. La migrazione della CA radice interesserà tutti questi elementi?

Sì, la migrazione della CA radice verrà eseguita su tutti i servizi e le API Google, ma le tempistiche possono variare in base al servizio. Tuttavia, una volta verificato che l'account principale archivi di certificati utilizzati dalle tue applicazioni client di Google Maps Platform contengono tutte le CA elencate nella pacchetto CA radice di Google attendibile, il tuo non dovrebbero essere interessati dalla migrazione in corso e vengono mantenuti la sincronizzazione ti proteggerà anche da future modifiche dell'autorità di certificazione principale.

Visualizza le domande Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice attendibile di Google? e Quali tipi di applicazioni rischiano di interrompersi? per ulteriori insight.

La sezione Come verificare se l'archivio dei certificati radice richiede un aggiornamento di seguito fornisce inoltre istruzioni generali per testare l'impianto.

Come verificare se l'archivio di certificati radice richiede un aggiornamento

Testa l'ambiente applicativo rispetto agli endpoint di test elencati di seguito:

  • Se sei in grado di stabilire una connessione TLS Endpoint cross test GTS Root R1, non deve essere interessata dalla scadenza di GS Root R2.
  • Se sei in grado di stabilire una connessione TLS Endpoint di test GTS Root R1, probabilmente la tua applicazione verrà protetta dalla scadenza GTS Root R1 Cross e GlobalSign Root CA - R1 nel 2028.

In genere il sistema sarà compatibile con questa modifica CA radice se:

  • il tuo servizio viene eseguito su un sistema operativo mainstream mantenuto e tu devi Ha mantenuto sia il sistema operativo che le librerie utilizzate dal servizio e non gestisci il tuo archivio di certificati radice oppure:
  • hai seguito i nostri suggerimenti precedenti e hai installato tutte le CA radice da Il pacchetto attendibile di CA radice di Google

I clienti eventualmente interessati devono installare immediatamente i certificati da pacchetto CA radice attendibile di Google per per evitare future interruzioni del servizio.

Visualizza domanda Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice attendibile di Google? per tutti i dettagli.

Esiste un semplice strumento che posso utilizzare per verificare il nostro archivio dei certificati radice?

Potrebbero esserti utili i due strumenti a riga di comando curl e openssl nella tua le indagini del caso. Entrambe sono disponibili sulla maggior parte delle piattaforme e offrono per testare la configurazione.

Per istruzioni su come ottenere curl, consulta la sezione Recupero di curl di seguito.

I comandi openssl mostrati di seguito si riferiscono alla versione 1.1.1 o successive. Le versioni precedenti alla 1.1.1 non sono più supportate. Se utilizzi una versione precedente, eseguire l'upgrade o modificare questi comandi in base alle esigenze della tua versione. Per istruzioni per informazioni su come ottenere openssl, consulta la sezione Come scaricare OpenSSL di seguito.

Troverai anche altri strumenti utili nella sezione Dove posso trovare gli strumenti di cui ho bisogno? qui sotto.

Per istruzioni sui test concrete, consulta la sezione Come verificare se l'archivio dei certificati radice richiede un aggiornamento.

Test dell'archivio dei certificati radice predefinito

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

Verifica del bundle CA radice di Google attendibile

Scarica il pacchetto CA radice di Google attendibile, segui questi passaggi:

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

Come e quando continuerà la migrazione della CA radice di Google?

  1. Prima fase (migrazione a GS Root R2), annunciato a gennaio 2017, è iniziata a fine 2017 e si è conclusa nella prima metà del 2018.
  2. Seconda fase (migrazione a GTS Root R1 Cross) è stato annunciato a marzo 2021, e verrà implementata nei prossimi mesi, prima della scadenza di GS Root R2 il giorno 15 dicembre 2021.

I programmi delle eventuali fasi di migrazione successive verranno annunciati con largo anticipo. delle scadenze future dei certificati.

Tuttavia, potrai rendere le tue app a prova di futuro, se conservi che i certificati radice siano sincronizzati con l'elenco selezionato di CA radice nel pacchetto CA radice attendibile di Google.

Vedi anche domanda Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice attendibile di Google? per ulteriori informazioni.

Piano di implementazione generale per ogni servizio Google

  1. L'implementazione graduale inizia in un unico data center.
  2. Il lancio viene gradualmente esteso a un maggior numero di data center finché non sarà disponibile copertura.
  3. Se vengono rilevati problemi gravi in qualsiasi fase, è possibile eseguire il rollback dei test temporaneamente mentre i problemi vengono risolti.
  4. Sulla base degli input di iterazioni precedenti, ulteriori servizi Google vengono incluse nell'implementazione finché non sarà stata eseguita la migrazione graduale di tutti i servizi Google i nuovi certificati.

Chi sarà interessato, quando e dove?

Un numero crescente di sviluppatori di Google Maps Platform inizierà a ricevere e i nuovi certificati man mano che vengono migrati i nuovi data center. Le modifiche verranno localizzato, in quanto le richieste dei clienti tendono a essere inoltrate ai server data center geograficamente vicini.

Non possiamo dire con certezza chi sarà colpito, quando e dove. consigliamo a tutti i nostri clienti di verificare e rendere i propri servizi già a prova di futuro con largo anticipo rispetto alle possibili fasi di migrazione della CA radice di Google.

Consulta la sezione Come verificare se l'archivio di certificati radice richiede un aggiornamento per ulteriori informazioni guida.

Aspetti da tenere presenti

I client che non sono configurati con il certificato radice necessario non saranno in grado di verificare la connessione TLS a Google Maps Platform. In questo in questi casi, i client emettono in genere un avviso che informa che la convalida non è riuscito.

A seconda della configurazione TLS, i client possono continuare a emettere un Google Maps Platform, o possono rifiutarsi di proseguire con richiesta.

Quali sono i requisiti minimi affinché un client TLS possa comunicare con Google Maps Platform?

I certificati di Google Maps Platform utilizzano DNS Nomi alternativi dell'oggetto (SAN), quindi un la gestione dei certificati da parte del client deve essere in grado di supportare SAN che possono includere un un singolo carattere jolly come etichetta all'estrema sinistra del nome, ad esempio *.googleapis.com.

Per altri requisiti, consulta la sezione Quali sono i requisiti consigliati affinché un client TLS possa comunicare con Google? nelle Domande frequenti su GTS.

Quali tipi di applicazioni rischiano di non funzionare?

L'applicazione utilizza l'archivio dei certificati radice di sistema senza restrizioni imposte dallo sviluppatore

Applicazioni dei servizi web di Google Maps Platform

Se utilizzi un sistema operativo mainstream, ad es. Ubuntu, Red Hat, Windows 10 o Server 2019, OS X) che viene ancora mantenuto e riceve aggiornamenti regolari, l'impostazione predefinita nell'archivio dei certificati radice deve già includere il certificato GTS Root R1.

Se utilizzi una versione precedente del sistema operativo che non riceve più aggiornamenti, puoi: potrebbero non disporre del certificato GTS Root R1. Tuttavia, i certificati radice molto probabilmente conterrà GlobalSign Root CA - R1, uno dei più vecchi e le CA radice più attendibili.

Per le applicazioni mobile che chiamano direttamente i servizi web di Google Maps Platform dal dispositivo dell'utente finale, le linee guida dalla domanda Le app mobile rischiano di non funzionare? .

Applicazioni lato client di Google Maps Platform

Le applicazioni dell'API Maps JavaScript si basano in genere sulla radice certificati del browser web che esegue l'applicazione. Vedi sezione Le applicazioni JavaScript rischiano di interrompersi? per ulteriori dettagli.

Per le app mobile native che utilizzano qualsiasi SDK Maps per Android, Maps SDK for iOS, Places SDK per Android o SDK Places per iOS, valgono le stesse regole che valgono per le app che chiamano Servizi web di Google Maps Platform.

Visualizza domanda Le app mobile rischiano di non funzionare? per ulteriori informazioni.

L'app utilizza il proprio bundle di certificati o funzionalità di sicurezza avanzate, come il blocco dei certificati

Dovrai assicurarti di aggiornare personalmente il bundle di certificati. Come discusso in questione Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice di Google attendibile?, ti consigliamo di importare tutti i certificati pacchetto attendibile di CA radice di Google nel tuo archivio di certificati radice.

Se vuoi bloccare certificati o chiavi pubbliche per i domini Google, all'applicazione, devi aggiungere i certificati e le chiavi pubbliche di entità attendibili nell'applicazione.

Per ulteriori informazioni sul blocco dei certificati o della chiave pubblica, consulta risorse esterne elencate alla domanda Hai bisogno di ulteriori informazioni?.

Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice di Google attendibile?

L'elenco selezionato di CA radice Pacchetto CA radice attendibile di Google include tutte le CA che potrebbero plausibilmente essere utilizzate dai servizi Google nel futuro prevedibile.

Pertanto, se vuoi rendere il tuo sistema a prova di futuro, ti consigliamo vivamente di verifichi che l'archivio dei certificati radice contenga tutti i certificati. dal bundle e prendi l'abitudine di mantenerli sincronizzati.

Ciò è particolarmente importante se i servizi vengono eseguiti su un sistema operativo non mantenuto versione di sistema, perché non riesci a mantenere il sistema operativo e librerie con patch applicate, oppure a gestire il tuo archivio di certificati radice.

Visualizza domanda Come faccio a ricevere un preavviso per le migrazioni future? per scoprire come ricevere aggiornamenti sulle future migrazioni delle CA radice. Di routine mantenendo sincronizzato l'archivio dei certificati radice con l'elenco selezionato per salvaguardare i tuoi servizi da future interruzioni del servizio, dovute a modifiche alle CA e manterranno i servizi in esecuzione oltre la scadenza delle GTS Root R1 Cross e GlobalSign Root CA - R1.

Inoltre, fai riferimento alla domanda Sto creando un prodotto che si collega ai servizi Google. Quali certificati CA devo considerare attendibili? nelle domande frequenti sul GTS per ulteriori consigli.

Perché non devo installare certificati CA foglia o intermedi?

In questo modo rischi di interrompere la richiesta in qualsiasi momento in cui registriamo un nuovo o passare da una CA intermedia. Entrambe le circostanze possono verificarsi in un arco di tempo e senza preavviso, e si applica anche ai singoli server certificati, come quelli pubblicati da maps.googleapis.com, nonché eventuali delle nostre CA intermedie, come GTS Root R1 Cross.

Per proteggere i tuoi servizi da questo comportamento, devi installare solo root certificati da pacchetto attendibile di CA radice di Google e si basa solo sul certificato radice per verificare l'affidabilità l'intera catena di certificati ancorata.

Qualsiasi implementazione moderna della libreria TLS deve essere in grado di verificare automaticamente le catene di attendibilità, purché l'autorità di certificazione radice sia attendibile.

Le applicazioni JavaScript rischiano di interrompersi?

I certificati radice GTS sono già ben incorporati e considerati attendibili dai browser e il simbolo incrociato di GMO GlobalSign dovrebbe garantire anche per la maggior parte degli utenti finali che utilizzano browser legacy. Sono incluse tutte le metriche ufficialmente browser supportati per l'API Maps JavaScript.

Ogni browser moderno dovrebbe consentire agli utenti finali di verificare e modificare certificati affidabili dal browser. Anche se la posizione esatta varia a seconda del caso, browser, l'elenco dei certificati si trova in genere nella sezione Impostazioni.

Le app mobile rischiano di non funzionare?

I dispositivi Android e Apple iOS continuano a ricevere aggiornamenti regolari dal dispositivo produttore sono tenuti a essere a prova di futuro. La maggior parte degli smartphone Android meno recenti includono almeno il certificato GlobalSign Root CA - R1, anche se l'elenco dei certificati attendibili può variare in base al produttore dello smartphone, al modello di dispositivo e Versione di Android.

Tuttavia, il supporto delle CA radice GTS, incluso GTS Root R1, potrebbe comunque essere sono limitate nelle versioni di Android precedenti alla 10.

Per i dispositivi iOS, Apple gestisce un elenco di CA radice attendibili per ogni app iOS recente disponibile nelle relative pagine di assistenza. Tuttavia, tutte le versioni di iOS 5 e successive supportano GlobalSign Root CA - R1.

Le CA radice GTS, tra cui GTS Root R1, sono supportate sin dalla versione iOS 12.1.3.

Visualizza domanda Come faccio a controllare i certificati radice attendibili sul mio telefono cellulare? per ulteriori dettagli.

Quando il mio browser o il mio sistema operativo includerà i certificati radice di Google Trust Services?

Negli ultimi anni, Google ha lavorato a lungo con tutte le principali terze parti il mantenimento di pacchetti di certificati radice utilizzati e attendibili. Tra gli esempi possibili come Apple e Microsoft, ma anche gli sviluppatori di Google i propri team Android e Chrome OS; come Mozilla, Apple, Microsoft, ma anche il team di Chrome di Google; produttori di hardware, come telefoni, decoder, TV, console per videogiochi, stampanti e altro ancora.

È quindi molto probabile che qualsiasi sistema attualmente mantenuto Supporta le nuove CA GTS Root CA, tra cui GTS Root R1, e anche le versioni precedenti è molto probabile che supportino GlobalSign Root CA - R1, che sarà utilizzati per la firma incrociata dei certificati emessi da Google negli anni successivi.

Tuttavia, poiché le tempistiche per l'inclusione dei certificati di terze parti vanno ben oltre le controllo di Google, il miglior consiglio generale che possiamo offrire è assicurarsi applicano regolarmente gli aggiornamenti di sistema disponibili.

Alcune terze parti, ad esempio il CA Certificate Program di Mozilla, potrebbero avere documentato la propria tempistiche di inclusione dei certificati.

Risoluzione dei problemi

Dove posso trovare gli strumenti di cui ho bisogno?

Recupero di curl in corso...

Se la distribuzione del tuo sistema operativo non fornisce curl, puoi scaricarlo da https://curl.haxx.se/. Puoi scaricare il codice sorgente e compilare lo strumento personalmente o scaricare un file binario, se disponibile per la tua piattaforma.

Scaricare OpenSSL

Se la distribuzione del tuo sistema operativo non fornisce openssl, puoi scaricare il codice sorgente da https://www.openssl.org/ e compilare lo strumento. È possibile trovare un elenco di file binari creati da terze parti tramite https://www.openssl.org/community/binaries.html. Tuttavia, nessuna di queste build è supportata o in alcun modo avallato in maniera specifica il team di OpenSSL.

Recupero di Wireshark, Tshark o Tcpdump

Sebbene la maggior parte delle distribuzioni Linux offra wireshark, il suo strumento a riga di comando tshark e tcpdump, le versioni precompilate dei primi due per altri sistemi operativi possono essere disponibile all'indirizzo https://www.wireshark.org.

Il codice sorgente per Tcpdump e libPCAP è disponibile all'indirizzo https://www.tcpdump.org.

La documentazione relativa a questi utili strumenti è disponibile nel Guida dell'utente di Wireshark, sulla pagina Man di Tshark e nella pagina man di Tcpdump, rispettivamente.

Recupero del keytool Java

Lo strumento a riga di comando keytool deve essere fornito con ogni Java Versione di Development Kit (JDK) o Java Runtime Environment (JRE). Installa questi per ottenere keytool.. Tuttavia, è improbabile che l'utilizzo di keytool per la verifica del certificato radice, a meno che la tua applicazione non sia stata creata utilizzando Java.

Cosa fare in caso di interruzione della produzione

La soluzione principale è installare il file certificati da pacchetto CA radice attendibile di Google nell'archivio dei certificati radice utilizzati dall'applicazione.

  1. Collabora con gli amministratori di sistema per eseguire l'upgrade del tuo dei certificati radice.
  2. Consulta queste Domande frequenti per suggerimenti relativi al tuo sistema.
  3. Se hai bisogno di ulteriore assistenza specifica per piattaforma o sistema, contatta il canali di assistenza tecnica offerti dal fornitore del sistema.
  4. Per assistenza generale, contatta il nostro team di assistenza, come descritto in sezione Contattare l'assistenza Google Maps Platform. Nota: per problemi specifici delle piattaforme, le indicazioni vengono fornite soltanto sulla base del massimo impegno base.
  5. Aggiungi il problema pubblico 186840968 per ulteriori aggiornamenti relativi alla migrazione.

Contattare l'assistenza di Google Maps Platform

Risoluzione dei problemi iniziale

Vedi sezione Come verificare se l'archivio di certificati radice richiede un aggiornamento per istruzioni generiche sulla risoluzione dei problemi.

Sezione La gestione dei certificati attendibili potrebbe forniscono anche informazioni preziose, se devi importare o esportare i dati certificati.

Se il problema persiste e decidi di contattare Google Maps Platform ricevere assistenza, è pronto a fornire anche le seguenti informazioni:

  1. Dove si trovano i server interessati?
  2. Quali indirizzi IP Google utilizzi per le chiamate di servizio?
  3. Quali API sono interessate da questo problema?
  4. Quando è iniziato esattamente il problema?

  5. Output dei seguenti comandi:

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

Per istruzioni su come ottenere gli strumenti necessari, vedi la domanda Dove posso trovare gli strumenti di cui ho bisogno?.

Presentazione di una richiesta di assistenza

Segui le istruzioni per Creazione di una richiesta di assistenza sotto Assistenza e risorse per Google Maps Platform.

Quando invii una richiesta di assistenza, oltre ai dati elencati nella sezione Risoluzione dei problemi iniziale, fornisci anche il seguenti:

  • Quali sono i tuoi indirizzi IP pubblici?
  • Qual è l'indirizzo IP pubblico del tuo server DNS?
  • Se possibile, un pacchetto tcpdump o Wireshark acquisisce il protocollo TLS contro https://maps.googleapis.com/ in formato PCAP, utilizzando un lunghezza dello snapshot sufficientemente grande per acquisire l'intero pacchetto senza troncandolo (ad esempio utilizzando -s0 sulle versioni precedenti di tcpdump).
  • Se possibile, estratti di log dal tuo servizio che mostrano la connessione TLS esatta il motivo dell'errore, preferibilmente con informazioni complete sulla catena di certificati del server.

Per istruzioni su come ottenere gli strumenti richiesti, vedi la domanda Dove posso trovare gli strumenti di cui ho bisogno?.

Pubblicazione su un problema pubblico 186840968

Quando si pubblica un commento su un problema pubblico 186840968, includi le informazioni elencate nella sezione Risoluzione dei problemi iniziale.

Come faccio a determinare l'indirizzo pubblico del mio DNS?

Su Linux, puoi eseguire questo comando:

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

Su Windows, puoi utilizzare nslookup interattiva modalità:

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

Come interpretare l'output curl

L'esecuzione di curl con i flag -vvI offre informazioni. Ecco alcune istruzioni per interpretare l'output:

  • Righe che iniziano con "*" visualizza l'output dal sistema negoziato e informazioni sulla terminazione della connessione.
  • Righe che iniziano con ">" visualizzare la richiesta HTTP in uscita curl invia.
  • Righe che iniziano con "<" visualizzare la risposta HTTP che riceve il server.
  • Se il protocollo era HTTPS, la presenza di ">" o "<" implicano handshake TLS riuscito.

Libreria TLS e bundle di certificati radice utilizzati

L'esecuzione di curl con i flag -vvI stampa anche dei certificati radice utilizzati, ma l'output esatto può variare in base al sistema, come mostrato qui.

Output da una macchina Red Hat Linux con curl collegato a NSS può contenere le seguenti righe:

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

L'output da una macchina Ubuntu o Debian Linux può contenere le seguenti righe:

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

Output da una macchina Ubuntu o Debian Linux utilizzando il file PEM del certificato radice di Google fornito utilizzando il flag --cacert può contenere queste righe:

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

User agent

Le richieste in uscita contengono l'intestazione User-Agent, che può fornire informazioni informazioni su curl e sul tuo sistema.

Ecco un esempio da un computer 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: */*
>

handshake TLS non riuscito

Le righe, come quelle in questo esempio di codice, indicano che la connessione è handshake mid-TLS terminato a causa di un certificato del server non attendibile. La anche l'assenza di un output di debug che inizi con > o < Gli indicatori chiari di un tentativo di connessione non riuscito:

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

Handshake TLS riuscito

Un handshake TLS riuscito è indicato dalla presenza di righe dall'aspetto simile a quelli in questo esempio di codice. Il pacchetto di crittografia utilizzato per connessione, così come i dettagli del server accettato. certificato. Inoltre, la presenza di righe che iniziano con > o < indica che il traffico HTTP del payload viene trasmesso correttamente tramite la connessione crittografata 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
…

Come stampare i certificati del server ricevuti in formato leggibile

Supponendo che l'output sia in formato PEM, ad esempio l'output openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, puoi stampare il certificato pubblicato seguendo questi passaggi:

  • Copia l'intero certificato codificato in Base 64, inclusi intestazione e piè di pagina:

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

  • Poi:

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

  • Quindi, incolla i contenuti del buffer di copia nel terminale.

  • Premi il tasto Invio.

Per esempio input e output, consulta la sezione Come stampare certificati PEM in formato leggibile.

Che aspetto hanno i certificati Google incrociati in OpenSSL?

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

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

---
…

Gestione dei certificati attendibili

Come faccio a controllare i certificati radice attendibili sul mio cellulare?

Certificati attendibili Android

Come menzionato nella domanda Le app mobile rischiano di non funzionare?, A partire dalla versione 4.0, Android ha consentito agli utenti di smartphone di verificare l'elenco di e certificati attendibili nella sezione Impostazioni. Questa tabella mostra le Impostazioni esatte percorso menu:

Versione di Android Percorso menu
1,x, 2,x, 3,x N/D
4, 5, 6, 7, 7 Impostazioni > Sicurezza > Credenziali attendibili
8,x, 9 Impostazioni > Sicurezza e Posizione > Crittografia e credenziali > Credenziali attendibili
10+ Impostazioni > Sicurezza > Avanzate > Crittografia e credenziali > Credenziali attendibili

Questa tabella illustra la probabile disponibilità della risorsa radice più critica certificati per versione di Android, basati sulla verifica manuale tramite Android attualmente disponibile Immagini di sistema di dispositivi virtuali (AVD), con riferimento ai ca-certificates AOSP. Cronologia delle versioni del repository Git, dove le immagini di sistema non erano più disponibili:

Versione di Android Radice GTS R1 CA radice GlobalSign - R1 GlobalSign Root R2 (valido fino al 15 dicembre 2021)
2,3, 3,2, 4,x, 5,x, 6,x, 7,x, 8,x, 9
10+

Generalmente non è possibile aggiornare l'archivio dei certificati radice di sistema Android senza un aggiornamento firmware o il rooting del dispositivo. Tuttavia, sulla maggior parte dei dispositivi Android ancora in uso, l'insieme attuale di che forniscano un servizio ininterrotto per più anni oltre la durata effettiva della maggior parte dei dispositivi esistenti.

A partire dalla versione 7.0, Android offre agli sviluppatori di applicazioni un'esperienza per aggiungere certificati attendibili che siano considerati attendibili solo dal loro un'applicazione. Per farlo, raggruppa i certificati con l'applicazione e creando una configurazione personalizzata della sicurezza di rete, come descritto Best practice su Android per la sicurezza e Privacy Configurazione della sicurezza di rete documento di addestramento.

Tuttavia, gli sviluppatori di applicazioni di terze parti non saranno in grado di influire configurazione della sicurezza di rete del traffico proveniente APK Google Play Services, tali sforzi potrebbero fornire solo una soluzione alternativa parziale.

Sui dispositivi legacy meno recenti, l'unica opzione disponibile sarebbe affidarsi a CA aggiunte dagli utenti, installate tramite un criterio di gruppo aziendale applicato alla fine dispositivo dell'utente o dagli stessi utenti finali.

Archivio attendibilità iOS

Sebbene Apple non mostri direttamente il suo insieme predefinito di certificati radice attendibili l'utente dello smartphone, l'azienda dispone di link ai set di CA radice attendibili iOS 5 e versioni successive dagli articoli del Supporto Apple:

Tuttavia, gli eventuali certificati aggiuntivi installati sul dispositivo iOS dovrebbero essere visibile in Impostazioni > Generali > Profilo. Se non vengono se sono installati i certificati, la voce di menu Profilo potrebbe non essere visualizzata.

Questa tabella illustra la disponibilità dei certificati radice più importanti per versione di iOS, in base alle fonti riportate sopra:

Versione iOS Radice GTS R1 CA radice GlobalSign - R1 GlobalSign Root R2 (valido fino al 15 dicembre 2021)
5, 6, 7, 8, 9, 10, 11, 12,0
12.1.3+

Dove si trova l'archivio dei certificati radice di sistema e come faccio ad aggiornarlo?

La posizione dell'archivio dei certificati radice predefinito varia in base al sistema operativo. e la libreria SSL/TLS utilizzata. Tuttavia, nella maggior parte delle distribuzioni Linux, disponibili in uno dei seguenti percorsi:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, versioni precedenti di RHEL e Versioni CentOS
  • /etc/pki/ca-trust/source/anchors e /usr/share/pki/ca-trust-source: Fedora, versioni RHEL e CentOS più recenti
  • /var/lib/ca-certificates: OpenSUSE

Altri percorsi di certificazione possono includere:

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

Alcuni dei certificati in queste directory sono probabilmente link simbolici a file in altre directory.

Archivio certificati radice OpenSSL

Per le applicazioni che utilizzano OpenSSL, è possibile: controllare la posizione configurata dei componenti installati, inclusa quella predefinita dei certificati radice utilizzando il seguente comando:

openssl version -d

Il comando stampa OPENSSLDIR, che corrisponde al livello superiore directory in cui sono disponibili la libreria e le sue configurazioni:

OPENSSLDIR: "/usr/lib/ssl"

L'archivio dei certificati radice si trova nella sottodirectory 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 OpenSSL si basa sull'archivio dei certificati radice di sistema predefinito esempio precedente, controlla la sezione di primo livello Dove si trova l'archivio dei certificati radice di sistema e come faccio ad aggiornarlo? per assicurarti che il bundle dei certificati radice di sistema sia aggiornato.

Per istruzioni su come ottenere openssl, consulta la sezione Recupero di OpenSSL.

Archivio dei certificati radice Java

Le applicazioni Java potrebbero utilizzare il proprio archivio di certificati radice, che su Linux in genere si trova in /etc/pki/java/cacerts o /usr/share/ca-certificates-java, che può essere gestito utilizzando keytool Java a strumento a riga di comando.

Per importare un singolo certificato nel tuo archivio certificati Java, invia il seguente comando:

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

Basta sostituire cert.pem con il file del certificato corrispondente a ogni certificato radice consigliato, alias con un certificato univoco ma significativo e certs.jks con il file del database dei certificati utilizzato in completamente gestito di Google Cloud.

Per ulteriori informazioni, consulta le seguenti risorse articoli:

Archivio certificati radice Mozilla NSS

Applicazioni che utilizzano Mozilla NSS può utilizzare per impostazione predefinita anche un database di certificati a livello di sistema, generalmente in /etc/pki/nssdb o un archivio predefinito specifico dell'utente in ${HOME}/.pki/nssdb.

Per aggiornare il database NSS, utilizza lo strumento certutil.

Per importare un singolo file di certificato nel database NSS, invia il seguente comando:

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

Basta sostituire cert.pem con il file del certificato corrispondente a ogni certificato radice consigliato, cert-name con un certificato significativo nickname e certdir con il percorso del database dei certificati utilizzato completamente gestito di Google Cloud.

Per ulteriori informazioni, consulta il Certutil degli strumenti NNS manuale e la documentazione del sistema operativo.

Archivio certificati radice Microsoft .NET

Gli sviluppatori Windows .NET possono consultare almeno i seguenti articoli Microsoft è utile per aggiornare l'archivio dei certificati radice:

Formati file dei certificati

Che cos'è un file PEM?

PEM (Privacy-Enhanced Mail) è un formato di file testuale standard per l'archiviazione e l'invio di crittografia certificati, chiavi ecc., formalizzati come standard de-jure in RFC 7468.

Mentre il formato file stesso è leggibile, il valore Programma binario codificato in Base64 informazioni sui dati del certificato non lo sono. Tuttavia, la specifica PEM consente emissione testo esplicativo prima o dopo il corpo del certificato codificato in testo e molti strumenti usano di questa funzionalità per fornire anche un riepilogo chiaro dei dati più pertinenti in un certificato.

Puoi utilizzare anche strumenti come openssl per decodificare l'intero certificato in formato leggibile. Vedi sezione Come stampare i certificati PEM in formato leggibile per ulteriori informazioni.

Che cos'è un file ".crt" ?

Strumenti che consentono l'esportazione di certificati in formato PEM comunemente estensione del file ".crt" per indicare che il file utilizza una codifica testuale.

Che cos'è un file DER?

Regole di codifica distinto (DER) è un formato binario standardizzato per i certificati di codifica. Certificati in PEM di file sono in genere Certificati DER con codifica Base64.

Che cos'è un file ".cer" ?

Un file esportato con un ".cer" può contenere un certificato con codifica PEM, ma più tipicamente un certificato binario, di solito con codifica DER. Di convention, ".cer" di solito contengono un solo certificato.

Il mio sistema si rifiuta di importare tutti i certificati da roots.pem

Alcuni sistemi, ad esempio Java keytool, può importare un solo certificato da un file PEM, anche se ne contiene diversi. Visualizza domanda Come faccio a estrarre singoli certificati da roots.pem? per vedere come può essere prima suddiviso il file.

Come faccio a estrarre singoli certificati da roots.pem?

Puoi suddividere roots.pem in certificati che ne fanno parte utilizzando quanto segue script bash semplice:

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

Questa operazione dovrebbe creare una serie di singoli file PEM simili a quelli elencati qui:

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

È quindi possibile importare i singoli file PEM, ad esempio 02265526.pem separatamente o ulteriormente convertita in un formato file nell'archivio certificati accetta.

Come convertire un file PEM in un formato supportato dal mio sistema

Lo strumento a riga di comando del toolkit OpenSSL openssl può essere utilizzato per convertire file tra tutti i certificati di uso comune formati di file. Istruzioni per la conversione da un file PEM a un file di uso comune sono elencati di seguito.

Per un elenco completo delle opzioni disponibili, consulta la Documentazione relativa alle utilità a riga di comando OpenSSL.

Per istruzioni su come ottenere openssl, consulta la sezione Recupero di OpenSSL.

Come faccio a convertire un file PEM nel formato DER?

Con openssl puoi inviare il seguente comando per convertire un file da PEM a DER:

openssl x509 -in roots.pem -outform der -out roots.der
Come posso convertire un file PEM in PKCS #7?

Con openssl puoi inviare il seguente comando per convertire un file da PEM a PKCS n. 7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
Come posso convertire un file PEM in PKCS #12 (PFX)?

Con openssl puoi inviare il seguente comando per convertire un file da PEM a PKCS n. 12:

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

Quando crei un archivio PKCS #12, devi specificare una password per il file. Marca di memorizzare la password in un luogo sicuro, se non importi immediatamente PKCS #12 nel sistema.

Elenco, stampa ed esportazione di certificati dall'archivio certificati radice

Come posso esportare un certificato dall'archivio chiavi Java come file PEM?

Con keytool puoi emettere il seguente comando per elencare tutti certificati nel tuo archivio certificati, insieme all'alias che puoi utilizzare esportali tutti:

keytool -v -list -keystore certs.jks

Devi solo sostituire certs.jks con il file del database dei certificati utilizzato in completamente gestito di Google Cloud. Questo comando mostrerà anche l'alias di ciascun certificato, che ti servirà per esportarlo.

Per esportare un singolo certificato in formato PEM, esegui il comando seguente:

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

Devi solo sostituire certs.jks con il file del database dei certificati utilizzato in e fornisci i valori alias e alias.pem corrispondenti che desideri esportare.

Per ulteriori informazioni, consulta il manuale Java Platform, Standard Edition Tools Reference: keytool.

Come faccio a esportare i certificati dall'archivio dei certificati radice NSS come file PEM?

Con certutil puoi emettere il seguente comando per elencare tutti certificati nell'archivio certificati, insieme al nickname che puoi utilizzare per esportarli singolarmente:

certutil -L -d certdir

Devi solo sostituire certdir con il percorso del database dei certificati utilizzato in completamente gestito di Google Cloud. Questo comando mostra anche il nickname di ogni certificato, che ti servirà per esportarlo.

Per esportare un singolo certificato in formato PEM, esegui il comando seguente:

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

Basta sostituire certdir con il percorso del database dei certificati utilizzato nel tuo ambiente e fornire cert-name e cert.pem corrispondenti al certificato che vuoi esportare.

Per ulteriori informazioni, consulta il Certutil degli strumenti NNS manuale e la documentazione del sistema operativo.

Come stampare certificati PEM in formato leggibile

Nei seguenti esempi presupponiamo che tu abbia il file GTS_Root_R1.pem con i seguenti contenuti:

# 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-----
Stampa dei file dei certificati utilizzando OpenSSL

Emissione del comando

openssl x509 -in GTS_Root_R1.pem -text

dovrebbe restituire un risultato simile a questo:

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
        …

Per istruzioni su come ottenere openssl, consulta la sezione Recupero di OpenSSL.

Stampa di certificati utilizzando keytool Java

Emissione del comando seguente

keytool -printcert -file GTS_Root_R1.pem

dovrebbe restituire un risultato simile a questo:

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

Per istruzioni su come ottenere keytool, consulta la sezione Recupero del keytool Java.

Come posso visualizzare i certificati installati nel mio archivio di certificati radice?

Questa operazione varia in base al sistema operativo e alla libreria SSL/TLS. Tuttavia, gli strumenti che consente di importare ed esportare certificati da e verso i certificati radice .In genere offre anche un'opzione per elencare i certificati installati.

Inoltre, se hai esportato correttamente i certificati radice attendibili in PEM o l'archivio dei certificati radice contiene già file PEM archiviati, prova ad aprire i file in qualsiasi editor di testo, dato che sono in formato di testo normale.

Il file PEM potrebbe essere etichettato correttamente in modo da fornire informazioni leggibili da una persona all'autorità di certificazione associata (ad esempio, pacchetto CA radice attendibile di 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-----

Il file potrebbe anche contenere solo la parte del certificato. In questi casi, il nome del il file, ad esempio GTS_Root_R1.pem potrebbe descrivere a quale CA appartiene il certificato. La stringa del certificato tra i token -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- è inoltre garantita come univoca per ogni CA.

Tuttavia, anche se non disponi degli strumenti di cui sopra, poiché ogni certificato il bundle CA radice di Google attendibile è etichettate correttamente, puoi associare in modo affidabile le CA radice dell'account aganist del bundle quelle dei tuoi certificati radice sono archiviate da Issuer o confrontando Stringhe dei certificati dei file PEM.

I browser web possono utilizzare il proprio archivio di certificati radice o affidarsi allo fornita dall'operatore. Tuttavia, tutti i browser moderni dovrebbero consentirti gestire o almeno visualizzare l'insieme di CA principali che considerano attendibili. Visualizza domanda Le applicazioni JavaScript rischiano di interrompersi? per ulteriori dettagli.

Per istruzioni specifiche per i telefoni cellulari, vedi la domanda separata Come faccio a controllare i certificati radice attendibili sul mio telefono cellulare?

Appendice

Per maggiori informazioni,

Fai sempre affidamento principalmente sulla documentazione del tuo sistema operativo, del linguaggio o dei linguaggi di programmazione dell'applicazione, oltre alla documentazione eventuali librerie esterne utilizzate dall'applicazione.

Qualsiasi altra fonte di informazioni incluse le presenti Domande frequenti potrebbe essere obsoleta o sono altrimenti errate e non devono essere considerate autorevoli. Tuttavia, trovare comunque informazioni utili su molti dei Community di domande e risposte di Stack Exchange, nonché siti come AdamW su Linux e altro e il blog di conferma, tra gli altri.

Consulta anche Domande frequenti su Google Trust Services.

Per ulteriori dettagli sugli argomenti avanzati, come il blocco dei certificati, puoi trova l'Open Web Application Security Project (OWASP) Blocco del certificato e della chiave pubblica in questo articolo e Scheda di riferimento per il blocco informativi. Per istruzioni specifiche per Android, consulta il Best practice su Android per la sicurezza e Privacy Sicurezza con HTTPS e SSL documento di addestramento. Per discussioni sul confronto tra certificati e blocco della chiave pubblica su Android, potresti trovare il post del blog di Matthew Dolan Sicurezza Android: blocco SSL utile.

Le best practice di Android per la sicurezza e Formazione sulla configurazione della sicurezza della rete per la privacy documento e post del blog di JeroenHD Android 7 Nougat e autorità di certificazione fornire ulteriori informazioni sulla gestione di certificati attendibili aggiuntivi su Android.

Per un elenco completo delle CA radice attendibili da AOSP, consulta le certificati ca un repository Git. Per tutte le versioni basate su fork di Android non ufficiali, ad esempio LineageOS, fai riferimento ai repository appropriati forniti dal fornitore del sistema operativo.