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 una destinazione.

Informazioni Impostare le opzioni TLS in un endpoint o 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>. Utilizza lo stesso tag <SSLInfo> per configurare un endpoint o un server di destinazione.

Per informazioni sugli elementi secondari di <SSLInfo>, consulta Configurazione dell'endpoint di destinazione TLS/SSL.

Nella tabella seguente vengono descritti gli elementi di configurazione TLS utilizzati dalla Tag <SSLInfo>:

Elemento Descrizione
<Enabled> Il blocco <SSLInfo> può essere utilizzato per TLS/SSL unidirezionale o 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 il criterio viene impostato su true, le connessioni non riusciranno per le destinazioni con certificati non validi, certificati scaduti certificati autofirmati, certificati con nome host non corrispondente e certificati con una radice non attendibile. Un codice di errore di 4xx o 5xx.

Se il criterio non viene configurato o se viene impostato su false, il risultato delle connessioni ai backend con cui scegliere come target certificati problematici dipendono dall'impostazione di <IgnoreValidationErrors> (vedi di seguito). In determinate condizioni, può verificarsi una risposta di operazione riuscita (2xx) se <IgnoreValidationErrors> è impostato su true.

<ClientAuthEnabled>

Attiva TLS a due vie (noto anche come TLS mutuale o mTLS) tra Apigee e l'API client o tra Apigee e il backend di destinazione.

L'attivazione del TLS bidirezionale in genere richiede la configurazione di un truststore su Apigee e di un altro su

<KeyStore> Un keystore contenente le chiavi private utilizzate per l'autenticazione dei client in uscita
<KeyAlias> L'alias specificato quando hai caricato un certificato e una chiave privata nell'archivio chiavi.
<TrustStore> Un keystore contenente certificati del 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) soggetto che non corrisponde al nome host; non c'è modo di ignorare l'errore e la connessione non riesce.

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

<Ciphers>

Crittografia supportate per TLS/SSL in uscita. Se non vengono specificati algoritmi di crittografia, saranno consentiti tutti gli algoritmi di crittografia disponibili per la JVM.

Per limitare le crittografie, aggiungi i seguenti elementi che elencano le crittografie 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 1.2 o TLS 1.3:

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

Informazioni sull'impostazione del &lt;KeyStore&gt; e <TrustStore> elementi

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

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

Apigee consiglia vivamente di utilizzare sempre i riferimenti all'archivio chiavi e all'archivio chiavi. R riferimento è una variabile che contiene il nome dell'archivio chiavi o dell'archivio chiavi, anziché specificando direttamente il nome dell'archivio chiavi. In questo esempio:

  • myKeystoreRef è un riferimento che contiene il nome dell'archivio chiavi. In questo esempio, il nome del keystore è myKeystore.
  • myTruststoreRef è un riferimento che contiene il nome del archivio attendibilità. In questo esempio, il nome del truststore è myTruststore.

Quando un certificato scade, devi aggiornare l'endpoint/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 l'archivio chiavi o l'archivio chiavi senza dover modifica l'endpoint/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 dell'archivio attendibile:

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

Se specifichi direttamente il nome dell'archivio chiavi o dell'archivio chiavi, devi contatta l'assistenza clienti Google Cloud.

Una terza opzione è utilizzare le variabili di flusso:

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

Il funzionamento delle variabili di flusso ti consente di aggiornare il keystore o il truststore come riferimenti. Per ulteriori informazioni, vedi Utilizzo delle 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 endpoint/server di destinazione. Inoltre, i clienti Apigee a pagamento hanno il controllo completo 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. Durante la configurazione di TLS per un endpoint/server di destinazione, devi decidere come eseguire l'aggiornamento prima di eseguire qualsiasi configurazione.

Alla scadenza di un certificato

In Apigee, puoi archiviare i certificati in due posizioni:

  • Archivio chiavi: contiene il certificato TLS e la chiave privata utilizzati per identificare la persona giuridica durante l'handshake TLS.
  • Truststore: contiene 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 un'autorità di certificazione attendibile o certificati utilizzati nell'ambito di un sistema bidirezionale TLS (noto anche come TLS reciproco o mTLS).

Quando un certificato in un keystore scade e utilizzi un riferimento all'archivio chiavi, non puoi caricare un nuovo certificato nell'archivio chiavi. Invece:

  1. Creare un nuovo archivio chiavi.
  2. Carica il nuovo certificato nel nuovo keystore utilizzando lo stesso nome dell'alias del vecchio keystore.
  3. Aggiornare il riferimento nel server/endpoint di destinazione per utilizzare il nuovo archivio chiavi.

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 singolo file contenente tutti i certificati e caricarlo su un singolo alias, oppure caricare tutti i certificati nel separatamente al truststore utilizzando un alias diverso per ciascun certificato.
  3. Aggiorna il riferimento nel server di destinazione/nell'endpoint di destinazione per utilizzare il nuovo truststore.

Riepilogo dei metodi per aggiornare un indirizzo scaduto cert

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

  • Riferimenti
  • Nomi diretti
  • Variabili di flusso

Ognuno di questi metodi ha ripercussioni diverse sul processo di aggiornamento, come descritto nel 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, crea un truststore 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 archivio attendibilità, crea un archivio attendibilità con un nuovo nome.

Passa la variabile di flusso aggiornata a ogni richiesta con il nome del nuovo archivio chiavi, dell'alias o del truststore.

Non è necessario contattare l'assistenza Apigee.

Diretto Creare un nuovo archivio chiavi, alias e archivio attendibilità. Esegui di nuovo il deployment del proxy.
Diretto Elimina l'archivio chiavi o l'archivio attendibili e ricrealo con lo stesso nome. Le richieste dell'API non andranno a buon fine finché non verranno impostati il nuovo keystore e l'alias.

Se l'archivio chiavi viene utilizzato per TLS a due vie (noto anche come TLS reciproca o mTLS) tra Apigee e il servizio di backend, Contatta l'assistenza clienti Google Cloud per riavviare i processori di messaggi.

Diretto Solo per l'archivio attendibilità, carica un nuovo certificato nell'archivio attendibili. Contatta l'assistenza clienti Google Cloud per riavviare i processori di messaggi.