Utilizzo di SNI con Edge

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

L'indicazione del nome del server (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 è abilitato su un client, il client passa il nome host dell'endpoint di destinazione come parte dell'handshake TLS iniziale. In questo modo, il server TLS può 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 all'handshake TLS richiesta, come mostrato di seguito:

Edge supporta SNI per:

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

Per ulteriori informazioni su SNI, vedi:

Supporto di SNI per una richiesta al proxy API su Edge

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

Informazioni sugli host virtuali e sugli alias host

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

Quando crei l'host virtuale, devi specificare anche l'alias host dell'host virtuale. In genere si tratta del nome DNS dell'host virtuale. Per determinare il 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 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 tramite il protocollo HTTPS criptato tramite TLS. Quando configuri un host virtuale per l'utilizzo di HTTPS, associa l'host virtuale a un keystore 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 definire più host virtuali sulla stessa porta, ognuno con certificati e chiavi TLS diversi. Edge determina quindi l'host virtuale e la coppia 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 cercare gli alias host di tutti gli host virtuali. Se il router rileva una corrispondenza con un alias host, utilizza il certificato e la chiave TLS da l'host virtuale associato all'alias host. Se non viene trovata alcuna corrispondenza, l'handshake TLS non riesce.

Anziché far fallire l'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 API utilizzando il certificato e la chiave Apigee.

In Edge per il cloud, se il router non riesce a trovare una corrispondenza tra l'intestazione SNI e 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/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/la chiave della combinazione orgName_envName_vhName che viene visualizzata per 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 viene prima di example_prod_test in ordine alfabetico.

Per abilitare l'host virtuale predefinito:

  1. Nel 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/la chiave dell'host virtuale predefinito, puoi definire in modo esplicito il certificato/la chiave predefinita sul router. Utilizza la seguente procedura per definire una coppia certificato/chiave predefinita esplicita:

  1. Nel primo nodo del router, copia il certificato e la chiave privata in una posizione sul nodo del router accessibile all'utente apigee. Ad esempio, /opt/apigee/customer/application.
  2. Modifica la proprietà dei file in modo che appartengano 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/la chiave predefinita:
    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 a il backend

Edge supporta l'utilizzo di SNI dai Message Processor per i target endpoint nei deployment di Apigee Edge per il cloud e per il cloud privato. Per impostazione predefinita, SNI è abilitato sui Message Processor Edge per il cloud e disabilitato nel cloud privato.

Utilizzo di SNI sul backend in Edge per il cloud privato

Per Edge per il cloud privato, per garantire la compatibilità con i backend di destinazione esistenti, 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 è richiesta alcuna altra configurazione specifica di 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.

Abilitazione di SNI tra Edge e il backend per Edge versione 4.15.07.0x

Utilizza la seguente procedura per abilitare SNI:

  1. Nel 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 Message Processor: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Ripeti questi passaggi su tutti i Message Processor rimanenti.

Abilitazione di SNI tra Edge e il backend per Edge versione 4.16.01 e successive

Utilizza la seguente procedura per abilitare SNI:

  1. Nel 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 i Message Processor rimanenti.