Domande frequenti sulla migrazione della CA radice di Google Maps Platform

Il presente documento si articola nelle seguenti sezioni:

Per una panoramica più dettagliata, consulta la sezione Di cosa si tratta?.

Terminologia

Di seguito, abbiamo raccolto un elenco dei termini più importanti che devi conoscere per questo documento. Per una panoramica più completa della terminologia correlata, consulta le domande frequenti (FAQ) di Google Trust Services.

Certificato TLS/SSL
Un certificato associa una chiave crittografica a un'identità.
I certificati TLS/SSL vengono utilizzati per autenticare e stabilire connessioni sicure ai siti web. I certificati vengono emessi e firmati crittograficamente da entità note come autorità di certificazione.
I browser si basano su certificati emessi da autorità di certificazione attendibili per sapere che le informazioni trasmesse vengono inviate al server corretto e che sono criptate durante il transito.
Secure Sockets Layer (SSL)
Secure Sockets Layer era il protocollo più ampiamente implementato utilizzato per crittografare le comunicazioni internet. Il protocollo SSL non è più considerato sicuro e non è più supportato sui servizi Google.
Transport Layer Security (TLS)
Transport Layer Security è il successore di SSL.
Autorità di certificazione (CA)
Un'autorità di certificazione è come un ufficio passaporti digitale per dispositivi e persone. Emette documenti protetti crittograficamente (certificati) per attestare che un'entità (ad es. un sito web) è chi afferma di essere.
Prima di emettere un certificato, le CA sono responsabili della verifica che i nomi nel certificato siano collegati alla persona o all'entità che lo richiede.
Il termine Autorità di certificazione può riferirsi sia a organizzazioni come Google Trust Services sia a sistemi che emettono certificati.
Infrastruttura a chiave pubblica (PKI)
L'infrastruttura a chiave pubblica è un insieme di tecnologie, norme e procedure che consentono a un'autorità di certificazione di verificare l'identità di un richiedente di certificato, produrre un certificato che attesti tale verifica e consentono agli utenti di internet di fare affidamento sul certificato.
La crittografia con chiave pubblica è la tecnologia che lo rende possibile
La PKI viene utilizzata anche sulle reti interne, ma il suo caso d'uso più comune è quello di abilitare la comunicazione criptata sul web. I browser web considerano attendibili i certificati emessi dalle CA incluse nel loro archivio di certificati radice.
Crittografia a chiave pubblica
La crittografia a chiave pubblica è una forma di crittografia che utilizza coppie di chiavi. Una delle chiavi è considerata pubblica e può essere distribuita ampiamente, l'altra è considerata privata e deve essere mantenuta segreta.
I dati criptati con una chiave pubblica possono essere decriptati con la chiave privata corrispondente e viceversa.
Ciò consente di utilizzare i concetti di firma digitale e crittografia a chiave pubblica, che sono i blocchi di base di protocolli come TLS, in cui due parti possono autenticarsi a vicenda e condividere dati criptati senza scambiarsi in precedenza informazioni segrete.
Archivio dei certificati radice (o truststore)
Un archivio di certificati radice contiene un insieme di autorità di certificazione considerate attendibili da un fornitore di software applicativo. La maggior parte dei browser web e dei sistemi operativi dispone di un proprio archivio di certificati radice.
Per essere inclusa in un archivio di certificati radice, l'autorità di certificazione deve soddisfare i rigorosi requisiti stabiliti dal fornitore di software applicativo.
In genere, questi includono la conformità agli standard di settore, come i requisiti del CA/Browser Forum.
Autorità di certificazione radice
Un'autorità di certificazione radice (o più correttamente, il suo certificato) è il certificato di primo livello in una catena di certificati.
I certificati CA radice sono in genere autofirmati. Le chiavi private associate vengono archiviate in strutture altamente sicure e mantenute offline per proteggerle 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 di certificati online, consentendo al contempo al certificato CA radice di rimanere offline.
Le CA intermedie sono note anche come CA subordinate.
Autorità di certificazione emittente
Un'autorità di certificazione emittente, o più correttamente il suo certificato, è il certificato utilizzato per firmare il certificato più in basso in una catena di certificati.
Questo certificato più in basso è comunemente chiamato certificato dell'abbonato, certificato dell'entità finale o certificato foglia. In questo documento utilizzeremo anche il termine certificato server.
Catena di certificati
I certificati sono collegati (firmati crittograficamente) al loro emittente. Una catena di certificati è composta da un certificato dell'entità finale, da tutti i suoi certificati emittenti e da un certificato radice.
Firma incrociata
I clienti dei fornitori di software applicativi devono aggiornare il proprio archivio di certificati radice per includere nuovi certificati CA in modo che siano considerati attendibili dai loro prodotti. È necessario 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, i certificati CA possono essere "cross-signed" da un'altra CA meno recente. In questo modo viene creato un secondo certificato CA per la stessa identità (coppia di nome e chiave).
A seconda delle CA incluse nel loro archivio di certificati radice, i client creeranno una catena di certificati diversa fino a una radice attendibile.

Informazioni generali

Che cosa significa?

Riepilogo: se non segui le indicazioni riportate all'indirizzo https://pki.goog/faq/#connecting-to-google, è molto probabile che in futuro si verifichino interruzioni del servizio correlate ai certificati.

Introduzione

Nel 2017, Google ha avviato un progetto pluriennale per emettere e utilizzare i propri certificati root, le firme crittografiche alla base della sicurezza di internet TLS utilizzata da HTTPS.

Dopo la prima fase, la sicurezza TLS dei servizi Google Maps Platform è stata fornita da GS Root R2, un'autorità di certificazione (CA) radice molto nota e ampiamente attendibile, che Google ha acquisito da GMO GlobalSign per facilitare la transizione alle nostre CA radice Google Trust Services (GTS) autoemesse.

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

Tuttavia, una CA per progettazione NON deve emettere certificati validi oltre la data di scadenza del proprio certificato. Poiché GS Root R2 è scaduto il 15 dicembre 2021, Google ha eseguito 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 stragrande maggioranza dei sistemi operativi moderni e delle librerie client TLS consideri già attendibili le CA radice GTS, per garantire una transizione senza problemi anche per la maggior parte dei sistemi legacy, Google ha acquisito una firma incrociata da GMO GlobalSign utilizzando GlobalSign Root CA - R1, una delle CA radice più antiche e attendibili disponibili.

Pertanto, la maggior parte dei client Google Maps Platform dei clienti dovrebbe già riconoscere una o entrambe queste CA radice affidabili e non dovrebbe essere stata interessata dalla seconda fase della migrazione.

Ciò vale anche per i clienti che hanno intrapreso azioni durante la prima fase della migrazione nel 2018, supponendo che all'epoca abbiano seguito le nostre istruzioni, installando tutti i certificati dal nostro bundle di CA radice attendibili di Google e devono controllare gli aggiornamenti di questo file e aggiornare l'archivio attendibile almeno una volta ogni 6 mesi.

Se hai problemi di connessione ai servizi Google Maps Platform, devi verificare i tuoi sistemi se si verifica quanto segue:

  • i tuoi servizi eseguono piattaforme non standard o legacy oppure gestisci il tuo archivio di certificati root
  • non hai intrapreso alcuna azione nel 2017-2018, durante la prima fase della migrazione della CA radice di Google, o non hai installato l'intero set di certificati dal bundle CA radice attendibile di Google

Se quanto sopra si applica, i tuoi client potrebbero dover essere aggiornati con i certificati root consigliati per poter garantire l'utilizzo ininterrotto di Google Maps Platform durante questa fase della migrazione.

Per ulteriori dettagli tecnici, continua a leggere. Per istruzioni generali, consulta la sezione Come verificare se l'archivio dei certificati root deve essere aggiornato.

Ti consigliamo inoltre di continuare a mantenere sincronizzati gli archivi dei certificati radice con il bundle di CA radice curato sopra indicato per proteggere i tuoi servizi da futuri cambiamenti della CA radice. Tuttavia, queste modifiche verranno annunciate in anticipo. Consulta le sezioni Come faccio a ricevere aggiornamenti su questa fase di migrazione? e Come posso ricevere una notifica anticipata delle migrazioni future? per ulteriori istruzioni su come rimanere informato.

Riepilogo tecnico

Come annunciato il 15 marzo 2021 sul blog di Google Security, GS Root R2, la CA radice di Google Maps Platform utilizzata dall'inizio del 2018 è scaduta il 15 dicembre 2021. Pertanto, Google eseguirà la migrazione a una CA GTS Root R1 Cross appena emessa.

Quasi tutti i sistemi e i client TLS moderni sono già preconfigurati con il certificato GTS Root R1 o dovrebbero riceverlo dai normali aggiornamenti software, e GlobalSign Root CA - R1 dovrebbe essere disponibile anche sui sistemi legacy meno recenti.

Tuttavia, devi verificare i tuoi sistemi almeno se si verificano entrambi i seguenti punti:

  • i tuoi servizi vengono eseguiti su piattaforme non standard o legacy oppure gestisci il tuo archivio di certificati radice
  • non hai intrapreso alcuna azione nel 2017-2018, durante la prima fase della migrazione della CA radice di Google, o non hai installato l'intero set di certificati dal bundle CA radice attendibile di Google

Come verificare se l'archivio dei certificati radice deve essere aggiornato fornisce indicazioni per verificare se il tuo sistema sarà interessato.

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

Come faccio a ricevere aggiornamenti su questa fase di migrazione?

Aggiungi a Speciali il problema pubblico 186840968 per ricevere aggiornamenti. Queste domande frequenti vengono aggiornate anche durante il processo di migrazione, ogni volta che incontriamo argomenti che potrebbero essere di interesse generale.

Come faccio a ricevere una notifica anticipata delle migrazioni future?

I nuovi certificati radice verranno annunciati all'indirizzo https://pki.goog/updates/ e c'è un feed RSS a cui puoi iscriverti per ricevere notifiche sugli aggiornamenti. Annunciamo solo le nuove radici. Le modifiche alla catena di certificati che comportano il passaggio tra radici consolidate non vengono annunciate e possono avvenire in qualsiasi momento. Non devi eseguire il pinning a una singola root o a un singolo intermedio e devi considerare attendibile l'intero insieme di root Google trattate in https://pki.goog/faq/#connecting-to-google se vuoi garantire connessioni affidabili a Google.

Ti suggeriamo di seguire il blog sulla sicurezza di Google. Ci impegneremo inoltre ad aggiornare la documentazione specifica del prodotto il prima possibile, dopo l'annuncio pubblico sul blog.

Iscriviti anche alle notifiche di Google Maps Platform, in quanto pubblichiamo regolarmente aggiornamenti sul forum in merito a modifiche che potrebbero interessare un numero maggiore di clienti.

Utilizziamo più servizi Google. La migrazione della CA radice interesserà tutti i certificati?

Sì, la migrazione della CA radice avverrà in tutti i servizi e le API di Google, ma la tempistica potrebbe variare in base al servizio. Tuttavia, una volta verificato che gli archivi dei certificati radice utilizzati dalle applicazioni client Google Maps Platform contengono tutte le CA elencate nel bundle di CA radice attendibili di Google, i tuoi servizi non dovrebbero essere interessati dalla migrazione in corso e la sincronizzazione (almeno una volta ogni 6 mesi) ti proteggerà anche da future modifiche alle CA radice.

Per ulteriori informazioni, consulta 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 non funzionare?.

Come verificare se l'archivio dei certificati radice deve essere aggiornato di seguito sono riportate anche istruzioni generali per testare il sistema.

Come verificare se l'archivio dei certificati root deve essere aggiornato

Testa l'ambiente dell'applicazione rispetto a tutte le radici nella sezione "Root CA" di https://pki.goog/repository/

In genere, il tuo sistema sarà compatibile con le modifiche alla CA principale se:

  • il tuo servizio viene eseguito su un sistema operativo mainstream gestito e hai mantenuto aggiornati sia il sistema operativo sia le librerie utilizzate dal tuo servizio e non gestisci il tuo archivio di certificati root, oppure:
  • hai seguito i nostri consigli precedenti e hai installato tutte le CA radice dal bundle di CA radice attendibili di Google e continui ad aggiornare regolarmente l'archivio attendibile.

I clienti potenzialmente interessati devono installare immediatamente i certificati dal bundle CA radice attendibile di Google per evitare future interruzioni del servizio.

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

Esiste uno strumento che posso utilizzare per verificare il nostro archivio di certificati root?

Potresti trovare utili due strumenti a riga di comando curl e openssl nelle tue indagini. Entrambi sono disponibili sulla maggior parte delle piattaforme e offrono numerose opzioni per testare la configurazione.

Per istruzioni su come ottenere curl, vedi la sezione Ottenere 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, esegui l'upgrade o modifica questi comandi in base alle esigenze della tua versione. Per istruzioni su come ottenere openssl, consulta la sezione Ottenere OpenSSL di seguito.

Troverai altri strumenti utili nella sezione Dove posso trovare gli strumenti che mi servono? di seguito.

Per istruzioni di test concrete, vedi Come verificare se l'archivio dei certificati root deve essere aggiornato.

Test dell'archivio dei certificati radice predefiniti

Questo esempio è per GTS R1. I test devono essere eseguiti su tutte le radici GTS.

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

Verificare il bundle di CA radice attendibili di Google

Scarica il bundle di CA radice attendibili di Google, poi 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; \

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

  1. La prima fase (migrazione a GS Root R2), annunciata a gennaio 2017, è iniziata alla fine del 2017 e si è conclusa nella prima metà del 2018.
  2. La seconda fase (migrazione a GTS Root R1 Cross) è stata annunciata a marzo 2021 ed è stata implementata nei mesi precedenti la scadenza di GS Root R2 il 15 dicembre 2021.

Le pianificazioni delle nuove radici verranno annunciate con largo anticipo rispetto alle future scadenze dei certificati, ma le transizioni tra le radici esistenti non verranno annunciate.

Prepara le tue app per il futuro mantenendo il tuo archivio di certificati radice sincronizzato con l'elenco curato di CA radice nel bundle di CA radice attendibili di Google.

Per ulteriori informazioni, consulta anche la domanda Perché devo mantenere sincronizzato l'archivio dei certificati radice con il bundle di CA radice attendibili di Google?.

Piano di implementazione generale per ogni servizio Google

  1. L'implementazione graduale inizia in un singolo data center.
  2. L'implementazione viene gradualmente estesa a più data center fino a raggiungere una copertura globale.
  3. Se vengono rilevati problemi gravi in qualsiasi fase, i test possono essere temporaneamente annullati mentre i problemi vengono risolti.
  4. In base ai feedback delle iterazioni precedenti, vengono inclusi ulteriori servizi Google nell'implementazione fino a quando tutti i servizi Google non saranno migrati ai nuovi certificati.

Chi sarà interessato, quando e dove?

Un numero crescente di sviluppatori della piattaforma Google Maps inizierà a ricevere i nuovi certificati man mano che vengono migrati i nuovi data center. Le modifiche saranno in parte localizzate, in quanto le richieste dei client tendono a essere inoltrate a server in data center geograficamente vicini.

Poiché non possiamo dire con certezza in anticipo chi sarà interessato, quando e dove, consigliamo a tutti i nostri clienti di verificare e proteggere i propri servizi con largo anticipo rispetto alle possibili fasi di migrazione della CA radice di Google.

Consulta la sezione Come verificare se l'archivio dei certificati root deve essere aggiornato per ulteriori indicazioni.

Aspetti a cui prestare attenzione

I client non configurati con il certificato radice necessario non saranno in grado di verificare la connessione TLS a Google Maps Platform. In questa situazione, i client in genere emettono un avviso che indica che la convalida del certificato non è riuscita.

A seconda della configurazione TLS, i client potrebbero continuare a emettere una richiesta di Google Maps Platform oppure potrebbero rifiutarsi di continuare con la richiesta.

Quali sono i requisiti minimi per un client TLS per comunicare con Google Maps Platform?

I certificati Google Maps Platform utilizzano nomi alternativi del soggetto (SAN) DNS, pertanto la gestione dei certificati di un client deve essere in grado di supportare SAN che possono includere un singolo carattere jolly come etichetta più a sinistra nel nome, ad esempio *.googleapis.com.

Sebbene le versioni precedenti di TLS 1.0 e 1.1 siano ancora supportate, sconsigliamo di utilizzarle e consigliamo di utilizzare TLS 1.3, se possibile.

Per altri requisiti e consigli, consulta le sezioni Quali sono i requisiti consigliati per un client TLS per comunicare con Google? e Perché molti servizi Google consentono ancora connessioni che utilizzano TLS 1.0 e TLS 1.1? nelle domande frequenti di GTS.

Quali tipi di applicazioni rischiano di non funzionare più?

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

Applicazioni di servizi web Google Maps Platform

Se utilizzi un sistema operativo mainstream ancora gestito e che riceve aggiornamenti regolari, l'archivio dei certificati radice predefinito dovrebbe già includere i certificati radice GTS.

Se utilizzi una versione precedente del sistema operativo che non riceve più aggiornamenti, potresti avere o meno i certificati radice GTS. Tuttavia, l'archivio dei certificati radice conterrà molto probabilmente GlobalSign Root CA - R1, una delle CA radice più vecchie e ampiamente attendibili, utilizzata per la firma incrociata delle CA radice GTS quando necessario.

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

Applicazioni Google Maps Platform lato client

Le applicazioni API Maps JavaScript in genere si basano sui certificati root del browser web che esegue l'applicazione. Per ulteriori dettagli, consulta la sezione Le applicazioni JavaScript rischiano di non funzionare più?.

Per le applicazioni mobile che utilizzano uno qualsiasi degli SDK Maps per Android, SDK Maps per iOS, Places SDK for Android o Places SDK for iOS, si applicano le stesse regole delle app che chiamano i servizi web Google Maps Platform.

Per maggiori dettagli, consulta la domanda Le app mobile rischiano di non funzionare più?.

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

Dovrai assicurarti di aggiornare personalmente il bundle di certificati. Come spiegato nella domanda Perché devo mantenere sincronizzato il mio archivio di certificati radice con il bundle di CA radice attendibili di Google?, ti consigliamo di importare tutti i certificati dal bundle di CA radice attendibili di Google nel tuo archivio di certificati radice e di aggiornarlo regolarmente.

Google sconsiglia di bloccare certificati o chiavi pubbliche per i domini Google a cui si connette la tua applicazione. Se lo spillo si rompe, il rischio di rottura è elevato.

Per ulteriori informazioni sul pinning di certificati o chiavi pubbliche, consulta le risorse esterne elencate nella domanda Hai bisogno di maggiori informazioni?.

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

L'elenco selezionato di CA radice nel bundle di CA radice attendibili di Google include tutte le CA che potrebbero essere plausibilmente utilizzate dai servizi Google nel prossimo futuro.

Pertanto, se vuoi proteggere il tuo sistema per il futuro, ti consigliamo vivamente di verificare che l'archivio dei certificati radice contenga tutti i certificati del bundle e di sincronizzare regolarmente i due archivi almeno una volta ogni sei mesi.

Ciò è particolarmente importante se i tuoi servizi vengono eseguiti su una versione del sistema operativo non gestita, se per altri motivi non riesci a mantenere aggiornati il sistema operativo e le librerie o se gestisci il tuo archivio di certificati root.

Consulta la domanda Come posso ricevere una notifica anticipata delle migrazioni future? per scoprire come ricevere aggiornamenti sulle future migrazioni delle CA radice. Mantenere regolarmente il tuo archivio di certificati radice sincronizzato con l'elenco curato proteggerà i tuoi servizi da future interruzioni del servizio dovute a modifiche della CA e li manterrà in esecuzione oltre la scadenza di GTS Root R1 Cross e GlobalSign Root CA - R1.

Fai riferimento anche alla domanda Sto creando un prodotto che si connette ai servizi Google. Quali certificati CA devo considerare attendibili? Consulta le domande frequenti di GTS per ulteriori consigli.

Perché non dovrei installare certificati CA intermedi o foglia?

In questo modo, rischi di interrompere il funzionamento della tua applicazione ogni volta che registriamo un nuovo certificato o cambiamo le CA intermedie. Entrambe le operazioni possono verificarsi in qualsiasi momento e senza preavviso e si applicano in egual misura ai singoli certificati del server, come quelli forniti da maps.googleapis.com, nonché a qualsiasi delle nostre CA intermedie, come GTS Root R1 Cross.

Per proteggere i tuoi servizi da questo problema, devi solo installare i certificati radice dal bundle CA radice attendibile di Google e fare affidamento solo sul certificato radice per verificare l'attendibilità dell'intera catena di certificati ancorata.

Qualsiasi implementazione moderna della libreria TLS dovrebbe essere in grado di verificare automaticamente queste catene di attendibilità, a condizione che l'autorità di certificazione radice sia attendibile.

Le applicazioni JavaScript rischiano di non funzionare più?

I certificati root GTS sono già ben integrati e considerati attendibili dalla maggior parte dei browser moderni e la firma incrociata di GlobalSign dovrebbe garantire una migrazione senza problemi anche per la maggior parte degli utenti finali che utilizzano browser legacy. Sono inclusi tutti i browser supportati ufficialmente per l'API Maps JavaScript.

Tutti i browser moderni dovrebbero consentire agli utenti finali di verificare e, in genere, modificare i certificati considerati attendibili dal browser. Sebbene la posizione esatta vari a seconda del browser, l'elenco dei certificati si trova in genere in Impostazioni.

Le app mobile rischiano di non funzionare più?

Anche i dispositivi Android e Apple iOS che ricevono ancora aggiornamenti regolari dal produttore del dispositivo dovrebbero essere a prova di futuro. La maggior parte dei modelli di smartphone Android meno recenti include almeno il certificato GlobalSign Root CA - R1, anche se l'elenco dei certificati attendibili può variare in base al produttore dello smartphone, al modello del dispositivo e alla versione di Android.

Tuttavia, il supporto per le CA radice GTS, inclusa GTS Root R1, potrebbe essere ancora limitato nelle versioni di Android precedenti alla 10.

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

Le CA radice GTS, inclusa GTS Root R1, sono supportate a partire dalla versione iOS 12.1.3.

Per ulteriori dettagli, consulta la domanda Come posso controllare i certificati root attendibili sul mio cellulare?.

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

Negli ultimi anni, Google ha collaborato intensamente con tutte le principali terze parti che gestiscono bundle di certificati radice attendibili e ampiamente utilizzati. Alcuni esempi includono produttori di sistemi operativi, come Apple e Microsoft, ma anche i team Android e ChromeOS di Google; sviluppatori di browser, come Mozilla, Apple, Microsoft, ma anche il team Chrome di Google; produttori di hardware, come smartphone, set-top box, TV, console per videogiochi, stampanti, solo per citarne alcuni.

È quindi molto probabile che qualsiasi sistema gestito attivamente supporti già le CA radice di GTS e che anche i sistemi legacy supportino GlobalSign Root CA - R1, che verrà utilizzata per la firma incrociata di molti certificati emessi da Google nei prossimi anni.

Tuttavia, poiché le tempistiche di inclusione dei certificati di terze parti sono in gran parte al di fuori del controllo di Google, il miglior consiglio generale che possiamo offrire è di assicurarsi di applicare regolarmente gli aggiornamenti di sistema disponibili.

Alcune terze parti, come il programma di certificazione CA di Mozilla, potrebbero aver documentato le proprie tempistiche di inclusione dei certificati.

Risoluzione dei problemi

Dove posso trovare gli strumenti di cui ho bisogno?

Ottenere curl

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

Ottenere OpenSSL

Se la tua distribuzione del sistema operativo non fornisce openssl, puoi scaricare l'origine da https://www.openssl.org/ e compilare lo strumento. Un elenco di file binari creati da terze parti è disponibile all'indirizzo https://www.openssl.org/community/binaries.html. Tuttavia, nessuna di queste build è supportata o approvata in modo specifico dal team di OpenSSL.

Ottenere Wireshark, Tshark o Tcpdump

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

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

La documentazione di questi utili strumenti è disponibile nella Guida per l'utente di Wireshark, nella pagina man di Tshark e nella pagina man di Tcpdump, rispettivamente.

Ottenere Keytool Java

Lo strumento a riga di comando keytool deve essere fornito con ogni versione di Java Development Kit (JDK) o Java Runtime Environment (JRE). Installa questi per ottenere keytool.. Tuttavia, l'utilizzo di keytool è probabilmente necessario per la verifica dei certificati radice, a meno che l'applicazione non sia creata utilizzando Java.

Cosa fare in caso di interruzione della produzione

L'azione principale da intraprendere è installare i certificati radice richiesti dal bundle CA radice attendibile di Google nell'archivio dei certificati radice utilizzato dall'applicazione.

  1. Collabora con gli amministratori di sistema per eseguire l'upgrade dell'archivio dei certificati root locali.
  2. Consulta queste domande frequenti per suggerimenti applicabili al tuo sistema.
  3. Se hai bisogno di ulteriore assistenza specifica per la piattaforma o il sistema, contatta i canali di assistenza tecnica offerti dal tuo fornitore di sistema.
  4. Per assistenza generale, contatta il nostro team di assistenza, come descritto nella sezione Contattare l'assistenza di Google Maps Platform. Nota: per i problemi specifici della piattaforma, le indicazioni vengono fornite solo in base alle migliori possibilità.

  5. Segnala il problema pubblico 186840968 per ulteriori aggiornamenti relativi alla migrazione.

    Contattare l'assistenza Google Maps Platform

Risoluzione dei problemi iniziale

Consulta la sezione Come verificare se l'archivio dei certificati root deve essere aggiornato per istruzioni generiche per la risoluzione dei problemi.

La sezione Gestione dei certificati attendibili può fornire informazioni utili anche se devi importare o esportare certificati radice.

Se il problema persiste e decidi di contattare l'assistenza di Google Maps Platform, preparati a fornire anche le seguenti informazioni:

  1. Dove si trovano i server interessati?
  2. Quali indirizzi IP Google chiama il tuo servizio?
  3. Quali API sono interessate da questo problema?
  4. Quando esattamente ha iniziato a verificarsi 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.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.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 creare una richiesta di assistenza in Assistenza e risorse di Google Maps Platform.

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

  • Quali sono i tuoi indirizzi IP pubblici?
  • Qual è l'indirizzo IP pubblico del tuo server DNS?
  • Se possibile, un dump TCP o un'acquisizione di pacchetti Wireshark della negoziazione TLS non riuscita rispetto a https://maps.googleapis.com/ in formato PCAP, utilizzando una lunghezza dello snapshot sufficientemente grande da acquisire l'intero pacchetto senza troncarlo (ad es. utilizzando -s0 nelle versioni precedenti di tcpdump).
  • Se possibile, estratti dei log del servizio che mostrano il motivo esatto dell'errore di connessione TLS, preferibilmente con informazioni complete sulla catena di certificati del server.

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

Post sul problema pubblico 186840968

Quando pubblichi un commento sul 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 il seguente comando:

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

Su Windows puoi utilizzare nslookup in modalità interattiva: 

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

Come interpretare l'output di curl

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

  • Le righe che iniziano con "*" mostrano l'output della negoziazione TLS, nonché le informazioni sulla chiusura della connessione.
  • Le righe che iniziano con ">" mostrano la richiesta HTTP in uscita inviata da curl.
  • Le righe che iniziano con "<" mostrano la risposta HTTP ricevuta dal server.
  • Se il protocollo era HTTPS, la presenza delle righe ">" o "<" implica un handshake TLS riuscito.

Libreria TLS e bundle di certificati radice utilizzati

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

L'output di una macchina Red Hat Linux con curl collegato a NSS potrebbe contenere queste righe:

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

L'output di una macchina Ubuntu o Debian Linux potrebbe contenere queste righe:

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

L'output di una macchina Ubuntu o Debian Linux che utilizza il file PEM del certificato root 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 utili su curl e sul tuo sistema.

Esempio da una macchina 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 è stata terminata a metà dell'handshake TLS a causa di un certificato del server non attendibile. L'assenza di output di debug che inizia con > o < è anche un forte indicatore 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

L'handshake TLS riuscito è indicato dalla presenza di righe simili a quelle di questo esempio di codice. Devono essere elencate la suite di crittografia utilizzata per la connessione criptata e i dettagli del certificato del server accettato. Inoltre, la presenza di righe che iniziano con > o < indica che il traffico HTTP del payload viene trasmesso correttamente tramite la connessione criptata 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 formattato in formato PEM, ad esempio l'output di openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, puoi stampare il certificato pubblicato seguendo questi passaggi:

  • Copia l'intero certificato con codifica Base64, inclusi intestazione e piè di pagina:

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

  • Poi:

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

  • Poi incolla i contenuti del buffer di copia nel terminale.

  • Premi il tasto Invio.

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

Che aspetto hanno i certificati Google con firma incrociata in OpenSSL?

{# disableFinding(LINE_OVER_80)}

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

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

---
…

Gestire i certificati attendibili

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

Certificati attendibili di Android

Come indicato nella domanda Le app mobile rischiano di smettere di funzionare?, A partire dalla versione 4.0, Android consente agli utenti di smartphone di verificare l'elenco dei certificati attendibili in Impostazioni. Questa tabella mostra il percorso esatto del menu Impostazioni:

Versione di Android Percorso del menu
1.x, 2.x, 3.x N/D
4.x, 5.x, 6.x, 7.x 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 disponibilità probabile dei certificati root più critici per versione di Android, in base alla verifica manuale utilizzando le immagini di sistema Android Virtual Device (AVD) disponibili, con fallback alla cronologia delle versioni del repository Git ca-certificates AOSP, in cui le immagini di sistema non erano più disponibili:

Versione di Android GTS Root R1 GlobalSign Root CA - 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+

L'aggiornamento dell'archivio dei certificati root del sistema Android in genere non è possibile senza un aggiornamento firmware o il rooting del dispositivo. Tuttavia, nella maggior parte delle versioni di Android ancora in uso, l'attuale insieme di certificati root attendibili probabilmente fornirà un servizio ininterrotto per molti anni a venire, oltre la durata effettiva della maggior parte dei dispositivi esistenti.

A partire dalla versione 7.0, Android offre agli sviluppatori di applicazioni un metodo sicuro per aggiungere certificati attendibili che sono attendibili solo dalla loro applicazione. A questo scopo, i certificati vengono raggruppati con l'applicazione e viene creata una configurazione della sicurezza di rete personalizzata, come descritto nel documento di formazione Best practice per la sicurezza e la privacy di Android Configurazione della sicurezza di rete.

Tuttavia, poiché gli sviluppatori di applicazioni di terze parti non potranno influire sulla configurazione della sicurezza di rete del traffico proveniente dall'APK di Google Play Services, questi sforzi probabilmente forniranno solo una soluzione alternativa parziale.

Sui dispositivi legacy meno recenti, l'unica opzione disponibile è affidarsi alle CA aggiunte dagli utenti, installate da un criterio di gruppo aziendale applicato al dispositivo dell'utente finale o dagli utenti finali stessi.

Archivio attendibilità iOS

Apple non mostra direttamente il suo insieme predefinito di certificati radice attendibili all'utente del dispositivo mobile. L'azienda fornisce link agli insiemi di CA radice attendibili per iOS versione 5 e successive negli articoli del supporto Apple:

Tuttavia, tutti i certificati aggiuntivi installati sul dispositivo iOS dovrebbero essere visibili in Impostazioni > Generali > Profilo. Se non sono installati certificati aggiuntivi, la voce di menu Profilo potrebbe non essere visualizzata.

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

Versione iOS GTS Root R1 GlobalSign Root CA - 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 posso aggiornarlo?

La posizione dell'archivio dei certificati root predefiniti varia in base al sistema operativo e alla libreria SSL/TLS utilizzata. Tuttavia, nella maggior parte delle distribuzioni Linux, i certificati root predefiniti si trovano in uno dei seguenti percorsi:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, versioni precedenti di RHEL e CentOS
  • /etc/pki/ca-trust/source/anchors e /usr/share/pki/ca-trust-source: Fedora, versioni più recenti di RHEL e CentOS
  • /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 dei certificati radice OpenSSL

Per le applicazioni che utilizzano OpenSSL, puoi controllare la posizione configurata dei componenti installati, incluso l'archivio dei certificati root predefinito, utilizzando il comando seguente:

openssl version -d

Il comando stampa OPENSSLDIR, che corrisponde alla directory di primo livello in cui si trovano la libreria e le relative 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 root di sistema predefinito, come nell'esempio precedente, controlla la sezione di primo livello Dove si trova l'archivio dei certificati root di sistema e come posso aggiornarlo? per assicurarti che il bundle di certificati root di sistema sia aggiornato.

Per istruzioni su come ottenere openssl, vedi la sezione Ottenere OpenSSL.

Archivio dei certificati radice Java

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

Per importare un singolo certificato nell'archivio dei certificati Java, esegui il seguente comando:

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

Sostituisci cert.pem con il file del certificato corrispondente a ogni certificato radice consigliato, alias con un alias del certificato univoco ma significativo e certs.jks con il file del database dei certificati utilizzato nel tuo ambiente.

Per ulteriori informazioni, consulta i seguenti articoli di Oracle e Stack Overflow:

Archivio dei certificati radice NSS di Mozilla

Le applicazioni che utilizzano Mozilla NSS potrebbero per impostazione predefinita utilizzare anche un database di certificati a livello di sistema in genere situato 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, esegui 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 ciascun certificato radice consigliato, cert-name con un nickname significativo per il certificato e certdir con il percorso del database dei certificati utilizzato nel tuo ambiente.

Per ulteriori informazioni, consulta il manuale ufficiale di NSS Tools certutil, nonché la documentazione del sistema operativo.

Archivio dei certificati radice Microsoft .NET

Gli sviluppatori .NET di Windows potrebbero trovare utili almeno i seguenti articoli Microsoft per aggiornare l'archivio dei certificati radice:

Formati dei file dei certificati

Che cos'è un file PEM?

Privacy-Enhanced Mail (PEM) è un formato file di testo standard di fatto per l'archiviazione e l'invio di certificati, chiavi e così via crittografici, formalizzato come standard de jure nella RFC 7468.

Sebbene il formato del file sia leggibile, i dati binari del certificato con codifica Base64 non lo sono. Tuttavia, la specifica PEM consente l'emissione di testo esplicativo prima o dopo il corpo del certificato codificato nel testo e molti strumenti utilizzano questa funzionalità per fornire anche un riepilogo in testo normale degli elementi di dati più pertinenti in un certificato.

È possibile utilizzare anche strumenti come openssl per decodificare l'intero certificato in un formato leggibile. Per saperne di più, consulta la sezione Come stampare i certificati PEM in formato leggibile.

Che cos'è un file ".crt"?

Gli strumenti che consentono l'esportazione dei certificati in formato PEM comunemente utilizzano l'estensione file ".crt" per indicare che il file utilizza una codifica testuale.

Che cos'è un file DER?

Distinguished Encoding Rules (DER) è un formato binario standardizzato per la codifica dei certificati. I certificati nei file PEM sono in genere certificati DER con codifica Base64.

Che cos'è un file ".cer"?

Un file esportato con il suffisso ".cer" potrebbe contenere un certificato con codifica PEM, ma più comunemente un certificato binario, di solito con codifica DER. Per convenzione, i file ".cer" in genere 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. Consulta la domanda Come faccio a estrarre i singoli certificati da roots.pem? per scoprire come dividere prima il file.

Come faccio a estrarre singoli certificati da roots.pem?

Puoi dividere roots.pem nei suoi certificati componenti utilizzando il seguente script bash:

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

In questo modo, verranno creati diversi file PEM individuali 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

I singoli file PEM, ad esempio 02265526.pem, possono essere importati separatamente o convertiti ulteriormente in un formato di file accettato dall'archivio certificati.

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 i file tra tutti i formati di file di certificato comunemente utilizzati. Di seguito sono riportate le istruzioni per la conversione da un file PEM ai formati di file del certificato più comunemente utilizzati.

Per un elenco completo delle opzioni disponibili, consulta la documentazione ufficiale delle utilità della riga di comando OpenSSL.

Per istruzioni su come ottenere openssl, vedi la sezione Ottenere OpenSSL.

Come faccio a convertire un file PEM in formato DER?

Utilizzando openssl, puoi eseguire il seguente comando per convertire un file da PEM a DER:

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

Utilizzando openssl, puoi eseguire il seguente comando per convertire un file da PEM a PKCS #7:

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

Utilizzando openssl, puoi eseguire il seguente comando per convertire un file da PEM a PKCS #12:

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

Quando crei un archivio PKCS #12, devi fornire una password per il file. Assicurati di conservare la password in un luogo sicuro, se non importi immediatamente il file PKCS #12 nel tuo sistema.

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

Come faccio a esportare un certificato dal keystore Java come file PEM?

Utilizzando keytool, puoi eseguire il seguente comando per elencare tutti i certificati nel tuo archivio certificati, insieme all'alias che puoi utilizzare per esportare ciascuno:

keytool -v -list -keystore certs.jks

Basta sostituire certs.jks con il file del database dei certificati utilizzato nel tuo ambiente. Questo comando mostra anche l'alias di ogni certificato, che ti servirà se vuoi esportarlo.

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

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

Basta sostituire certs.jks con il file del database dei certificati utilizzato nel tuo ambiente e fornire un alias e un alias.pem corrispondenti al certificato che vuoi esportare.

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

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

Utilizzando certutil, puoi eseguire il seguente comando per elencare tutti i certificati nell'archivio certificati, insieme al nickname che puoi utilizzare per esportare ciascun certificato:

certutil -L -d certdir

Basta sostituire certdir con il percorso del database dei certificati utilizzato nel tuo ambiente. Questo comando mostra anche il nickname di ogni certificato, che ti servirà se vuoi esportarlo.

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

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 un cert-name e un cert.pem corrispondenti al certificato che vuoi esportare.

Per ulteriori informazioni, consulta il manuale ufficiale di NSS Tools certutil, nonché la documentazione del sistema operativo.

Come stampare i 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 di certificato utilizzando OpenSSL

Emissione del comando

openssl x509 -in GTS_Root_R1.pem -text

dovrebbe restituire un output 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, vedi la sezione Ottenere OpenSSL.

Stampa dei certificati utilizzando Keytool Java

Eseguendo il seguente comando

keytool -printcert -file GTS_Root_R1.pem

dovrebbe restituire un output 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 Ottenere Keytool Java.

Come faccio a vedere quali certificati sono installati nell'archivio dei certificati radice?

Questo valore varia in base al sistema operativo e alla libreria SSL/TLS. Tuttavia, gli strumenti che consentono di importare ed esportare certificati da e verso l'archivio dei certificati radice in genere forniscono anche un'opzione per elencare i certificati installati.

Inoltre, se hai esportato correttamente i certificati radice attendibili in file PEM o se l'archivio dei certificati radice contiene già file PEM archiviati, puoi provare ad aprire i file in qualsiasi editor di testo, poiché si tratta di un formato di file di testo normale.

Il file PEM potrebbe essere etichettato correttamente, fornendo informazioni leggibili sull'autorità di certificazione associata (esempio dal bundle 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 può contenere anche solo la parte del certificato. In questi casi, il nome del file, ad esempio GTS_Root_R1.pem, può descrivere a quale CA appartiene il certificato. Anche la stringa del certificato tra i token -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- è univoca per ogni CA.

Tuttavia, anche se non disponi degli strumenti sopra indicati, poiché ogni certificato nel bundle CA radice attendibile di Google è etichettato correttamente, puoi abbinare in modo affidabile le CA radice del bundle a quelle del tuo archivio di certificati radice tramite Issuer o confrontando le stringhe dei certificati dei file PEM.

I browser web possono utilizzare il proprio archivio di certificati radice o fare affidamento su quello predefinito fornito dal sistema operativo. Tuttavia, tutti i browser moderni dovrebbero consentirti di gestire o almeno visualizzare l'insieme di CA radice di cui si fidano. Per ulteriori dettagli, consulta la domanda Le applicazioni JavaScript rischiano di non funzionare più?.

Per istruzioni specifiche per i cellulari, consulta la domanda separata Come faccio a controllare i certificati root attendibili sul mio cellulare?.

Appendice

Per maggiori informazioni,

Fai sempre affidamento principalmente alla documentazione del sistema operativo, alla documentazione dei linguaggi di programmazione dell'applicazione, nonché alla documentazione di qualsiasi libreria esterna utilizzata dall'applicazione.

Qualsiasi altra fonte di informazioni inclusa questa pagina delle domande frequenti potrebbe essere obsoleta o errata e non deve essere considerata autorevole. Tuttavia, potresti trovare informazioni utili in molte delle community di domande e risposte di Stack Exchange.

Consulta anche le Domande frequenti su Google Trust Services.

Per una breve introduzione alla crittografia, alla PKI, ai certificati e alle catene di certificati, ti consigliamo di consultare la playlist di YouTube PKI Bootcamp di Paul Turner.

Per ulteriori dettagli su argomenti avanzati, come il pinning dei certificati, puoi trovare utili l'articolo Certificate and Public Key Pinning e il Pinning Cheat Sheet di Open Web Application Security Project (OWASP). Per istruzioni specifiche per Android, consulta il documento di formazione ufficiale Android Best Practices for Security & Privacy Security with HTTPS and SSL. Per una discussione sul pinning di certificati e chiavi pubbliche su Android, potrebbe esserti utile il post del blog di Matthew Dolan Android Security: SSL Pinning.

Il documento di formazione Best practice per la sicurezza e la privacy di Android Configurazione della sicurezza di rete fornisce ulteriori informazioni sulla gestione di certificati attendibili aggiuntivi su Android.

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