Utilizzo di SNI con Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

La funzione Server Name Indication (SNI) consente di gestire più destinazioni HTTPS dallo stesso IP indirizzo e porta senza richiedere che queste destinazioni usino lo stesso certificato TLS. Quando SNI è impostato su abilitato su un client, il client trasmette il nome host dell'endpoint di destinazione come parte della TLS handshake. Ciò consente al server TLS di determinare quale certificato TLS utilizzare per la convalida la richiesta.

Ad esempio, se il target della richiesta è https://example.com/request/path, il client TLS aggiunge l'estensione server_name all'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 TLS server
  • Richieste da Edge al backend. In questo scenario, Edge agisce come client TLS.

Per ulteriori informazioni su SNI, vedi:

Supporto SNI per una richiesta al proxy API su Dispositivi periferici

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

Informazioni sugli annunci virtuali host e alias host

Con Edge, un host virtuale definisce l'indirizzo IP e la porta (o nome e porta DNS) in cui viene esposto un proxy API e, per estensione, l'URL utilizzato dalle app per accedere a un proxy API. L'indirizzo IP/nome DNS corrisponde a un router perimetrale e il numero di porta è una porta aperta il 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 elenco di 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 tutte di host virtuali nell'installazione Edge. Ciò significa che più host virtuali possono utilizzare stesso numero di porta se hanno alias host diversi.

Un host virtuale definisce inoltre se si accede al proxy API utilizzando il protocollo HTTP, oppure dal protocollo HTTPS criptato tramite TLS. Quando configuri un host virtuale per l'utilizzo di HTTPS, associare l'host virtuale a un archivio chiavi che contiene il certificato e la chiave privata utilizzati durante l'handshake TLS.

Per ulteriori informazioni sugli host virtuali, consulta:

Come funziona SNI con alias host

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

Il router perimetrale legge l'estensione server_name nell'handshake TLS richiesta, e la utilizza per cercare gli alias host da tutte le istanze . Se il router rileva una corrispondenza con un alias host, utilizza il certificato e la chiave TLS all'host virtuale associato all'alias host. Se non viene trovata alcuna corrispondenza, l'handshake TLS non va a buon fine.

Anziché avere esito negativo per l'handshake TLS, puoi definire una coppia certificato/chiave predefinita, come descritti 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. Anche se molti clienti se preferiscono usare il proprio certificato e la propria chiave privata al momento del deployment, puoi eseguire il deployment utilizzando il certificato e la chiave Apigee.

In Edge per il cloud, se il router non riesce a far corrispondere l'intestazione SNI a un alias host o se non supporta SNI, il router utilizza il certificato predefinito fornito da Apigee, che è *.apigee.net.

Definizione di una coppia di certificati/chiavi 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 da tutti gli host virtuali o se il client che ha inviato la richiesta non supporta SNI, puoi configurare Router per utilizzare il certificato/la chiave di un host virtuale predefinito sulla porta. L'host virtuale predefinito è definiti da una combinazione di nome organizzazione, nome ambiente e nome host virtuale, modulo:

orgName_envName_vhName

Il router utilizza il certificato/la chiave della combinazione di orgName_envName_vhName che compare per prima in ordine alfabetico. Ad esempio, se la richiesta arriva sulla porta 443, due host virtuali definiti 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 example_prod_test in ordine alfabetico.

Per attivare 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 consentirti di 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/la chiave dell'host virtuale predefinito, puoi definire esplicitamente la certificato o chiave predefinito sul router. Utilizza la seguente procedura per definire un valore predefinito esplicito coppia certificato/chiave:

  1. Sul primo nodo router, copia il certificato e la chiave privata in una posizione sul nodo router accessibile dall'utente apigee. Ad esempio, /opt/apigee/customer/application.
  2. Cambia la proprietà dei file in 'apigee. utente: 
    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 consentirti di specificare il certificato/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 posizione 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 SNI per le richieste da Edge a il backend

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

Utilizzo SNI al backend in Edge per il cloud privato

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

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

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

Utilizza la seguente procedura per abilitare SNI:

  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 versione 4.16.01 e successive

Utilizza la seguente procedura per abilitare SNI:

  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.