Opzioni per la configurazione di TLS

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questa sezione mostra come configurare TLS per il traffico da un proxy a un target.

Informazioni sull'impostazione delle opzioni TLS in un endpoint di destinazione o in un server di destinazione

Un target può essere rappresentato da un oggetto XML come quello riportato di seguito:

<HTTPTargetConnection>
    <Properties/>
    <URL>https:myTargetAddress</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <Enforce>true</Enforce>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols>myProtocols</Protocols>
        <Ciphers>myCipher</Ciphers>
    </SSLInfo>
</HTTPTargetConnection>

L'area della configurazione dell'endpoint di destinazione che modifichi per configurare TLS è definita dal tag <SSLInfo>. Utilizzi lo stesso tag <SSLInfo> per configurare un endpoint di destinazione o un server di destinazione.

Per informazioni sugli elementi secondari di <SSLInfo>, consulta Configurazione di TargetEndpoint TLS/SSL.

La tabella seguente descrive gli elementi di configurazione TLS utilizzati dal tag <SSLInfo>:

Elemento Descrizione
<Enabled> Il blocco <SSLInfo> può essere utilizzato per TLS/SSL unidirezionale e bidirezionale.

Se impostato su true, <Enabled> specifica che deve essere utilizzato il blocco <SSLInfo>. Se impostato su false, il blocco <SSLInfo> viene ignorato.

Il valore predefinito di <Enabled> è true se <URL> specifica il protocollo HTTPS, e false se <URL> specifica HTTP.
<Enforce>

Applica SSL rigoroso tra Apigee e il backend di destinazione.

Se impostato su true, le connessioni non andranno a buon fine per le destinazioni con certificati non validi, scaduti, autofirmati, con mancata corrispondenza del nome host e con una radice non attendibile. Viene restituito un codice di errore 4xx o 5xx.

Se non è impostato o è impostato su false, il risultato delle connessioni ai backend di destinazione con certificati problematici dipende dall'impostazione di <IgnoreValidationErrors> (vedi sotto). Una risposta di successo (2xx) può verificarsi in determinate condizioni, se <IgnoreValidationErrors> è impostato su true.
<ClientAuthEnabled>

Consente TLS bidirezionale (noto anche come mutual TLS o mTLS) tra Apigee e il client API oppure tra Apigee e il backend di destinazione.

L'attivazione di TLS bidirezionale in genere richiede la configurazione di un truststore su Apigee e di un truststore.
<KeyStore> Un keystore contenente le chiavi private utilizzate per l'autenticazione client in uscita
<KeyAlias> L'alias specificato quando hai caricato un certificato e una chiave privata nell'archivio chiavi.
<TrustStore> Un keystore contenente certificati server attendibili.
<IgnoreValidationErrors>

Indica se gli errori di convalida vengono ignorati. Se il sistema di backend utilizza SNI e restituisce un certificato con un nome distinto (DN) del soggetto che non corrisponde al nome host, non è possibile ignorare l'errore e la connessione non va a buon fine.

Nota: se <Enforce> è impostato su true, il valore di <IgnoreValidationErrors> viene ignorato.
<Ciphers>

Crittografie supportate per TLS/SSL in uscita. Se non vengono specificate cifrature, saranno consentite tutte le cifrature disponibili per la JVM.

Per limitare le cifrature, aggiungi i seguenti elementi che elencano le cifrature supportate:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
<Protocols>

Protocolli supportati per TLS/SSL in uscita. Se non vengono specificati protocolli, saranno consentiti tutti i protocolli disponibili per la JVM.

Per limitare i protocolli, specificali in modo esplicito. Ad esempio, per consentire solo TLS v1.2 o TLS v1.3:

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

Informazioni sull'impostazione degli elementi <KeyStore> e <TrustStore>

Nell'esempio precedente, il keystore e il truststore vengono specificati utilizzando riferimenti, nel formato:

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

Apigee consiglia vivamente di utilizzare sempre i riferimenti al keystore e al truststore. Un riferimento è una variabile che contiene il nome dell'archivio chiavi o dell'archivio attendibile, anziché specificare direttamente il nome dell'archivio chiavi. In questo esempio:

  • myKeystoreRef è un riferimento che contiene il nome del keystore. In questo esempio, il nome del keystore è myKeystore.
  • myTruststoreRef è un riferimento che contiene il nome del truststore. In questo esempio, il nome del truststore è myTruststore.

Quando un certificato scade, devi aggiornare l'endpoint di destinazione/il server di destinazione per specificare il keystore o il truststore contenente il nuovo certificato. Il vantaggio di un riferimento è che puoi modificare il valore del riferimento per cambiare il keystore o il truststore senza dover modificare l'endpoint di destinazione/il server di destinazione stesso:

La modifica del valore del riferimento non richiede di contattare l'assistenza clienti Google Cloud.

In alternativa, puoi specificare direttamente il nome dell'archivio chiavi e del truststore:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore>

Se specifichi direttamente il nome del keystore o del truststore, devi contattare l'assistenza clienti Google Cloud.

Una terza opzione è utilizzare le variabili di flusso:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore>

Puoi utilizzare le variabili di flusso per specificare in modo dinamico un keystore o un truststore, con un effetto simile all'utilizzo di un riferimento. Per ulteriori informazioni, vedi Utilizzare le variabili di flusso per impostare dinamicamente i valori TLS/SSL.

Informazioni sulla configurazione di TLS

Tutti i clienti Apigee, sia a pagamento che di valutazione, hanno il controllo completo della configurazione di endpoint di destinazione/server di destinazione. Inoltre, i clienti Apigee a pagamento hanno il controllo completo delle proprietà TLS.

Gestione dei certificati scaduti

Se un certificato TLS scade o se la configurazione del sistema cambia in modo che il certificato non sia più valido, devi aggiornarlo. Quando configuri TLS per un endpoint di destinazione/server di destinazione, devi decidere come eseguire l'aggiornamento prima di eseguire qualsiasi configurazione.

Quando un certificato scade

Su Apigee, i certificati vengono archiviati in una delle due posizioni seguenti:

  • Keystore: contiene il certificato TLS e la chiave privata utilizzati per identificare l'entità durante l'handshake TLS.
  • Truststore: contiene i certificati attendibili su un client TLS utilizzati per convalidare il certificato di un server TLS presentato al client. Questi certificati sono in genere certificati autofirmati, certificati firmati da una CA attendibile o certificati utilizzati nell'ambito di TLS bidirezionale (noto anche come TLS reciproco o mTLS).

Quando un certificato in un keystore scade e utilizzi un riferimento al keystore, non puoi caricare un nuovo certificato nel keystore. Invece, tu:

  1. Crea un nuovo keystore.
  2. Carica il nuovo certificato nel nuovo keystore utilizzando lo stesso nome alias del vecchio keystore.
  3. Aggiorna il riferimento nel server di destinazione/endpoint di destinazione per utilizzare il nuovo keystore.

Quando un certificato in un truststore scade e utilizzi un riferimento al truststore:

  1. Crea un nuovo truststore.
  2. Carica il nuovo certificato nel nuovo truststore. Il nome dell'alias non è importante per i truststore. Nota: se un certificato fa parte di una catena, devi creare un unico file contenente tutti i certificati e caricarlo in un singolo alias oppure caricare tutti i certificati della catena separatamente nel truststore utilizzando un alias diverso per ogni certificato.
  3. Aggiorna il riferimento nel server di destinazione/endpoint di destinazione per utilizzare il nuovo truststore.

Riepilogo dei metodi per aggiornare un certificato scaduto

Il metodo che utilizzi per specificare il nome del keystore e del truststore nell'endpoint di destinazione/nel server di destinazione determina la modalità di esecuzione dell'aggiornamento del certificato. Puoi utilizzare:

  • Riferimenti
  • Nomi diretti
  • Variabili di flusso

Ciascuno di questi metodi ha ripercussioni diverse sul processo di aggiornamento, come descritto nella tabella seguente:

Tipo di configurazione Come aggiornare/sostituire il certificato Utilizzo
Riferimento (consigliato) Per un archivio chiavi, crea un nuovo archivio chiavi con un nuovo nome e un alias con lo stesso nome del vecchio alias.

Per un truststore, creane uno con un nuovo nome.

 Aggiorna il riferimento al keystore o al truststore.

Non è necessario contattare l'assistenza Apigee.
Variabile di flusso Per un archivio chiavi, crea un nuovo archivio chiavi con un nuovo nome e un alias con lo stesso nome o con un nuovo nome.

Per un truststore, creane uno con un nuovo nome.

 Passa la variabile di flusso aggiornata in ogni richiesta con il nome del nuovo archivio chiavi, alias o archivio attendibile.

Non è necessario contattare l'assistenza Apigee.
Diretto Crea un nuovo keystore, alias e truststore. Esegui nuovamente il deployment del proxy.
Diretto Elimina il keystore o il truststore e ricrealo con lo stesso nome. Le richieste API non riusciranno finché non vengono impostati il nuovo keystore e il nuovo alias.

Se il keystore viene utilizzato per TLS bidirezionale (noto anche come TLS reciproco o mTLS) tra Apigee e il servizio di backend, contatta l'assistenza clienti di Google Cloud per riavviare i processori di messaggi.
Diretto Solo per il truststore, carica un nuovo certificato nel truststore. Contatta l'assistenza clienti Google Cloud per riavviare i Message Processor.