Panoramica dei certificati SSL

SSL/TLS è il protocollo crittografico più utilizzato su internet. Tecnicamente, TLS è il successore di SSL, anche se i termini vengono talvolta utilizzati in modo intercambiabile, come in questo documento.

Transport Layer Security (TLS) viene utilizzato per criptare le informazioni durante l'invio su una rete, garantendo la privacy tra un client e un server o un bilanciatore del carico. Un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete proxy che utilizza SSL richiede almeno una chiave privata e un certificato SSL.

Questa pagina illustra i certificati SSL e la crittografia in transito tra un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete proxy che utilizza SSL e i relativi client. Per maggiori dettagli sulla crittografia in transito tra il bilanciatore del carico Google Cloud e i relativi backend, consulta Crittografia dei backend.

Metodi di configurazione dei certificati

Google Cloud offre tre metodi di configurazione dei certificati per i bilanciatori del carico delle applicazioni che utilizzano proxy HTTPS di destinazione e i bilanciatori del carico di rete proxy che utilizzano proxy SSL di destinazione.

  • Il proxy di destinazione fa riferimento ai certificati SSL di Compute Engine: con questo metodo, il proxy di destinazione del bilanciatore del carico può fare riferimento a un massimo di 15 risorse certificato SSL di Compute Engine. Ogni risorsa del certificato SSL di Compute Engine contiene la chiave privata, il certificato corrispondente e, facoltativamente, i certificati CA.

  • Il proxy di destinazione fa riferimento a una mappa dei certificati di Certificate Manager: con questo metodo, il proxy di destinazione del bilanciatore del carico fa riferimento a una singola mappa dei certificati. La mappa dei certificati supporta migliaia di voci per impostazione predefinita e può scalare fino a milioni di voci. Ogni voce contiene i dati della chiave privata e del certificato.

  • Il proxy di destinazione fa riferimento direttamente ai certificati di Certificate Manager: con questo metodo, il proxy di destinazione del bilanciatore del carico può fare riferimento a un massimo di 100 certificati di Certificate Manager.

Supporto del bilanciatore del carico

La tabella seguente mostra i metodi di configurazione dei certificati supportati da ciascun bilanciatore del carico.

Bilanciatore del carico Metodo di configurazione del certificato
Certificati SSL di Compute Engine Certificate Manager (mappa dei certificati) Certificate Manager (certificati individuali)
Bilanciatori del carico delle applicazioni (proxy HTTPS di destinazione)
Bilanciatore del carico delle applicazioni esterno globale Autogestito
Gestito da Google
Autogestito
Gestito da Google
Bilanciatore del carico delle applicazioni classico Autogestito
Gestito da Google
Autogestito
Gestito da Google
Bilanciatore del carico delle applicazioni esterno regionale Gestito autonomamente
Gestito da Google
Autogestito
Gestito da Google
Bilanciatore del carico delle applicazioni interno regionale Gestito autonomamente
Gestito da Google
Autogestito
Gestito da Google
Bilanciatore del carico delle applicazioni interno tra regioni Gestito autonomamente
Gestito da Google
Bilanciatori del carico di rete proxy (proxy SSL di destinazione)
Bilanciatore del carico di rete proxy esterno globale Gestito autonomamente
Gestito da Google
Autogestito
Gestito da Google
Bilanciatore del carico di rete proxy classico Autogestito
Gestito da Google
Autogestito
Gestito da Google

Regole dei metodi di configurazione

Google Cloud applica le seguenti regole del metodo di configurazione dei certificati:

  • Per i bilanciatori del carico che supportano sia i certificati SSL di Compute Engine sia le mappe dei certificati di Certificate Manager: il proxy di destinazione del bilanciatore del carico può fare riferimento contemporaneamente a una mappa dei certificati e a uno o più certificati SSL di Compute Engine.

  • Per i bilanciatori del carico che supportano sia i certificati SSL di Compute Engine sia i certificati di Certificate Manager collegati direttamente: il proxy di destinazione del bilanciatore del carico può essere configurato solo per fare riferimento a un massimo di 15 certificati SSL di Compute Engine o a un massimo di 100 certificati di Certificate Manager, non a una combinazione di entrambi.

Tipi di certificati

Google Cloud supporta i certificati autogestiti e gestiti da Google.

Certificati SSL autogestiti

I certificati SSL autogestiti sono certificati che ottieni, di cui esegui il provisioning e che rinnovi autonomamente. I certificati autogestiti possono essere di uno dei seguenti tipi di certificato di chiave pubblica:

  • Domain Validation (DV)
  • Organization Validation (OV)
  • Certificati Extended Validation (EV)

Puoi creare certificati SSL autogestiti utilizzando:

Certificati SSL gestiti da Google

I certificati SSL gestiti da Google sono certificati che Google Cloudottiene, gestisce e rinnova automaticamente. I certificati gestiti da Google sono sempre certificati Domain Validation (DV). Non dimostrano l'identità di un'organizzazione o di un privato associato al certificato.

I certificati gestiti da Google che utilizzano caratteri jolly sono supportati da Certificate Manager solo se utilizzi l'autorizzazione DNS.

Puoi creare certificati SSL gestiti da Google utilizzando:

  • Risorse dei certificati SSL di Compute Engine: solo le risorse sslCertificates globali di Compute Engine supportano i certificati SSL gestiti da Google; le risorse regionSslCertificates non li supportano. I certificati SSL globali di Compute Engine supportano solo i certificati gestiti da Google pubblicamente attendibili. Per saperne di più, consulta Utilizza i certificati SSL gestiti da Google.
  • Certificate Manager: i certificati di Certificate Manager (sia globali che regionali) supportano i certificati gestiti da Google con attendibilità pubblica e privata. Per saperne di più, consulta Certificati nella documentazione di Certificate Manager.

Tipi di chiavi supportati

I bilanciatori del carico supportano i certificati che utilizzano chiavi private di diversi tipi di chiavi. La tabella seguente mostra il supporto dei tipi di chiavi a seconda che i certificati siano globali o regionali e che siano autogestiti o gestiti da Google.
Tipo di certificato SSL arrow_forward

Tipo di chiave arrow_downward
Certificati SSL di Compute Engine Certificati SSL di Certificate Manager
Globale Regionale Globale e regionale
Autogestito Certificati gestiti da Google con attendibilità pubblica Autogestito Autogestito Certificati gestiti da Google con attendibilità pubblica Gestito da Google con attendibilità privata
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384
Per scoprire di più sui certificati di Certificate Manager, consulta la documentazione di Certificate Manager.

Utilizza certificati con chiavi ECDSA

Questa sezione esamina il motivo per cui consigliamo ECDSA rispetto a RSA come best practice per le chiavi di firma dei certificati.

Quale tipo di chiave utilizzare

ECDSA P-256 è il tipo di chiave consigliato per la maggior parte dei certificati TLS, in quanto offre una solida sicurezza crittografica, prestazioni eccellenti per le operazioni di firma e un utilizzo efficiente della larghezza di banda della rete.

Ecco alcuni dei possibili motivi per utilizzare altri tipi di chiavi di certificato:

  • Se devi supportare client legacy che non supportano i certificati ECDSA, puoi fornire certificati RSA-2048 oltre ai certificati ECDSA P-256.
  • Se hai requisiti di conformità specifici che richiedono l'utilizzo di chiavi di dimensioni maggiori o di tipi di chiavi particolari, puoi utilizzare le chiavi ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Perché scegliere ECDSA anziché RSA

Il vantaggio principale di ECDSA risiede nella sua capacità di fornire un livello di sicurezza crittografica equivalente con chiavi significativamente più piccole rispetto a RSA. Questa efficienza si traduce in vantaggi tangibili in termini di prestazioni e risorse. Una chiave più piccola non implica una sicurezza più debole: ECDSA si basa sul problema del logaritmo discreto della curva ellittica, che fornisce una sicurezza più elevata per unità di chiave e, in alcuni casi, una migliore efficienza computazionale rispetto a RSA.

Ad esempio:

  • Una chiave ECDSA a 256 bit fornisce un livello di sicurezza simile a una chiave RSA-3072.
  • Una chiave ECDSA a 384 bit offre un livello di sicurezza superiore rispetto a qualsiasi dimensione di chiave RSA ampiamente supportata.

Vantaggi principali di ECDSA:

  • Prestazioni: le operazioni di firma ECDSA sono molto meno intensive dal punto di vista computazionale rispetto alle operazioni RSA che forniscono un livello di sicurezza equivalente. In questo modo si riducono il carico della CPU e la latenza, il che è fondamentale per i sistemi con throughput elevato o sensibili alla latenza.

  • Efficienza: chiavi e firme più piccole richiedono meno larghezza di banda e spazio di archiviazione, il che è particolarmente vantaggioso per gli ambienti con risorse limitate come i dispositivi mobili e IoT.

Più certificati SSL

Un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete proxy può ospitare due o più certificati SSL contemporaneamente se il proxy di destinazione è configurato utilizzando un metodo di configurazione dei certificati supportato. Come best practice, utilizza Certificate Manager quando sono necessari più certificati SSL.

  • Per i bilanciatori del carico che supportano i certificati SSL di Compute Engine: il proxy di destinazione del bilanciatore del carico può fare riferimento a un massimo di 15 certificati SSL di Compute Engine. La prima risorsa del certificato SSL di Compute Engine a cui viene fatto riferimento è il certificato predefinito (principale) per il proxy di destinazione.

  • Per i bilanciatori del carico che supportano una mappa dei certificati di Certificate Manager: il proxy di destinazione del bilanciatore del carico fa riferimento a una singola mappa dei certificati. La mappa dei certificati supporta migliaia di voci della mappa dei certificati. Puoi configurare quale voce del certificato è il certificato predefinito (principale) per la mappa dei certificati.

  • Per i bilanciatori del carico che supportano il riferimento diretto ai certificati di Certificate Manager: il proxy di destinazione del bilanciatore del carico può fare riferimento a un massimo di 100 certificati di Certificate Manager. La prima risorsa del certificato SSL di Certificate Manager a cui viene fatto riferimento è il certificato predefinito (principale) per il proxy di destinazione.

Per saperne di più, vedi:

Procedura di selezione dei certificati

La seguente procedura di selezione dei certificati si applica ai bilanciatori del carico i cui proxy di destinazione fanno riferimento a più certificati SSL di Compute Engine o a più certificati di Certificate Manager.

La procedura di selezione dei certificati è diversa se il proxy di destinazione di un bilanciatore del carico fa riferimento a una mappa dei certificati di Certificate Manager. Per maggiori dettagli sulla procedura di selezione dei certificati di una mappa dei certificati, consulta Logica di selezione dei certificati nella documentazione di Certificate Manager.

Dopo che un client si connette al bilanciatore del carico, il client e il bilanciatore del carico negoziano una sessione TLS. Durante la negoziazione della sessione TLS, il client invia al bilanciatore del carico un elenco di crittografie TLS supportate (in ClientHello). Il bilanciatore del carico seleziona un certificato il cui algoritmo di chiave pubblica è compatibile con il client. Il client può anche inviare un nome host SNI (Server Name Indication) al bilanciatore del carico nell'ambito di questa negoziazione. I dati del nome host SNI vengono talvolta utilizzati per aiutare il bilanciatore del carico a scegliere il certificato da inviare al client.

  • Se il proxy di destinazione del bilanciatore del carico fa riferimento a un solo certificato, viene utilizzato quel certificato e il valore del nome host SNI inviato dal client non è pertinente.

  • Se il proxy di destinazione del bilanciatore del carico fa riferimento a due o più certificati, il bilanciatore del carico utilizza la seguente procedura per selezionare un singolo certificato:

    • Se il client non ha inviato alcun nome host SNI nel suo ClientHello, il bilanciatore del carico utilizza il primo certificato nell'elenco dei certificati.

    • Se il client invia un nome host SNI che non corrisponde ad alcun nome comune (CN) del certificato e che non corrisponde ad alcun nome alternativo del soggetto (SAN) del certificato, il bilanciatore del carico utilizza il primo certificato nell'elenco dei certificati.

    • In tutte le altre situazioni, il bilanciatore del carico seleziona un certificato utilizzando il seguente processo di corrispondenza:

      • La corrispondenza viene eseguita sia con gli attributi del certificato del nome comune (CN) sia con quelli del nome alternativo del soggetto (SAN). Se un solo certificato corrisponde al nome host SNI, il bilanciatore del carico seleziona quel certificato. Se più certificati corrispondono al nome host SNI, il bilanciatore del carico li assegna in ordine di priorità come segue:

        • Corrispondenza esatta del nome host: le corrispondenze esatte con il CN o il SAN hanno la precedenza sulle corrispondenze con caratteri jolly.

        • Corrispondenza del nome host con caratteri jolly: se non esiste una corrispondenza esatta, il bilanciatore del carico verifica la presenza di una corrispondenza CN o SAN con caratteri jolly. Un carattere jolly (*) corrisponde solo al sottodominio di primo livello (ad esempio, *.pets.example.com corrisponde a cats.pets.example.com anziché a *.example.com).

        • Tipo di chiave del certificato: i certificati ECDSA sono preferiti rispetto ai certificati RSA.

        • Dimensioni della catena di certificati: se più certificati hanno la stessa specificità di corrispondenza e lo stesso algoritmo di chiave pubblica, il bilanciatore del carico dà la priorità al certificato con la catena di certificati di dimensioni inferiori (in byte) per ridurre al minimo la larghezza di banda della rete durante il TLS handshake.

      • Per illustrare il metodo di corrispondenza, considera un proxy di destinazione che fa riferimento ai seguenti due certificati:

        • Certificato A

          • CN: cats.pets.example.com
          • SAN: cats.pets.example.com, *.pets.example.com, *.example.com
        • Certificato B

          • CN: dogs.pets.example.com
          • SAN: dogs.pets.example.com, *.pets.example.com, *.example.com
      • Ora considera i seguenti scenari:

        • Se il nome host SNI inviato dal client è cats.pets.example.com, il bilanciatore del carico utilizza il certificato A.

        • Se il nome host SNI inviato dal client è ferrets.pets.example.com, non esiste una corrispondenza esatta e sia il certificato A sia il certificato B corrispondono a *.pets.example.com nell'elenco dei SAN. Se entrambi i certificati utilizzano lo stesso algoritmo di chiave pubblica, il bilanciatore del carico seleziona il certificato con la dimensione della catena di certificati più piccola. Se anche le dimensioni della catena di certificati sono identiche, il bilanciatore del carico seleziona il certificato A o il certificato B e non puoi controllare quale certificato viene selezionato.

  • Dopo aver selezionato un certificato, il bilanciatore del carico lo invia al client solo se il certificato selezionato utilizza un algoritmo di chiave pubblica compatibile con una crittografia inviata dal client in ClientHello. La negoziazione TLS non va a buon fine se il client non supporta una suite di crittografia che include l'algoritmo di chiave pubblica (ECDSA o RSA) del certificato selezionato dal bilanciatore del carico.

Prezzi

Per i prezzi dei certificati SSL di Compute Engine e di Cloud Load Balancing, consulta Prezzi di rete: Cloud Load Balancing.

Per i prezzi di Certificate Manager, consulta la pagina dei prezzi di Certificate Manager.

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia senza costi