Questa pagina è stata tradotta dall'API Cloud Translation.

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 sull'impostazione delle 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>
    </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 pagina relativa alla configurazione degli endpoint di destinazione TLS/SSL.

Nella tabella seguente vengono descritti gli elementi di configurazione TLS utilizzati dal tag <SSLInfo>:

Elemento	Description
`<Enabled>`	Abilita TLS unidirezionale tra Apigee e il client API o tra Apigee e il backend di destinazione.
`<Enforce>`	Applica il livello di conformità SSL tra Apigee e il backend di destinazione. Se il criterio viene impostato su `true`, le connessioni non andranno a buon fine per le destinazioni con certificati non validi, scaduti o autofirmati, certificati con una mancata corrispondenza del nome host e certificati con una radice non attendibile. Viene restituito un codice di errore `4xx` o `5xx`. Se il criterio non viene configurato o se viene impostato su `false`, il risultato delle connessioni ai backend di destinazione con certificati problematici dipende dall'impostazione di `<IgnoreValidationErrors>` (vedi di seguito). Una risposta positiva (`2xx`) può verificarsi in determinate condizioni, se `<IgnoreValidationErrors>` è impostato su `true`.
`<ClientAuthEnabled>`	Abilita il protocollo TLS a due vie (noto anche come TLS reciproco o mTLS) tra Apigee e il client API o tra Apigee e il backend di destinazione. L'abilitazione del TLS bidirezionale richiede in genere la configurazione di un archivio attendibilità su Apigee e un archivio attendibilità.
`<KeyStore>`	L'archivio chiavi.
`<KeyAlias>`	L'alias specificato quando hai caricato un certificato e una chiave privata nell'archivio chiavi.
`<TrustStore>`	L'archivio attendibilità.
`<IgnoreValidationErrors>`	Se il valore è true, Apigee ignora gli errori dei certificati TLS. Il valore predefinito è false. 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 `<Enforce>` è impostato su `true`, il valore di `<IgnoreValidationErrors>` viene ignorato.

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

Nell'esempio precedente, l'archivio chiavi e l'archivio attendibilità sono specificati utilizzando 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 attendibilità. Un riferimento è una variabile che contiene il nome dell'archivio chiavi o dell'archivio di attendibilità, 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 dell'archivio attendibilità è myTruststore.

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

Modificare il valore del riferimento non richiede di contattare l'assistenza Apigee.

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

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

Se specifichi direttamente il nome dell'archivio chiavi o dell'archivio attendibilità, devi contattare l'assistenza Apigee.

Una terza opzione consiste nell'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 di attendibilità come i riferimenti. Per maggiori informazioni, consulta Utilizzo delle variabili di flusso per impostare valori TLS/SSL in modo dinamico.

Informazioni sulla configurazione di TLS

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

Gestione dei certificati scaduti

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

Quando scade un certificato

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

Archivio chiavi: contiene il certificato TLS e la chiave privata utilizzati per identificare l'entità durante l'handshake TLS.
Archivio attendibilità: contiene certificati attendibili su un client TLS utilizzato per convalidare il certificato di un server TLS presentato al client. Questi 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 archivio chiavi scade e utilizzi un riferimento all'archivio chiavi, non puoi caricare un nuovo certificato nell'archivio chiavi. ma:

Crea un nuovo archivio chiavi.
Carica il nuovo certificato nel nuovo archivio chiavi utilizzando lo stesso nome alias dell'archivio chiavi precedente.
Aggiorna il riferimento nell'endpoint server/target di destinazione per utilizzare il nuovo archivio chiavi.

Quando un certificato in un archivio attendibilità scade e utilizzi un riferimento all'archivio attendibilità, esegui queste operazioni:

Creare un nuovo archivio attendibilità.
Carica il nuovo certificato nel nuovo archivio attendibilità. Il nome alias non è importante per gli archivi di attendibilità. Nota: se un certificato fa parte di una catena, devi creare un singolo file contenente tutti i certificati e caricare il file su un singolo alias oppure caricare tutti i certificati nella catena separatamente nell'archivio di attendibilità utilizzando un alias diverso per ciascun certificato.
Aggiorna il riferimento nell'endpoint del server/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 seguente tabella:

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 attendibilità. 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 su ogni richiesta con il nome del nuovo archivio chiavi, dell'alias o dell'archivio attendibilità. Non è necessario contattare l'assistenza Apigee.
Diretta	Crea un nuovo archivio chiavi, un nuovo alias e un nuovo archivio attendibilità.	Esegui di nuovo il deployment del proxy.
Diretta	Elimina l'archivio chiavi o l'archivio di attendibilità e ricrealo con lo stesso nome.	Le richieste API non andranno a buon fine finché non verranno impostati il nuovo archivio chiavi e l'alias. Se l'archivio chiavi viene utilizzato per TLS a due vie (noto anche come TLS reciproco o mTLS) tra Apigee e il servizio di backend, contatta l'assistenza Apigee per riavviare i processori di messaggi.
Diretta	Solo per l'archivio attendibilità, carica un nuovo certificato nell'archivio attendibilità.	Contatta l'assistenza Apigee per riavviare i processori di messaggi.