Domande frequenti sulla migrazione della CA radice di Google Maps Platform

Il presente documento si articola nelle seguenti sezioni:

Per una panoramica più dettagliata della migrazione della CA radice di Google in corso, consulta 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 sono emessi e firmati crittograficamente da entità note come autorità di certificazione.
I browser si basano sui certificati emessi da autorità di certificazione affidabili per sapere che le informazioni trasmesse vengono inviate al server corretto e che sono criptate in transito.
SSL (Secure Sockets Layer)
Secure Sockets Layer era il protocollo più utilizzato per criptare le comunicazioni su 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 digitale per dispositivi e persone. Emette documenti protetti da crittografia (certificati) per dimostrare che un'entità (ad es. il sito web) è chi dichiara di essere.
Prima di emettere un certificato, le autorità di certificazione 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 alle organizzazioni come Google Trust Services sia ai sistemi che emettono i certificati.
Archivio certificati radice
Un archivio di certificati radice contiene una serie di autorità di certificazione certificate da un fornitore di software per applicazioni. La maggior parte dei browser web e dei sistemi operativi dispone di proprietari di certificati radice.
Per essere inclusa in un archivio di certificati radice, l'autorità di certificazione deve soddisfare i severi requisiti stabiliti dal fornitore del software di applicazione.
In genere includono la conformità a standard di settore come i requisiti del CA/Browser Forum.
Autorità di certificazione radice
L'autorità di certificazione radice (o, più correttamente, il relativo 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 risorse sono archiviate in strutture altamente sicure e mantenute 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 di certificati online, lasciando che il certificato CA radice rimanga 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 denominato certificato di sottoscrizione, certificato di entità finale o certificato di foglia. In questo documento utilizzeremo anche il termine certificato del server.
Catena di certificati
I certificati sono collegati all'emittente (firmato da). Una catena di certificati è composta da un certificato foglia, da tutti i certificati emittente e da un certificato radice.
Firma incrociata
Fornitori di software per applicazioni' i clienti devono aggiornare il loro archivio certificati radice per includere nuovi certificati CA affinché siano considerati attendibili dai loro prodotti. Occorre un po' di tempo prima che i prodotti contenenti i nuovi certificati CA vengano utilizzati in modo ampio.
Per aumentare la compatibilità con i client meno recenti, i certificati CA possono essere "sottoscritti tra loro" da un'altra CA consolidata. Viene creato un secondo certificato CA per la stessa identità (nome e coppia di chiavi).
A seconda delle autorità di certificazione incluse nell'archivio dei certificati radice, i client creeranno 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 root, le firme crittografiche alla base della sicurezza Internet TLS utilizzata da HTTPS.

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

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

Tuttavia, un'autorità di certificazione può by design non emettere certificati validi oltre la data di scadenza del proprio certificato. Dal momento che GS Root R2 scade il 15 dicembre 2021, Google eseguirà la migrazione dei propri servizi a una nuova CA, GTS Root R1 Cross, utilizzando un certificato emesso dalla CA radice di Google GTS Root R1.

Sebbene la grande maggioranza dei sistemi operativi moderni e delle librerie client TLS si fidi già delle CA radice di GTS, per garantire una transizione fluida per la maggior parte dei sistemi legacy, Google ha acquisito un segno incrociato da GMO GlobalSign utilizzando Global Sign Root CA - R1, una delle più antiche CA radice attualmente più attendibili disponibili.

Di conseguenza, la maggior parte dei clienti di Google Maps Platform riconoscerà già una o entrambe le CA radice attendibili e non sarà assolutamente interessata dalla seconda fase della migrazione.

Questo vale anche per i clienti che hanno intrapreso un'azione nella prima fase della migrazione nel 2018, presumendo che al momento abbiano seguito le nostre istruzioni, installando tutti i certificati dal nostro pacchetto CA radice di Google attendibile.

Devi verificare i tuoi sistemi se si verifica quanto segue:

  • I tuoi servizi eseguono piattaforme non standard o legacy e/o mantieni il tuo archivio certificati radice.
  • Non hai intrapreso alcuna azione nel 2017-2018, durante la prima fase della migrazione della CA radice di Google oppure non hai installato l'intero set di certificati dal pacchetto CA radice di Google attendibile

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

Continua a leggere per ulteriori dettagli tecnici. Per istruzioni generali, consulta la sezione Come verificare se l'archivio dei certificati radice richiede un aggiornamento.

Ti consigliamo anche di continuare a mantenere sincronizzati i tuoi archivi certificati radice con il bundle CA radice selezionato sopra per dimostrare che i tuoi servizi non subiranno modifiche in futuro. Tuttavia questi annunci verranno annunciati in anticipo. Consulta le sezioni Come posso ricevere aggiornamenti su questa fase di migrazione? e Come posso ricevere una notifica anticipata delle migrazioni future? per ulteriori istruzioni su come essere sempre informati.

Riepilogo tecnico

Come annunciato il 15 marzo 2021 nel blog sulla sicurezza di Google, GS Root R2, la CA radice di Google Maps Platform che ha utilizzato dall'inizio del 2018 scadrà il 15 dicembre 2021. Durante questo anno Google quindi eseguirà la migrazione a una GTS Root R1 Cross appena rilasciata in CA. Ciò significa che i nostri servizi passeranno gradualmente ai certificati TLS foglia rilasciati da questa nuova CA.

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

Tuttavia, devi verificare i sistemi almeno se sono soddisfatti entrambi i punti seguenti:

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

La sezione Come verificare se il mio archivio certificati radice richiede un aggiornamento fornisce indicazioni generali per verificare se il tuo sistema sarà interessato.

Vedi la domanda Perché dovrei mantenere sincronizzati i miei certificati radice con il bundle CA radice di Google attendibile? per i dettagli completi.

Come faccio a ricevere aggiornamenti in questa fase della migrazione?

Aggiungi il numero pubblico 186840968 agli aggiornamenti. Inoltre, queste Domande frequenti vengono aggiornate durante tutta la procedura di migrazione, quando incontriamo argomenti di interesse generale.

Come posso ricevere una notifica anticipata sulle migrazioni future?

Ti suggeriamo di seguire il blog sulla sicurezza di Google. Inoltre, ci impegniamo ad aggiornare al più presto la documentazione specifica di un prodotto, in seguito all'annuncio pubblico sul blog.

Iscriviti anche alle Notifiche di Google Maps Platform, perché pubblichiamo regolarmente aggiornamenti nel forum sulle modifiche che potrebbero colpire un numero maggiore di clienti.

Utilizziamo più servizi Google. La migrazione della CA radice influirà su tutti?

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

Vedi domande Perché dovrei mantenere sincronizzati i miei certificati radice con il bundle CA radice di Google attendibile? e Quali tipi di applicazioni sono a rischio di rottura? per ulteriori insight.

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

Come verificare se il mio archivio certificati radice richiede un aggiornamento

Testa l'ambiente della tua applicazione rispetto agli endpoint di test elencati di seguito:

  • Se riesci a stabilire una connessione TLS all'endpoint di test GTS Root R1 Cross, non dovresti essere interessato dalla scadenza di GS Root R2.
  • Se riesci a stabilire una connessione TLS all'endpoint di test GTS Root R1, probabilmente la tua applicazione verrà protetta dalla scadenza di GTS Root R1 Cross e GlobalSign Root CA - R1 nel 2028.

Il tuo sistema sarà generalmente compatibile con questa modifica della CA radice se:

  • il servizio viene eseguito su un sistema operativo mainstream mantenuto, hai mantenuto sia il sistema operativo sia le librerie utilizzate dal tuo servizio e non mantieni il tuo archivio certificati radice oppure:
  • Hai seguito i nostri consigli precedenti e installato tutte le CA radice dal pacchetto CA radice di Google attendibile

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

Vedi la domanda Perché dovrei mantenere sincronizzati i miei certificati radice con il bundle CA radice di Google attendibile? per i dettagli completi.

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

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

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

I comandi openssl mostrati di seguito riguardano la 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 secondo necessità. Per le istruzioni su come ottenere openssl, consulta la sezione Scaricare OpenSSL di seguito.

Inoltre, nella sezione Dove posso trovare gli strumenti che mi servono? di seguito.

Per istruzioni sui test concreti, consulta la sezione Come verificare se il mio archivio certificati radice deve essere aggiornato.

Test dell'archivio certificati certificati predefinito

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

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.r1demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.r1xdemo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;

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

  1. La prima fase (eseguire la 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 (la 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.

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

Tuttavia, potrai mantenere le tue app a prova di futuro se mantieni sincronizzato l'archivio dei certificati radice con l'elenco selezionato di CA radice nel gruppo di CA radice di Google attendibile.

Vedi anche la domanda Perché dovrei mantenere sincronizzati i miei certificati radice con il bundle CA radice di Google attendibile? per ulteriori informazioni.

Piano generale di implementazione per ciascun servizio Google

  1. L'implementazione graduale inizia in un unico data center.
  2. L'implementazione verrà gradualmente estesa a più data center finché non sarà disponibile una copertura globale.
  3. Se vengono rilevati problemi gravi in una fase qualsiasi, i test possono essere ripristinati temporaneamente durante la risoluzione dei problemi.
  4. In base all'input delle iterazioni precedenti, altri servizi Google sono inclusi nell'implementazione fino a quando gradualmente tutti i servizi Google hanno eseguito la migrazione ai nuovi certificati.

Chi sarà interessato, quando e dove?

Aumento del numero di sviluppatori di Google Maps Platform inizierà a ricevere i nuovi certificati al termine della migrazione dei nuovi data center. Le modifiche saranno in qualche modo localizzate, in quanto le richieste dei client tendono a essere inoltrate ai server nei data center geograficamente vicini.

Poiché non possiamo avere certezza anticipata su chi sarà interessato, quando e dove, consigliamo a tutti i nostri clienti di verificare e dimostrare i loro servizi con largo anticipo rispetto alle possibili fasi di migrazione della CA radice di Google.

Per ulteriori indicazioni, consulta la sezione Come verificare se il mio archivio certificati radice richiede un aggiornamento.

A cosa prestare attenzione

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

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

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

I certificati Google Maps Platform utilizzano i SAN (Subject Alternative Name) DNS, quindi la gestione dei certificati del client deve essere in grado di supportare i SAN che possono includere un singolo carattere jolly come etichetta all'estrema sinistra del nome, come *.googleapis.com.

Per altri requisiti, consulta la sezione Quali sono i requisiti consigliati per la comunicazione di un client TLS con Google? nelle Domande frequenti su GTS.

Quali tipi di applicazioni sono a rischio di rottura?

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

Applicazioni del servizio web di Google Maps Platform

Se utilizzi un sistema operativo mainstream, ad es. Ubuntu, Red Hat, Windows 10 o Server 2019, OS X) che sono ancora gestiti e ricevono aggiornamenti regolari, il tuo 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 avere o meno il certificato GTS Root R1. Tuttavia, il tuo archivio certificati radice molto probabilmente conterrà GlobalSign Root CA - R1, una delle CA radice più vecchie e più attendibili.

Per le applicazioni per dispositivi mobili che chiamano i servizi web di Google Maps Platform direttamente dal dispositivo dell'utente finale, le linee guida dalla domanda Le app per dispositivi mobili rischiano di essere interrotte? Si applicano.

Applicazioni Google Maps Platform lato client

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

Per le applicazioni mobile native che utilizzano l'SDK Maps per Android, l'SDK Maps per iOS, l'SDK Places per Android o l'SDK Places per iOS, si applicano le stesse regole delle app che chiamano i servizi web di Google Maps Platform.

Vedi la domanda Le app per dispositivi mobili rischiano di essere interrotte? Per ulteriori dettagli.

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

Devi aggiornare il pacchetto di certificati personalmente. Come discusso in questione Perché dovrei mantenere sincronizzati l'archivio 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 di certificati radice.

Se hai bloccato certificati o chiavi pubbliche per i domini Google a cui si connette l'applicazione, devi aggiungere i certificati e le chiavi pubbliche all'elenco delle entità attendibili nell'applicazione.

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

Perché dovrei mantenere sincronizzati i miei certificati radice con il bundle CA radice di Google attendibile?

L'elenco selezionato di autorità di certificazione radice nel gruppo di CA radice di Google certificato include tutte le autorità di certificazione che potrebbero essere utilizzate in maniera plausibile dai servizi Google nel prossimo futuro.

Pertanto, se vuoi verificare il sistema in futuro, ti consigliamo vivamente di verificare che l'archivio dei certificati radice contenga tutti i certificati dal bundle e prendi l'abitudine di mantenere i due sincronizzati.

Ciò è particolarmente importante se i tuoi servizi sono eseguiti su una versione del sistema operativo non gestita, per altri motivi non puoi mantenere patch del sistema operativo e delle librerie o gestire il tuo archivio di certificati radice.

Consulta la domanda Come posso ricevere una notifica anticipata sulle migrazioni future? per scoprire come ricevere aggiornamenti sulle future migrazioni delle CA radice. Mantenere di routine i tuoi certificati radice sincronizzati con l'elenco selezionato proteggerà i tuoi servizi da future interruzioni del servizio, a causa di modifiche della CA, e manterrà i servizi in esecuzione oltre la scadenza sia di GTS Root R1 Cross che di GlobalSign Root CA - R1.

Fai riferimento alla domanda Sto creando un prodotto che si collega ai servizi Google. Quali certificati CA devo fidare? nelle Domande frequenti su GTS per ulteriori consigli.

Perché non dovrei installare certificati CA fogliali o intermedi?

Se procedi, rischierai di danneggiare la tua applicazione in qualsiasi momento quando registriamo un nuovo certificato o cambiamo le CA intermedie. Ognuno di questi scenari può verificarsi in qualsiasi momento e senza preavviso e si applica in modo uniforme ai singoli certificati del server, come quelli gestiti da maps.googleapis.com, nonché a ciascuna delle nostre CA intermedie, come GTS Root R1 Cross.

Per proteggere i tuoi servizi da questo problema, devi installare solo i certificati radice dal pacchetto CA radice di Google attendibile e affidarti esclusivamente al certificato radice per verificare l'affidabilità dell'intera catena di certificati ancora collegata.

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

Le applicazioni JavaScript sono a rischio di rottura?

I certificati radice GTS sono già ben incorporati e attendibili dalla maggior parte dei browser moderni e il segno incrociato di GMO GlobalSign dovrebbe garantire una migrazione senza problemi anche per la maggior parte degli utenti finali sui browser precedenti. Sono inclusi tutti i browser ufficialmente supportati per l'API Maps JavaScript.

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

Le app per dispositivi mobili sono a rischio di rottura?

Anche i dispositivi Android e Apple iOS che continuano a ricevere aggiornamenti regolari dal produttore dei dispositivi sono previsti per il futuro. La maggior parte dei modelli di telefoni Android precedenti include almeno il certificato GlobalSign Root CA - R1, anche se l'elenco dei certificati attendibili può variare in base al produttore, al modello del dispositivo e alla versione di Android del dispositivo.

Tuttavia, il supporto per le CA radice di 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 autorità di certificazione radice attendibili per ogni versione recente di iOS nelle proprie pagine di assistenza. Tuttavia, tutte le versioni 5 e successive di iOS supportano GlobalSign Root CA - R1.

Le CA radice di GTS, incluso GTS Root R1 sono supportate dalla versione 12.1.3 di iOS.

Consulta la domanda Come posso controllare i certificati radice attendibili sul mio cellulare? per avere ulteriori dettagli.

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

Negli ultimi anni Google ha lavorato a stretto contatto con tutte le principali terze parti che gestiscono pacchetti di certificati radice ampiamente utilizzati e attendibili. Alcuni esempi includono produttori di sistemi operativi, come Apple e Microsoft, ma anche i team Android e Chrome OS di Google, gli sviluppatori di browser come Mozilla, Apple e Microsoft, ma anche il team Chrome di Google, i produttori di hardware, come telefoni, decoder, TV, console per videogiochi, stampanti, per citarne solo alcuni.

È quindi molto probabile che qualsiasi sistema attualmente gestito supporti già le nuove CA radice di Google Workspace, tra cui GTS Root R1, e anche i sistemi legacy hanno molto probabilità di supportare GlobalSign Root CA - R1, che verrà utilizzato per la firma incrociata dei certificati emessi da Google nel corso degli anni successivi.

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

Seleziona terze parti, ad esempio il programma per i certificati CA di Mozilla potrebbero aver documentato le proprie tempistiche di inclusione dei certificati.

Risoluzione dei problemi

Dove posso trovare gli strumenti che mi servono?

Faccina arricciata

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

Scaricare OpenSSL

Se la distribuzione del sistema operativo non fornisce openssl, puoi scaricare il codice sorgente da https://www.openssl.org/ e compilare lo strumento. Un elenco di programmi binari creati da terze parti è disponibile all'indirizzo https://www.openssl.org/community/binaries.html. Tuttavia, nessuna di queste build è supportata o supportata in modo specifico 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 dei primi due per altri sistemi operativi sono disponibili all'indirizzo https://www.wireshark.org.

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

La documentazione di questi utili strumenti può essere consultata nella guida dell'utente di Wireshark, nella pagina Man di Tshark e nella man pagina di Tcpdump.

Recupero di Java keytool

Lo strumento a riga di comando keytool deve essere fornito con ogni versione Java Development Kit (JDK) o Java Runtime Environment (JRE). Installale per ottenere keytool.. È tuttavia improbabile che utilizzare keytool per la verifica del certificato radice sia necessario, a meno che la tua applicazione non sia stata creata con Java.

Cosa fare in caso di interruzione della produzione

L'azione principale per te è installare i certificati radice richiesti dal pacchetto CA radice di Google attendibile nel certificato radice che utilizza l'applicazione.

  1. Collabora con i tuoi amministratori di sistema per eseguire l'upgrade del tuo archivio certificati radice locale.
  2. Consulta queste Domande frequenti per verificare i suggerimenti applicabili al tuo sistema.
  3. Se hai bisogno di ulteriore assistenza specifica della piattaforma o del 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 Google Maps Platform. Nota: per i problemi specifici della piattaforma, le linee guida vengono fornite solo nel miglior modo possibile.
  5. Aggiungi il problema pubblico 186840968 per ulteriori aggiornamenti relativi alla migrazione.

Contattare l'assistenza Google Maps Platform

Risoluzione dei problemi iniziale

Per istruzioni generali sulla risoluzione dei problemi, consulta la sezione Come verificare se il mio archivio certificati radice richiede un aggiornamento.

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

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

  1. Dove si trovano i server interessati?
  2. Quali indirizzi IP di Google sta chiamando il tuo servizio?
  3. Quali API sono interessate dal 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.r1demo.pki.goog/; \
    openssl s_client -connect good.r1demo.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.r1xdemo.pki.goog/; \
    openssl s_client -connect good.r1xdemo.pki.goog:443 -showcerts </dev/null;
    

Per le istruzioni su come ottenere gli strumenti richiesti, consulta la domanda Dove posso trovare gli strumenti che mi servono?.

Presentazione di una richiesta di assistenza

Segui le istruzioni per la creazione di una richiesta di assistenza nella sezione Assistenza e risorse di Google Maps Platform.

Quando invii una richiesta di assistenza, oltre ai dati elencati nella sezione Risoluzione dei problemi iniziale, ti invitiamo a fornire anche:

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

Per le istruzioni su come ottenere gli strumenti richiesti, consulta la domanda Dove posso trovare gli strumenti che mi servono?.

Pubblicazione su problema pubblico 186840968

Quando pubblichi un commento su un problema pubblico 186840968, includi le informazioni riportate 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 curl

L'esecuzione di curl con i flag -vvI fornisce informazioni molto utili. Di seguito sono riportate alcune istruzioni per l'interpretazione dell'output:

  • Righe che iniziano con '*' visualizzano l'output della negoziazione TLS e informazioni sulla terminazione della connessione.
  • Le righe che iniziano con '>' mostrano la richiesta HTTP in uscita che curl invia.
  • Le righe che iniziano con '<' mostrano la risposta HTTP che ricevono dal server.
  • Se il protocollo era HTTPS, la presenza di '>' o '<' righe implica un handshake TLS riuscito.

Pacchetto di certificato radice e libreria TLS utilizzato

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

L'output da una macchina Red Hat Linux con curl collegato a NSS può contenere queste righe:

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

L'output da un computer Ubuntu o Debian Linux può contenere queste 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 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 il tuo sistema.

Esempio di 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à handshake TLS per via di un certificato 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

Un handshake TLS riuscito è indicato dalla presenza di righe dall'aspetto simile a quelle in questo esempio di codice. Dovresti elencare 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 < indica che il traffico HTTP di 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 server ricevuti in formato leggibile

Supponendo che l'output sia in formato PEM, ad esempio dall'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 codificato di Base 64, inclusi intestazione e piè di pagina:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • Poi:

    openssl x509 -inform pem -noout -text
    ````
    
  • Successivamente, incolla i contenuti del buffer di copia nel terminale.

  • Premi il tasto Invio.

Ad esempio, puoi inserire la sezione di output e output Come stampare i certificati PEM in formato leggibile.

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

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

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

---
…

Gestione dei certificati attendibili

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

Certificati attendibili Android

Come accennato nella domanda Le app per dispositivi mobili sono a rischio di rottura?, Dalla versione 4.0, Android ha consentito agli utenti di telefoni di verificare l'elenco di certificati attendibili nella sezione Impostazioni. Questa tabella mostra l'esatto percorso del menu Impostazioni:

Versione di Android Percorso 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 & Posizione > Crittografia & credenziali > Credenziali attendibili
10+ Impostazioni > Sicurezza > Avanzate > Crittografia & credenziali > Credenziali attendibili

Questa tabella illustra la probabile disponibilità dei certificati radice più critici per versione di Android, in base alla verifica manuale utilizzando le immagini di sistema Android Virtual Device (AVD) attualmente disponibili, che fanno riferimento alla cronologia delle versioni del repository AOSP, in cui le immagini di sistema non erano più disponibili:

Versione di Android Root RTS GTS 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+

In genere, l'aggiornamento dell'archivio dei certificati radice del sistema Android non è possibile senza un aggiornamento del firmware o il rooting del dispositivo. Tuttavia, nella maggior parte delle versioni di Android ancora in uso, l'insieme di certificati radice attendibili probabilmente è in grado di fornire un servizio senza interruzioni per molti anni a lungo, 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 ritenuti attendibili solo dalle loro applicazioni. 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 la sicurezza e la privacy Configurazione della sicurezza di rete.

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

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

Store per iOS

Sebbene Apple non mostri direttamente l'insieme predefinito di certificati radice attendibili all'utente del dispositivo, l'azienda ha link che rimandano agli insiemi di CA radice attendibili per iOS versione 5 e successive dagli articoli del Supporto Apple:

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ù critici per versione di iOS, in base alle origini sopra indicate:

Versione iOS Root RTS GTS 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 o versioni successive

Dove sono i miei certificati radice di sistema e come posso aggiornarli?

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 precedenti di RHEL e CententOS
  • /etc/pki/ca-trust/source/anchors e /usr/share/pki/ca-trust-source: Fedora, nuove versioni RHEL e CentOS
  • /var/lib/ca-certificates: OpenSUSE

Altri percorsi di certificato possono includere:

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

Alcuni 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 certificati predefinito predefinito, utilizzando il seguente comando:

openssl version -d

Il comando stampa OPENSSLDIR, che corrisponde alla directory di primo livello in cui si trova la libreria e le sue configurazioni:

OPENSSLDIR: "/usr/lib/ssl"

L'archivio dei certificati radice si trova nella sottodirectory certs.

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs
ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

Se OpenSSL si basa sull'archivio dei certificati radice del sistema predefinito come nell'esempio sopra, controlla la sezione di primo livello Dove si trova il mio certificato radice del sistema e come posso aggiornarlo? per assicurarti che il pacchetto del certificato radice del sistema sia aggiornato.

Per le istruzioni su come ottenere openssl, consulta la sezione Come ottenere OpenSSL.

Archivio certificati radice Java

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

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

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 di certificato univoco ma significativo e certs.jks con il file di database del certificato utilizzato nel tuo ambiente.

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

Archivio certificati radice Mozilla NSS

Per impostazione predefinita, le applicazioni che utilizzano Mozilla NSS possono utilizzare anche un database di certificati a livello di sistema, solitamente disponibile in /etc/pki/nssdb, o un archivio predefinito specifico per l'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 del certificato significativo e certdir con il percorso del database del certificato utilizzato nel tuo ambiente.

Per ulteriori informazioni, consulta il certificato NSS Tools ufficiale, nonché la documentazione del tuo sistema operativo.

Archivio certificati radice .NET Microsoft

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

Formati file certificato

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 crittografici, chiavi e così via, ufficializzato come standard de-jure in RFC 7468.

Anche se il formato file è facilmente leggibile, le informazioni dei certificati binari con codifica 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à anche per fornire un riepilogo chiaro degli elementi di dati più pertinenti in un certificato.

Gli strumenti come openssl possono essere utilizzati anche per decodificare l'intero certificato in una forma leggibile. Per ulteriori 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?

Ddistinzione delle regole di codifica (DER) è un formato binario standardizzato per i certificati di codifica. I certificati nei file PEM sono in genere certificati DER Base64.

Che cos'è un file "cer"?

Un file esportato con un suffisso ".cer" può contenere un certificato con codifica PEM, ma in genere un certificato binario, solitamente con codifica DER. Per convenzione, i file "&cert;.cer" in genere contengono un solo certificato.

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

Alcuni sistemi, ad esempio Java keytool può importare un singolo certificato da un file PEM, anche se ne contiene diversi. Vedi la domanda Come estratto i singoli certificati da roots.pem? per vedere come si può suddividere prima il file.

Come faccio a estrarre singoli certificati da roots.pem?

Puoi suddividere roots.pem nei relativi certificati di 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

Dovrebbero essere creati diversi 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 convertiti ulteriormente in un formato file accettato dall'archivio dei 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 elencate le istruzioni per la conversione da un file PEM ai formati di file di certificato più utilizzati.

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

Per le istruzioni su come ottenere openssl, consulta la sezione Come ottenere OpenSSL.

Come faccio a convertire un file PEM in formato DER?

Utilizzando openssl puoi emettere il seguente comando per convertire un file da PEM in DER:

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

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

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

Utilizzando openssl puoi emettere 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 n. 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.

Elencare, stampare ed esportare i certificati dal tuo archivio certificati radice

Come faccio a esportare un certificato dall'archivio delle chiavi Java come file PEM?

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

keytool -v -list -keystore certs.jks

Devi solo sostituire certs.jks con il file del database del certificato utilizzato nel tuo ambiente. Questo comando mostrerà 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 di database del certificato 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.

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

Utilizzando certutil puoi emettere il seguente comando per elencare tutti i certificati nel tuo archivio certificati, insieme al nickname che puoi utilizzare per esportarli tutti:

certutil -L -d certdir

Devi solo sostituire certdir con il percorso del database del certificato utilizzato nel tuo ambiente. Questo comando mostrerà anche il nickname di ciascun certificato, che ti servirà se vuoi 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 del certificato utilizzato nel tuo ambiente e fornire un cert-name e un cert.pem corrispondenti al certificato che vuoi esportare.

Per ulteriori informazioni, consulta il certificato NSS Tools ufficiale, nonché la documentazione del tuo sistema operativo.

Come stampare i certificati PEM in formato leggibile

Negli esempi riportati di seguito supponiamo che tu abbia il file GTS_Root_R1.pem con il seguente contenuto:

# 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 di file di certificato tramite OpenSSL

Emissione del comando

openssl x509 -in GTS_Root_R1.pem -text

dovrebbe restituire qualcosa di simile a:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

Per le istruzioni su come ottenere openssl, consulta la sezione Come ottenere OpenSSL.

Stampa dei certificati con Java keytool

Emissione del seguente comando

keytool -printcert -file GTS_Root_R1.pem

dovrebbe restituire qualcosa di simile a:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Per le istruzioni su come ottenere keytool, consulta la sezione Come ottenere uno strumento chiave Java.

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

I dati variano 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 certificati radice in genere offrono anche la possibilità di elencare i certificati installati.

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

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

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

I browser web possono utilizzare il proprio archivio di certificati radice o affidarsi a quello predefinito fornito dall'operatore. Tuttavia, tutti i browser moderni dovrebbero consentirti di gestire o almeno visualizzare l'insieme di CA radice di cui si fidano. Vedi la domanda Le applicazioni JavaScript rischiano di funzionare? Per ulteriori dettagli.

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

Appendice

Hai bisogno di ulteriori informazioni?

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

Qualsiasi altra fonte di informazioni incluse queste Domande frequenti potrebbe essere obsoleta o in altro modo non corretta e non deve essere considerata autorevole. Tuttavia, potresti comunque trovare informazioni utili su molte delle community Domande e risposte di Stack Exchange, nonché su siti come AdamW su Linux e altri e il blog di conferma, tra gli altri.

Consulta anche le Domande frequenti su Google Trust Services.

Per ulteriori dettagli sugli argomenti avanzati, come il blocco dei certificati, puoi trovare l'articolo Open Web Application Security Project (OWASP) Certificate and Public Key Pinning e Pinning Cheat Sheet informativo. Per istruzioni specifiche per Android, consulta il documento ufficiale di formazione su Best practice per la sicurezza e la privacy per Android. Sicurezza con HTTPS e SSL. Per discussioni sul blocco delle chiavi pubbliche o dei certificati su Android, potresti trovare utile il post del blog di Matthew Dolan Android Security: SSL Pinning.

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

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