Utilizzo di SNI con Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

SNI (Server Name Indication) consente di gestire più destinazioni HTTPS sullo stesso indirizzo IP e sulla stessa porta, senza che queste destinazioni utilizzino lo stesso certificato TLS. Quando SNI è abilitato su un client, quest'ultimo passa il nome host dell'endpoint di destinazione come parte dell'handshake TLS iniziale. Ciò consente al server TLS di determinare quale certificato TLS deve essere utilizzato per convalidare la richiesta.

Ad esempio, se la destinazione della richiesta è https://example.com/request/path, il client TLS aggiunge l'estensione server_name alla richiesta di handshake TLS, come mostrato di seguito:

Edge supporta SNI per:

  • Richieste da un'app client a un proxy API. In questo scenario, Edge agisce come server TLS
  • Richieste da Edge al backend. In questo scenario, Edge agisce come client TLS.

Per ulteriori informazioni su SNI, consulta:

Supporto di SNI per una richiesta a proxy API su Edge

Il supporto SNI per le richieste ai proxy API è controllato dagli alias host e dagli host virtuali.

Informazioni su host virtuali e alias host

Con Edge, un host virtuale definisce l'indirizzo IP e la porta, o il nome e la porta DNS, su cui è esposto un proxy API e, per estensione, l'URL che le app utilizzano per accedere a un proxy API. L'indirizzo IP/nome DNS corrisponde a un router Edge e il numero di porta è una porta aperta sul router.

Quando crei l'host virtuale, specifichi anche l'alias host dell'host virtuale. In genere si tratta del nome DNS dell'host virtuale. Nell'ambito della determinazione del proxy API che gestisce la richiesta, il router confronta l'intestazione Host della richiesta in entrata con l'elenco degli alias host disponibili definiti da tutti gli host virtuali.

La combinazione di alias host e numero di porta per l'host virtuale deve essere univoca per tutti gli host virtuali nell'installazione Edge. Ciò significa che più host virtuali possono utilizzare lo stesso numero di porta se hanno alias host diversi.

Un host virtuale definisce inoltre se l'accesso al proxy API è tramite il protocollo HTTP oppure il protocollo HTTPS criptato tramite TLS. Quando configuri un host virtuale per l'utilizzo di HTTPS, associa l'host virtuale a un archivio chiavi contenente il certificato e la chiave privata utilizzati dall'host virtuale durante l'handshake TLS.

Per ulteriori informazioni sugli host virtuali, vedi:

Come funziona SNI con gli alias host

SNI consente di avere più host virtuali definiti sulla stessa porta, ciascuno con certificati e chiavi TLS diversi. Edge determina quindi l'host virtuale e la coppia di certificato/chiave utilizzata da TLS, in base all'estensione server_name nella richiesta di handshake TLS.

Il router perimetrale legge l'estensione server_name nella richiesta di handshake TLS, quindi la utilizza per cercare negli alias host di tutti gli host virtuali. Se rileva una corrispondenza con un alias host, il router utilizza il certificato e la chiave TLS dell'host virtuale associato all'alias host. Se non viene trovata alcuna corrispondenza, l'handshake TLS non va a buon fine.

Anziché causare l'esito negativo dell'handshake TLS, puoi definire una coppia certificato/chiave predefinita, come descritto nelle sezioni successive.

Definizione di una coppia certificato/chiave predefinita in Edge per il cloud

Apigee fornisce un certificato TLS e una chiave privata per supportare HTTPS. Sebbene molti clienti preferiscano utilizzare il proprio certificato e la propria chiave privata al momento del deployment, puoi eseguire il deployment delle tue API utilizzando il certificato e la chiave Apigee.

In Edge per il cloud, se il router non può associare l'intestazione SNI a un alias host o se il client non supporta SNI, il router utilizza il certificato predefinito fornito da Apigee, ovvero *.apigee.net.

Definizione di una coppia certificato/chiave predefinita in Edge per il cloud privato

In Edge per il cloud privato, se non viene trovata alcuna corrispondenza tra l'estensione server_name e gli alias host di tutti gli host virtuali o se il client richiedente non supporta SNI, puoi configurare il router in modo che utilizzi il certificato o la chiave di un host virtuale predefinito sulla porta. L'host virtuale predefinito è definito da una combinazione di nome dell'organizzazione, nome dell'ambiente e nome dell'host virtuale nel formato:

orgName_envName_vhName

Il router utilizza il certificato/chiave della combinazione di orgName_envName_vhName, che è la prima in ordine alfabetico. Ad esempio, la richiesta arriva sulla porta 443 e sono stati definiti due host virtuali per l'organizzazione example nell'ambiente prod:

  • nome host virtuale = default
  • nome host virtuale = test

In questo esempio, il router utilizza il certificato/la chiave dell'host virtuale denominato default perché example_prod_default precede in ordine alfabetico example_prod_test.

Per abilitare l'host virtuale predefinito:

  1. Sul primo nodo del router, modifica /opt/apigee/customer/application/router.properties. Se il file non esiste, crealo.
  2. Aggiungi la seguente proprietà al file per poter definire un host virtuale predefinito: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Riavvia il router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Ripeti questi passaggi su tutti i router rimanenti.

Anziché utilizzare il certificato o la chiave dell'host virtuale predefinito, puoi definire esplicitamente il certificato o la chiave predefiniti sul router. Utilizza la seguente procedura per definire una coppia certificato/chiave predefinita esplicita:

  1. Sul primo nodo router, copia il certificato e la chiave privata in una posizione sul nodo router accessibile all'utente Apigee. Ad esempio, /opt/apigee/customer/application.
  2. Cambia la proprietà dei file all'utente "apigee. ": 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Modifica /opt/apigee/customer/application/router.properties. Se il file non esiste, crealo.
  4. Aggiungi le seguenti proprietà al file per poter specificare il certificato o la chiave predefiniti:
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. Imposta le seguenti proprietà in router.properties per specificare la località del certificato e della chiave: 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. Riavvia il router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Ripeti questi passaggi su tutti i router rimanenti.

Supporto di SNI per le richieste da Edge al backend

Edge supporta l'utilizzo di SNI dai processori di messaggi per scegliere come target gli endpoint in Apigee Edge per Cloud e per i deployment Private Cloud. Per impostazione predefinita, SNI è abilitato sui processori di messaggi Edge per il cloud e disabilitato nel cloud privato.

Utilizzo di SNI nel backend in Edge per il cloud privato

Affinché Edge per il cloud privato sia compatibile con le versioni precedenti dei backend di destinazione, Apigee ha disabilitato SNI per impostazione predefinita. Se il backend di destinazione è configurato per supportare SNI, puoi abilitare questa funzionalità come descritto di seguito per la tua versione di Edge.

Non sono necessarie altre configurazioni specifiche per Edge. Se il tuo ambiente di destinazione è configurato per SNI, Edge lo supporta. Edge estrae automaticamente il nome host dall'URL della richiesta e lo aggiunge alla richiesta di handshake TLS.

Abilita SNI tra Edge e il backend per Edge versione 4.15.07.0x

Per abilitare la funzione SNI, utilizza la seguente procedura:

  1. Sul primo nodo del processore di messaggi, apri il file /opt/apigee4/conf/apigee/message-processor/system.properties in un editor.
  2. Imposta la seguente proprietà su true in system.properties: 
    jsse.enableSNIExtension=true
  3. Riavvia i processori di messaggi: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Ripeti questi passaggi su tutti gli altri processori di messaggi.

Abilita SNI tra Edge e il backend per Edge 4.16.01 e versioni successive

Per abilitare la funzione SNI, utilizza la seguente procedura:

  1. Sul primo nodo del processore di messaggi, modifica /opt/apigee/customer/application/message-processor.properties. Se il file non esiste, crealo.
  2. Aggiungi la seguente proprietà al file: 
    conf_system_jsse.enableSNIExtension=true
  3. Riavvia il processore di messaggi: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Ripeti questi passaggi su tutti gli altri processori di messaggi.