Domande frequenti sulla migrazione della CA radice di Google Maps Platform

Il presente documento si articola nelle seguenti sezioni:

• Terminologia
• Informazioni generali
• Risoluzione dei problemi
• Gestione dei certificati attendibili
• Appendice

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 conoscere per questo documento. Per una panoramica più completa della terminologia correlata, consulta le 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 entità note come autorità di certificazione.

I browser si basano sui certificati emessi da autorità di certificazione attendibili per sapere che le informazioni trasmesse vengono inviate al server corretto e che vengono criptate durante il transito.

SSL (Secure Sockets Layer)

Secure Sockets Layer è stato il protocollo più ampiamente distribuito utilizzato per criptare le comunicazioni internet. Il protocollo SSL non è più considerato sicuro e non deve essere utilizzato.

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 dispositivi e persone. Emette documenti protetti tramite crittografia (certificati) per attestare che un'entità (ad esempio un sito web) è quella che sostiene di essere.

Prima di emettere un certificato, le CA hanno la responsabilità di verificare che i nomi nel certificato siano collegati alla persona o alla persona giuridica che lo richiede.

Il termine Autorità di certificazione può riferirsi sia a organizzazioni come Google Trust Services sia a sistemi che emettono certificati.

Archivio certificati radice

Un archivio di certificati radice contiene un insieme di autorità di certificazione ritenute 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 rigidi requisiti stabiliti dal fornitore di software per applicazioni.

In genere, questi requisiti includono la conformità a 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 livello più alto in una catena di certificati.

In genere i certificati CA radice sono autofirmati. Le chiavi private associate alle relative chiavi vengono archiviate in strutture altamente sicure e conservate in uno stato 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 dei certificati online, mentre il certificato della CA radice rimane 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, è il certificato utilizzato per firmare il certificato più in basso in una catena di certificati.

Il certificato più in basso è comunemente chiamato certificato sottoscrittore, certificato di entità finale o certificato foglia. In questo documento utilizzeremo anche il termine certificato del server.

Catena di certificati

I certificati sono collegati (firmati in modo crittografico) al loro emittente. Una catena di certificati è composta da un certificato foglia, tutti i certificati dell'emittente e un certificato radice.

Firma incrociata

I clienti dei fornitori di software per le applicazioni devono aggiornare il proprio archivio di certificati radice in modo da includere nuovi certificati CA affinché possano essere considerati attendibili dai rispettivi prodotti. Sarà necessario del tempo prima che i prodotti contenenti i nuovi certificati CA vengano ampiamente utilizzati.

Per aumentare la compatibilità con i client meno recenti, i certificati CA possono essere "con firma incrociata" da un'altra CA già stabilita. In questo modo viene creato in modo efficace un secondo certificato CA per la stessa identità (nome e coppia di chiavi).

A seconda delle CA incluse nell'archivio dei certificati radice, i client creano una catena di certificati diversa fino a una radice attendibile.

Informazioni generali

Che cosa sta succedendo?

Introduzione

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

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

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

Tuttavia, una CA può in base alla progettazione non emettere certificati validi oltre la scadenza del proprio certificato. Con la scadenza di GS Root R2, il 15 dicembre 2021, Google eseguirà la migrazione dei suoi 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 e delle librerie client TLS si basino già nelle CA radice GTS, per garantire anche una transizione senza problemi per la maggior parte dei sistemi legacy, Google ha acquisito un cross-sign da GMO GlobalSign utilizzando GlobalSign Root CA - R1, una delle CA radice più vecchie e attendibili attualmente disponibili.

Pertanto, i clienti di Google Maps Platform della maggior parte dei clienti già riconoscono una (o entrambe) queste CA radice affidabili e non saranno completamente interessati dalla seconda fase della migrazione.

Questo vale anche per i clienti che hanno intrapreso un'azione durante la prima fase della migrazione nel 2018, supponendo che al momento abbiano 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 gestisci il tuo archivio dei certificati radice
• Non hai preso provvedimenti nel periodo 2017-2018, durante la prima fase della migrazione della CA radice di Google oppure non hai installato il set completo di certificati dal pacchetto CA radice di Google attendibile.

In questi casi, è possibile che sia necessario aggiornare i client con i certificati radice consigliati per garantire un utilizzo ininterrotto 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 mantenere sincronizzati gli archivi di certificati radice con il bundle CA radice selezionato in precedenza per proteggere i tuoi servizi da future modifiche della CA radice. Tuttavia, verranno annunciati in anticipo. Consulta le sezioni Come posso ricevere aggiornamenti in questa fase della migrazione? e Come posso ricevere un preavviso per le migrazioni future? per ulteriori istruzioni su come restare al passo.

Riepilogo tecnico

Come annunciato il 15 marzo 2021 nel Google Security Blog, GS Root R2, la CA radice di Google Maps Platform utilizzata dall'inizio del 2018 scadrà il 15 dicembre 2021. Pertanto, durante l'anno Google eseguirà la migrazione a un'istanza CA GTS Root R1 Cross appena emessa. Ciò significa che i nostri servizi passeranno gradualmente ai certificati foglia TLS emessi dalla nuova CA.

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

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

• i tuoi servizi vengono eseguiti su piattaforme non standard o legacy e/o gestisci il tuo archivio dei certificati radice
• Non hai preso provvedimenti nel periodo 2017-2018, durante la prima fase della migrazione della CA radice di Google oppure non hai installato il set completo di certificati dal pacchetto CA radice di Google attendibile.

La sezione Come verificare se l'archivio dei certificati radice necessita di un aggiornamento fornisce indicazioni generali per testare se il sistema è interessato.

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

Come faccio a ricevere aggiornamenti su questa fase di migrazione?

Aggiungi a Speciali il problema pubblico 186840968 per gli aggiornamenti. Queste domande frequenti vengono aggiornate anche nel corso del processo di migrazione, ogni volta che vengono rilevati argomenti di interesse generale.

Come faccio a ricevere un preavviso per le migrazioni future?

Ti consigliamo di seguire il blog sulla sicurezza di Google. Inoltre, ci impegneremo ad aggiornare quanto prima la documentazione specifica per i prodotti, in base all'annuncio pubico sul blog.

Ti invitiamo inoltre a iscriverti alle notifiche di Google Maps Platform, poiché pubblichiamo regolarmente sul forum aggiornamenti sui cambiamenti che potrebbero influire su un maggior numero di clienti.

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

Sì, la migrazione della CA radice verrà eseguita per tutti i servizi e le API Google, ma le tempistiche potrebbero variare in base al servizio. Tuttavia, una volta verificato che gli archivi dei certificati radice utilizzati dalle applicazioni client di Google Maps Platform contengono tutte le CA elencate nel pacchetto CA radice di Google attendibile, i tuoi servizi non dovrebbero essere interessati dalla migrazione in corso e mantenere sincronizzati questi servizi ti proteggerà anche da future modifiche della CA radice.

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

La sezione Come verificare se l'archivio dei certificati radice necessita di un aggiornamento di seguito fornisce anche istruzioni generali per testare il sistema.

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 all'endpoint di cross test GTS Root R1, non dovresti essere interessato dalla scadenza di GS Root R2.
• Se sei in grado di stabilire una connessione TLS all'endpoint di test GTS Root R1, probabilmente la tua applicazione sarà protetta anche dalla scadenza dei programmi GTS Root R1 Cross e GlobalSign Root CA - R1 nel 2028.

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

• il tuo servizio viene eseguito su un sistema operativo mainstream gestito; hai conservato sia il sistema operativo sia le librerie utilizzate dal servizio con patch e non gestisci il tuo archivio di certificati radice oppure:
• hai seguito i nostri suggerimenti precedenti e hai installato tutte le CA radice dal pacchetto CA radice di Google attendibile

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

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

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

Nelle tue indagini potrebbero risultare utili i due strumenti a riga di comando curl e openssl. Entrambe sono disponibili sulla maggior parte delle piattaforme e offrono numerose opzioni per testare la configurazione.

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

I comandi openssl mostrati di seguito sono disponibili per la versione 1.1.1 o successive. Le versioni precedenti alla 1.1.1 non sono più supportate. Se usi 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 Come scaricare OpenSSL di seguito.

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

Per istruzioni di test concrete, consulta la sezione Come verificare se l'archivio di certificati radice necessita di 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, quindi 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. La prima fase (con migrazione a GS Root R2), annunciata a gennaio 2017, è iniziata a fine 2017 e si è conclusa nella prima metà del 2018.
2. La seconda fase (migrazione a GTS Root R1 Cross) è stata annunciata a marzo 2021 e verrà implementata nei prossimi mesi, prima della scadenza di GS Root R2, il 15 dicembre 2021.

Le pianificazioni delle eventuali fasi di migrazione successive verranno annunciate con largo anticipo delle future scadenze dei certificati.

Tuttavia, potrai proteggere le tue app in futuro se mantieni sincronizzato l'archivio dei certificati radice con l'elenco selezionato di CA radice nel pacchetto delle CA radice attendibili di Google.

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

Piano di implementazione generale per ogni servizio Google

1. L'implementazione graduale inizia in un unico data center.
2. L'implementazione viene estesa gradualmente ad altri data center fino a quando non sarà disponibile una copertura globale.
3. Se vengono rilevati problemi gravi in qualsiasi fase, è possibile eseguire il rollback dei test temporaneamente mentre i problemi vengono risolti.
4. In base ai dati inseriti da iterazioni precedenti, nell'implementazione sono inclusi ulteriori servizi Google finché non viene eseguita gradualmente la migrazione di tutti i servizi Google ai nuovi certificati.

Chi sarà interessato, quando e dove?

Un numero crescente di sviluppatori di Google Maps Platform inizierà a ricevere i nuovi certificati man mano che verranno migrati i nuovi data center. Le modifiche riguarderanno la localizzazione, dato che le richieste dei clienti tendono a essere inoltrate ai server nei data center geograficamente vicini.

Poiché non possiamo dire con certezza in anticipo chi sarà interessato, nonché 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.

Per ulteriori indicazioni, consulta la sezione Come verificare se l'archivio di certificati radice richiede un aggiornamento.

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 questa situazione, in genere i client emettono un avviso che indica che la convalida del certificato non è riuscita.

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

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

I certificati di 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.

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 è ancora mantenuto e riceve aggiornamenti regolari, l'archivio di certificati radice predefinito dovrebbe già includere il certificato GTS Root R1.

Se utilizzi una versione precedente del sistema operativo che non riceve più aggiornamenti, potresti disporre o meno del certificato GTS Root R1. Tuttavia, l'archivio dei certificati radice molto probabilmente conterrà GlobalSign Root CA - R1, una delle CA radice più vecchie e attendibili.

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

Applicazioni lato client di Google Maps Platform

Le applicazioni API Maps JavaScript si basano in genere sui certificati radice del browser web che esegue l'applicazione. Per ulteriori dettagli, consulta la sezione Le applicazioni JavaScript rischiano di interrompersi.

Per le applicazioni mobile native che utilizzano Maps SDK for Android, Maps SDK for iOS, Places SDK for Android o Places SDK for iOS, vengono applicate le stesse regole valide per le app che chiamano i servizi web di Google Maps Platform.

Per ulteriori dettagli, consulta la domanda Le app mobile rischiano di non funzionare.

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 alla domanda Perché dovrei mantenere sincronizzato l'archivio dei certificati radice con il bundle CA radice di Google attendibile?, ti consigliamo di importare tutti i certificati dal pacchetto CA radice di Google attendibile nel tuo archivio dei certificati radice.

Se stai bloccando certificati o chiavi pubbliche per i domini Google a cui si collega la tua applicazione, devi aggiungere i certificati e le chiavi pubbliche all'elenco delle entità attendibili nella tua applicazione.

Per ulteriori informazioni sul blocco dei certificati o della chiave pubblica, consulta le risorse esterne elencate alla domanda Hai bisogno di ulteriori 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 pacchetto delle CA radice attendibili di Google include tutte le CA che potrebbero plausibilmente essere utilizzate dai servizi Google nel prossimo futuro.

Pertanto, se vuoi proteggere il tuo sistema in futuro, ti consigliamo vivamente di verificare che l'archivio dei certificati radice contenga tutti i certificati del bundle e di abituarti a mantenerli sincronizzati.

Ciò è particolarmente importante se i servizi vengono eseguiti su una versione del sistema operativo non mantenuta, per altri motivi non puoi mantenere il sistema operativo e le librerie con patch aggiornate oppure gestisci il tuo archivio dei certificati radice.

Vedi la domanda Come posso ricevere un preavviso per le migrazioni future? per scoprire come ricevere aggiornamenti sulle future migrazioni della CA radice. Mantenendo regolarmente sincronizzato l'archivio dei certificati radice con l'elenco selezionato, proteggerai i tuoi servizi da future interruzioni del servizio dovute a modifiche delle CA e manterrai in esecuzione i servizi anche dopo la scadenza di 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 su GTS per ulteriori suggerimenti.

Perché non devo installare certificati CA foglia o intermedi?

In questo modo rischi di interrompere l'applicazione in qualsiasi momento in cui registriamo un nuovo certificato o passiamo a CA intermedie. Entrambe queste situazioni possono verificarsi in qualsiasi momento e senza preavviso e si applicano anche ai singoli certificati dei server, come quelli forniti da maps.googleapis.com, nonché a qualsiasi CA intermedia, come GTS Root R1 Cross.

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

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

Le applicazioni JavaScript rischiano di interrompersi?

I certificati radice GTS sono già ben integrati e ritenuti attendibili dalla maggior parte dei browser moderni, e il cross-sign di GMO GlobalSign dovrebbe garantire una migrazione senza problemi anche per la maggior parte degli utenti finali che utilizzano browser precedenti. Sono inclusi tutti i browser supportati ufficialmente per l'API Maps JavaScript.

Ogni browser moderno dovrebbe consentire agli utenti finali di verificare e, di solito, di modificare i certificati attendibili dal browser. Anche se la posizione esatta varia a seconda del browser, in genere l'elenco dei certificati è disponibile nelle Impostazioni.

Le app mobile rischiano di non funzionare?

Anche i dispositivi Android e Apple iOS che ricevono ancora aggiornamenti regolari dal produttore 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 di dispositivo e alla versione di Android.

Tuttavia, il supporto delle CA principali GTS, incluso 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 proprie 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 a partire dalla versione 12.1.3 di iOS.

Vedi la 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 mantenendo pacchetti di certificati radice attendibili e ampiamente utilizzati. Alcuni esempi sono i produttori di sistemi operativi come Apple e Microsoft, ma anche i team Android e Chrome OS di Google; sviluppatori di browser come Mozilla, Apple, Microsoft, ma anche il team Chrome di Google; produttori di hardware come telefoni, decoder, TV, console per videogiochi, stampanti e altro ancora.

È quindi molto probabile che tutti i sistemi attualmente gestiti supportino già le nuove CA radice GTS di Google, inclusa GTS Root R1, e che anche i sistemi precedenti supportino con molta probabilità GlobalSign Root CA - R1, che verrà utilizzato per la firma incrociata dei certificati emessi da Google nei prossimi anni.

Tuttavia, poiché le tempistiche per l'inclusione dei certificati di terze parti non sono di competenza di Google, il miglior consiglio generale che possiamo offrire è di applicare regolarmente gli aggiornamenti di sistema disponibili.

Alcune terze parti, come il CA Certificate Program di Mozilla, potrebbero aver documentato le proprie tempistiche per l'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 precompilato, 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. Puoi trovare un elenco di file binari creati da terze parti all'indirizzo https://www.openssl.org/community/binaries.html. Tuttavia, nessuna di queste build è supportata o in alcun modo approvata dal team 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 delle prime 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 relativa a questi utili strumenti è disponibile rispettivamente nella Guida dell'utente di Wireshark, nella pagina man di Tshark e nella pagina man di Tcpdump.

Recupero keytool Java

Lo strumento a riga di comando keytool deve essere fornito insieme a ogni versione di Java Development Kit (JDK) o di Java Runtime Environment (JRE). Installali per ottenere keytool.. Tuttavia, è improbabile che l'utilizzo di keytool sia necessario per la verifica del certificato radice, a meno che la tua applicazione non sia creata mediante Java.

Cosa fare in caso di interruzione della produzione

Il metodo principale consiste nell'installare i certificati radice richiesti dal pacchetto CA radice di Google attendibile nell'archivio dei certificati radice utilizzato dalla tua applicazione.

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

Contattare l'assistenza di Google Maps Platform

Risoluzione dei problemi iniziale

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

Anche la sezione Gestire i certificati attendibili può fornire informazioni preziose se devi importare o esportare i 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 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 richiesti, 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 Risorse e assistenza per Google Maps Platform.

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

• Quali sono i tuoi indirizzi IP pubblici?
• Qual è l'indirizzo IP pubblico del tuo server DNS?
• Se possibile, un'acquisizione di pacchetti tcpdump o Wireshark della negoziazione TLS non riuscita rispetto a https://maps.googleapis.com/ in formato PCAP, utilizzando una lunghezza dello snapshot sufficientemente grande per acquisire l'intero pacchetto senza troncarlo (ad esempio utilizzando -s0 nelle versioni precedenti di tcpdump).
• Se possibile, estratti di log dal tuo 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 richiesti, vedi la domanda Dove posso trovare gli strumenti di cui ho bisogno?.

Pubblicazione su un problema pubblico 186840968

Quando pubblichi un commento su un problema pubblico 186840968, include 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 in modalità interattiva:

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

Come interpretare l'output 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 e le informazioni sulla terminazione 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 che riceve dal server.
• Se il protocollo era HTTPS, la presenza di righe ">" o "<" implica che l'handshake TLS sia andato a buon fine.

Libreria TLS e bundle di certificati radice utilizzati

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

L'output da una macchina Red Hat Linux con curl collegato a NSS potrebbe 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

L'output da una macchina Ubuntu o Debian Linux utilizzando il file PEM del certificato radice di Google fornito utilizzando il flag --cacert può contenere le seguenti 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 potrebbe fornire informazioni utili su curl e sul tuo sistema.

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 è stata terminata durante l'handshake TLS a causa di un certificato server non attendibile. Anche l'assenza di un output di debug che inizia con > o < è un indicatore forte 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 quelle in questo esempio di codice. Dovrebbe essere elencata la suite di crittografia utilizzata per la connessione criptata, così come i dettagli del certificato del server accettato. Inoltre, la presenza di righe che iniziano con > o < indicano che il traffico HTTP del payload viene trasmesso correttamente tramite la connessione criptata con 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

Presupponendo che l'output sia 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 questa procedura:

• 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 di 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 accennato alla domanda Le app mobile rischiano di non funzionare?, Android fin dalla versione 4.0 consente agli utenti di smartphone di verificare l'elenco di certificati attendibili nella sezione Impostazioni. Questa tabella mostra il percorso esatto del menu Impostazioni:

Versione di Android	Percorso menu
1,x, 2,x, 3,x	N/A
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à dei certificati radice più importanti per versione di Android, in base alla verifica manuale tramite immagini di sistema Android Virtual Device (AVD) attualmente disponibili, facendo riferimento alla cronologia delle versioni del repository di Git (ca-certificates) AOSP, in cui 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 l'aggiornamento dell'archivio dei certificati radice del sistema Android non è possibile senza un aggiornamento firmware o il rooting del dispositivo. Tuttavia, nella maggior parte delle versioni di Android ancora in uso, è probabile che l'insieme attuale di certificati radice attendibili fornisca un servizio senza interruzioni per diversi anni, oltre la durata effettiva della maggior parte dei dispositivi attualmente esistenti.

A partire dalla versione 7.0, Android offre agli sviluppatori di applicazioni un metodo sicuro per aggiungere certificati attendibili che sono considerati attendibili solo dalla loro applicazione. Per farlo, raggruppa i certificati con l'applicazione e crea una configurazione di sicurezza di rete personalizzata, come descritto nel documento di formazione Best practice per Android per sicurezza e privacy Configurazione della sicurezza di rete.

Tuttavia, poiché gli sviluppatori di applicazioni di terze parti non saranno in grado di influenzare la configurazione della sicurezza di rete del traffico proveniente dall'APK Google Play Services, questi sforzi potrebbero fornire solo una soluzione alternativa parziale.

Sui dispositivi legacy meno recenti, l'unica opzione disponibile sarebbe quella di affidarsi alle CA aggiunte dagli utenti, installate tramite criteri di gruppo aziendali applicati al dispositivo dell'utente finale, oppure dagli stessi utenti finali.

Archivio attendibilità iOS

Sebbene Apple non mostri direttamente all'utente del telefono il suo insieme predefinito di certificati radice attendibili, l'azienda ha dei link ai set di CA radice attendibili per iOS 5 e versioni successive negli articoli del Supporto Apple:

• Elenco dei certificati radice attendibili disponibili in iOS 12.1.3, macOS 10.14.3, watchOS 5.1.3 e tvOS 12.1.2
• iOS 5 e iOS 6: elenco dei certificati radice attendibili disponibili.

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

Questa tabella illustra la disponibilità dei certificati radice più importanti per ogni versione di iOS, in base alle origini 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 alla libreria SSL/TLS utilizzata. Tuttavia, nella maggior parte delle distribuzioni Linux, i certificati radice predefiniti si trovano in uno dei seguenti percorsi:

• /usr/local/share/ca-certificates: Debian, Ubuntu, versioni RHEL e CentOS precedenti
• /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, puoi controllare la posizione configurata dei componenti installati, incluso l'archivio dei certificati root predefinito, utilizzando il seguente comando:

openssl version -d

Il comando restituisce 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 radice di sistema predefinito come nell'esempio precedente, controlla la sezione di primo livello Dove si trova l'archivio dei certificati radice di sistema e come posso aggiornarlo? per garantire 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 nei 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 nel tuo archivio certificati Java, esegui il comando seguente:

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

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

Per ulteriori informazioni, leggi i seguenti articoli su Oracle e Stack Overflow:

• Piattaforma Java, riferimento sugli strumenti della versione Standard: keytool
• Come ottenere il percorso di cacerts dell'installazione Java predefinita?
• Come si importa correttamente un certificato autofirmato nell'archivio chiavi Java che sia disponibile per impostazione predefinita per tutte le applicazioni Java?

Archivio certificati radice di Mozilla NSS

Per impostazione predefinita, le applicazioni che utilizzano Mozilla NSS possono utilizzare anche un database di certificati a livello di sistema, generalmente posizionato 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 comando seguente:

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

Devi solo sostituire cert.pem con il file del certificato corrispondente a ogni certificato radice consigliato, cert-name con un nickname significativo del certificato e certdir con il percorso del database del certificato utilizzato nel tuo ambiente.

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

Archivio certificati radice Microsoft .NET

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

• Utilizzo dei certificati
• Gestire i certificati radice attendibili

Formati file dei certificati

Che cos'è un file PEM?

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

Sebbene il formato file stesso sia leggibile, le informazioni dei dati del certificato binario codificato Base64 non lo sono. Tuttavia, la specifica PEM consente di emettere testo esplicativo prima o dopo il corpo del certificato codificato in testo e molti strumenti utilizzano questa funzionalità per fornire anche un riepilogo in chiaro degli elementi di dati più pertinenti in un certificato.

Puoi utilizzare anche strumenti come openssl per decodificare l'intero certificato in formato leggibile. Per maggiori informazioni, consulta la sezione Come stampare i certificati PEM in formato leggibile.

Che cos'è un file ".crt"?

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

Che cos'è un file DER?

Le regole di codifica DER sono un formato binario standardizzato per i certificati di codifica. I certificati nei file PEM sono in genere certificati DER codificati in Base64.

Che cos'è un file ".cer"?

Un file esportato con il suffisso ".cer" può contenere un certificato con codifica PEM, ma in genere un certificato binario, di solito con codifica DER. Per convenzione, i file ".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. Vedi la domanda Come faccio a estrarre singoli certificati da roots.pem? per vedere come può essere suddiviso il file.

Come faccio a estrarre singoli certificati da roots.pem?

Puoi suddividere roots.pem nei certificati dei componenti utilizzando il seguente semplice 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

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

I singoli file PEM, ad esempio 02265526.pem, possono essere importati separatamente o ulteriormente convertiti in un formato 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 file tra tutti i formati file di certificati più utilizzati. Di seguito sono elencate le istruzioni per convertire un file PEM nei formati file con certificati più utilizzati.

Per un elenco completo delle opzioni disponibili, consulta la documentazione ufficiale sulle utilità della 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 #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 #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. Se non importi immediatamente il file PKCS #12 nel sistema, assicurati di archiviare la password in un luogo sicuro.

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 inviare il seguente comando per elencare tutti i certificati nel tuo archivio certificati, insieme all'alias che puoi utilizzare per esportare ogni certificato:

keytool -v -list -keystore certs.jks

Devi solo sostituire certs.jks con il file del database dei certificati utilizzato nel tuo ambiente. Questo comando mostra anche l'alias di ciascun certificato, di cui avrai bisogno se vuoi 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 nel tuo ambiente e fornire i valori alias e alias.pem corrispondenti al certificato che vuoi 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 inviare il seguente comando per elencare tutti i certificati nel tuo archivio certificati, insieme al nickname che puoi utilizzare per esportare ogni certificato:

certutil -L -d certdir

Devi solo sostituire certdir con il percorso del database dei certificati utilizzato nel tuo ambiente. Questo comando mostra anche il nickname di ciascun certificato, di cui avrai bisogno per esportarlo.

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

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

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

Per ulteriori informazioni, consulta il manuale ufficiale di NSS Tools certutil e la documentazione del tuo 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 consentono l'importazione e l'esportazione di certificati da e verso l'archivio dei certificati radice in genere offrono 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 aprirli in qualsiasi editor di testo, poiché si tratta di un formato file di testo normale.

Il file PEM potrebbe essere etichettato correttamente, fornendo informazioni leggibili dell'autorità di certificazione associata (esempio proveniente dal pacchetto CA radice di Google attendibile):

# 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 file, ad esempio GTS_Root_R1.pem, può descrivere a quale CA appartiene il certificato. Inoltre, la stringa del certificato tra i token -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- è univoca per ogni CA.

Tuttavia, anche se non disponi degli strumenti indicati sopra, poiché ogni certificato nel pacchetto della CA radice di Google attendibile è etichettato correttamente, puoi associare in modo affidabile le CA radice del bundle e quelle dell'archivio dei 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 affidarsi a quello predefinito fornito dal sistema operativo. Tuttavia, tutti i browser moderni dovrebbero consentirti di gestire o almeno visualizzare il set di CA radice attendibili. Per ulteriori dettagli, consulta la domanda Le applicazioni JavaScript rischiano di funzionare.

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

Appendice

Per maggiori informazioni,

Fai sempre affidamento principalmente sulla documentazione del tuo sistema operativo, della documentazione del linguaggio o dei linguaggi di programmazione dell'applicazione e di qualsiasi libreria esterna utilizzata dall'applicazione.

Qualsiasi altra fonte di informazioni incluse le presenti Domande frequenti potrebbe essere obsoleta o altrimenti errata e non deve essere considerata autorevole. Tuttavia, potresti comunque trovare informazioni utili su molte delle community di domande e risposte di Stack Exchange, nonché su siti come AdamW su Linux e altri e sul blog di conferma, tra gli altri.

Consulta anche le Domande frequenti su Google Trust Services.

Per ulteriori dettagli su argomenti avanzati, come il blocco dei certificati, puoi trovare l'articolo Open Web Application Security Project (OWASP) sul blocco di certificati e chiavi pubbliche e le informazioni sulla scheda di riferimento sul blocco. Per istruzioni specifiche per Android, consulta il documento di formazione ufficiale Best practice per la sicurezza e la privacy di Android Sicurezza con HTTPS e SSL. Per discussioni sul confronto tra certificati e blocco della chiave pubblica su Android, potresti trovare utile il post del blog di Matthew Dolan Android Security: SSL Pinning.

Il documento di formazione sulle best practice di Android per la sicurezza e la privacy sulla configurazione della sicurezza della rete e il post del blog di JeroenHD su Android 7 Nougat e sulle autorità di certificazione forniscono ulteriori informazioni sulla gestione di certificati attendibili aggiuntivi su Android.

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