Questa pagina si applica a Apigee e Apigee ibrido.
Visualizza la documentazione di Apigee Edge.
Questa sezione mostra come configurare TLS per il traffico da un proxy a una destinazione.
Informazioni sull'impostazione delle opzioni TLS in un endpoint o un server di destinazione
Un target può essere rappresentato da un oggetto XML come il seguente:
<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 la
configurazione di TargetEndpoint TLS/SSL.
La seguente tabella descrive gli elementi di configurazione TLS utilizzati dal
tag <SSLInfo>
:
Elemento | Descrizione |
---|---|
<Enabled> |
Il blocco <SSLInfo> può essere utilizzato per TLS/SSL unidirezionale o bidirezionale.
Se impostato su Il valore predefinito |
<Enforce> |
Applica il protocollo SSL rigoroso tra Apigee e il backend di destinazione. Se il criterio viene impostato su Se il criterio non viene configurato o se viene impostato su |
<ClientAuthEnabled> |
Abilita il protocollo TLS bidirezionale (noto anche come TLS reciproca o mTLS) tra Apigee e il client API o tra Apigee e il backend di destinazione. L'abilitazione del protocollo TLS a due vie in genere richiede la configurazione di un truststore su Apigee e un archivio attendibilità. |
<KeyStore> |
Un archivio chiavi contenente chiavi private utilizzate per l'autenticazione del client in uscita |
<KeyAlias> |
L'alias specificato quando hai caricato un certificato e una chiave privata nell'archivio chiavi. |
<TrustStore> |
Un archivio chiavi 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 riesce. Nota: se |
<Ciphers> |
Crittografia supportate per TLS/SSL in uscita. Se non vengono specificate crittografie, saranno consentite tutte le crittografie 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 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, l'archivio chiavi e l'archivio attendibili vengono specificati mediante i references, nel formato:
<KeyStore>ref://myKeystoreRef</KeyStore> <TrustStore>ref://myTruststoreRef</TrustStore>
Apigee consiglia vivamente di utilizzare sempre i riferimenti all'archivio chiavi e all'archivio chiavi. Un riferimento è una variabile che contiene il nome dell'archivio chiavi o dell'archivio chiavi, anziché specificare direttamente il nome dell'archivio chiavi. In questo esempio:
myKeystoreRef
è un riferimento che contiene il nome dell'archivio chiavi. In questo esempio, il nome dell'archivio chiavi è myKeystore.myTruststoreRef
è un riferimento che contiene il nome dell'archivio attendibilità. In questo esempio, il nome del truststore è myTruststore.
Quando un certificato scade, devi aggiornare l'endpoint/il server di destinazione per specificare l'archivio chiavi o l'archivio chiavi in cui si trova il nuovo certificato. Il vantaggio di un riferimento è che puoi modificarne il valore per cambiare l'archivio chiavi o l'archivio chiavi senza dover modificare 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 il nome dell'archivio chiavi:
<KeyStore>myKeystore</KeyStore> <TrustStore>myTruststore</TrustStore>
Se specifichi direttamente il nome dell'archivio chiavi o dell'archivio chiavi, devi contattare l'assistenza clienti Google Cloud.
Una terza opzione è quella di utilizzare le variabili di flusso:
<KeyStore>{ssl.keystore}</KeyStore> <TrustStore>{ssl.truststore}</TrustStore>
Le variabili di flusso consentono di aggiornare l'archivio chiavi o l'archivio chiavi come riferimenti. Per maggiori informazioni, consulta 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 sulla configurazione di endpoint/server di destinazione. Inoltre, i clienti Apigee a pagamento hanno il controllo completo sulle proprietà TLS.
Gestione dei certificati scaduti
Se un certificato TLS scade o se la configurazione di sistema viene modificata in modo che il certificato non sia più valido, devi aggiornarlo. Quando configuri TLS per un endpoint/un server di destinazione, devi decidere come eseguire l'aggiornamento prima di eseguire qualsiasi configurazione.
Alla scadenza di un certificato
Su Apigee, i certificati vengono archiviati in una di queste due posizioni:
- Archivio chiavi: 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 utilizzato 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 come parte di TLS a due vie (noto anche come TLS reciproco o mTLS).
Quando un certificato in un archivio chiavi scade e utilizzi un riferimento all'archivio chiavi, non puoi caricare un nuovo certificato nell'archivio chiavi. Devi:
- Creare un nuovo archivio chiavi.
- Carica il nuovo certificato nel nuovo archivio chiavi utilizzando lo stesso nome alias del vecchio archivio chiavi.
- 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:
- Crea un nuovo archivio attendibilità.
- Carica il nuovo certificato nel nuovo archivio attendibilità. 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 in un singolo alias oppure caricare tutti i certificati della catena separatamente nell'archivio attendibilità utilizzando un alias diverso per ogni certificato.
- Aggiorna il riferimento nel server/endpoint di destinazione di destinazione per utilizzare il nuovo archivio di attendibilità.
Riepilogo dei metodi per aggiornare un certificato scaduto
Il metodo che utilizzi per specificare il nome dell'archivio chiavi e dell'archivio di attendibilità nell'endpoint/server di destinazione determina il modo in cui esegui l'aggiornamento dei certificati. 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 dell'alias precedente.
Per un archivio attendibilità, crea un archivio attendibilità con un nuovo nome. |
Aggiorna il riferimento all'archivio chiavi o all'archivio chiavi.
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, alias o archivio attendibilità.
Non è necessario contattare l'assistenza Apigee. |
Diretta | Creare un nuovo archivio chiavi, alias e archivio attendibilità. | Esegui di nuovo il deployment del proxy. |
Diretta | Elimina l'archivio chiavi o l'archivio attendibili e ricrealo con lo stesso nome. |
Le richieste API non riusciranno finché non vengono impostati il nuovo archivio chiavi e il nuovo 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. |
Diretta | Solo per l'archivio attendibilità, carica un nuovo certificato nell'archivio attendibili. | Contatta l'assistenza clienti Google Cloud per riavviare i processori di messaggi. |