Utilizzo di SNI con Edge

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

La funzionalità Server Name Indication (SNI) consente di pubblicare più target HTTPS dallo stesso indirizzo IP e dalla stessa porta senza richiedere che questi target utilizzino lo stesso certificato TLS. Quando SNI è attivo su un client, il client passa il nome host dell'endpoint di destinazione nell'ambito dell'handshake TLS iniziale. Ciò consente al server TLS di determinare quale certificato TLS deve essere utilizzato per convalidare la richiesta.

Ad esempio, se il target 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, vedi:

Supporto di SNI per una richiesta al 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 utilizzato dalle app 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 arrivo 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 di Edge. Ciò significa che più host virtuali possono utilizzare lo stesso numero di porta se hanno alias host diversi.

Un host virtuale definisce anche se si accede al proxy API utilizzando il protocollo HTTP o il protocollo HTTPS criptato tramite TLS. Quando configuri un host virtuale per l'utilizzo di HTTPS, associato 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, consulta:

Come funziona SNI con gli alias host

SNI ti consente di avere più host virtuali definiti sulla stessa porta, ciascuno con chiavi e certificati 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 Edge legge l'estensione server_name nella richiesta di handshake TLS e la utilizza per eseguire ricerche negli alias host di tutti gli host virtuali. Se il router rileva una corrispondenza con un alias host, 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é far fallire l'handshake TLS, puoi definire una coppia di certificati/chiavi predefinita, come descritto nelle sezioni successive.

Definire una coppia di chiavi/certificati predefinita in Edge per il cloud

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

In Edge for the Cloud, se il router non riesce ad 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.

Definire una coppia di chiavi/certificati predefinita in Edge per il cloud privato

In Edge per il Private Cloud, 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 da utilizzare il certificato/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 seguente formato:

orgName_envName_vhName

Il router utilizza il certificato/la chiave della combinazione di orgName_envName_vhName che viene prima in ordine alfabetico. Ad esempio, la richiesta arriva sulla porta 443 e sono 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 example_prod_test in ordine alfabetico.

Per attivare l'host virtuale predefinito:

  1. Sul primo nodo Router, modifica /opt/apigee/customer/application/router.properties. Se il file non esiste, creane uno.
  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/la chiave dell'host virtuale predefinito, puoi definire esplicitamente il certificato/la chiave predefiniti sul router. Per definire una coppia di chiave/certificato 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. Modifica la proprietà dei file in "apigee. user: 
    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, creane uno.
  4. Aggiungi le seguenti proprietà al file per poter 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 di SNI per le richieste da Edge al backend

Edge supporta l'utilizzo di SNI dai processori di messaggi agli endpoint di destinazione in Apigee Edge per i deployment su cloud e su private cloud. Per impostazione predefinita, SNI è abilitato negli Edge Message Processors per il cloud e disabilitato nel Private Cloud.

Utilizzo di SNI per il backend in Edge per il private cloud

Per Edge per il cloud privato, per garantire la compatibilità con le versioni precedenti con i backend di destinazione esistenti, Apigee ha disattivato SNI per impostazione predefinita. Se il backend di destinazione è configurato per supportare SNI, puoi attivare questa funzionalità come descritto di seguito per la tua versione di Edge.

Non è richiesta alcuna altra configurazione specifica per Edge. Se l'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.

Attivare SNI tra Edge e il backend per la versione 4.15.07.0x di Edge

Per attivare SNI:

  1. Sul primo nodo di elaborazione dei 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 elaboratori di messaggi.

Attivare SNI tra Edge e il backend per Edge versione 4.16.01 e successive

Per attivare SNI:

  1. Nel primo nodo di elaborazione dei messaggi, modifica /opt/apigee/customer/application/message-processor.properties. Se il file non esiste, creane uno.
  2. Aggiungi la proprietà seguente 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 elaboratori di messaggi.