Korzystanie z rozszerzenia SNI w przeglądarce Edge

Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.

Wskazanie nazwy serwera (SNI) umożliwia udostępnianie wielu celów HTTPS z tego samego adresu IP i portu bez konieczności używania tego samego certyfikatu TLS. Gdy klient SNI jest włączony, klient przekazuje nazwę hosta docelowego punktu końcowego w ramach początkowego uzgadniania połączenia TLS. Dzięki temu serwer TLS może określić, który certyfikat TLS ma być używany do weryfikowania żądania.

Jeśli na przykład celem żądania jest https://example.com/request/path, klient TLS dodaje rozszerzenie server_name do żądania uzgadniania połączenia TLS, jak pokazano poniżej:

Edge obsługuje SNI w przypadku:

  • Żądania z aplikacji klienckiej do serwera proxy interfejsu API. W tym scenariuszu Edge działa jako serwer TLS
  • Żądania z Edge do backendu. W tym scenariuszu Edge działa jako klient TLS.

Więcej informacji o SNI:

Obsługa SNI w przypadku żądania do serwera proxy interfejsu API na brzegu sieci

Obsługa żądań SNI do żądań serwerów proxy interfejsu API jest kontrolowana przez aliasy hostów i hosty wirtualne.

Informacje o hostach wirtualnych i aliasach hosta

W przypadku Edge host wirtualny określa adres IP i port (lub nazwę i port DNS) dla serwera proxy interfejsu API, a przez to także adres URL używany przez aplikacje do uzyskiwania dostępu do serwera proxy interfejsu API. Adres IP/nazwa DNS odpowiada routerowi brzegowemu, a numer portu to otwarty port routera.

Podczas tworzenia hosta wirtualnego musisz określić też jego hosta. Zwykle jest to nazwa DNS hosta wirtualnego. Podczas określania serwera proxy interfejsu API obsługującego żądanie router porównuje nagłówek Host żądania przychodzącego z listą dostępnych aliasów hostów zdefiniowanych przez wszystkie hosty wirtualne.

Kombinacja aliasu hosta i numeru portu hosta wirtualnego musi być unikalna dla wszystkich hostów wirtualnych podczas instalacji Edge. Oznacza to, że wielu hostów wirtualnych może używać tego samego numeru portu, jeśli mają różne aliasy hosta.

Host wirtualny określa też, czy dostęp do serwera proxy interfejsu API odbywa się przy użyciu protokołu HTTP, czy za pomocą zaszyfrowanego protokołu HTTPS z TLS. Podczas konfigurowania hosta wirtualnego na potrzeby protokołu HTTPS powiąż go z magazynem kluczy zawierającym certyfikat i klucz prywatny, których host wirtualny używa podczas uzgadniania połączenia TLS.

Więcej informacji o hostach wirtualnych znajdziesz w tych artykułach:

Jak SNI działa z aliasami hosta

SNI pozwala zdefiniować wiele hostów wirtualnych na tym samym porcie. Każdy z nich ma inny certyfikat i klucz TLS. Następnie Edge określa hosta wirtualnego i parę certyfikatów/klucza używaną przez TLS na podstawie rozszerzenia server_name w żądaniu uzgadniania połączenia TLS.

Router brzegowy odczytuje rozszerzenie server_name z żądania uzgadniania połączenia TLS, a następnie używa go do wyszukiwania aliasów hosta ze wszystkich hostów wirtualnych. Jeśli router wykryje zgodność z aliasem hosta, będzie używać certyfikatu TLS i klucza z hosta wirtualnego powiązanego z aliasem hosta. Jeśli nie uda się znaleźć dopasowania, połączenie TLS nie uda się połączyć.

Aby uniknąć nieudanego uzgadniania połączenia TLS, możesz zdefiniować domyślną parę certyfikatu/klucza, jak opisano w kolejnych sekcjach.

Definiowanie domyślnej pary certyfikatu/klucza w Edge dla chmury

Apigee udostępnia certyfikat TLS i klucz prywatny do obsługi HTTPS. Wielu klientów woli korzystać z własnych certyfikatów i kluczy prywatnych podczas wdrażania, ale możesz wdrożyć interfejsy API za pomocą certyfikatu i klucza Apigee.

W przypadku Edge w Cloud, jeśli router nie może dopasować nagłówka SNI do aliasu hosta lub jeśli klient nie obsługuje SNI, router używa domyślnego certyfikatu udostępnionego przez Apigee, który jest *.apigee.net.

Definiowanie domyślnej pary certyfikatu/klucza w Edge dla chmury prywatnej

Jeśli w Edge dla chmury prywatnej nie znaleziono dopasowania między rozszerzeniem server_name a aliasami hosta ze wszystkich hostów wirtualnych lub jeśli klient wysyłający żądanie nie obsługuje SNI, możesz skonfigurować router na potrzeby używania certyfikatu/klucza z domyślnego hosta wirtualnego na porcie. Domyślny host wirtualny jest zdefiniowany przez połączenie nazwy organizacji, nazwy środowiska i nazwy hosta wirtualnego w formacie:

orgName_envName_vhName

Router używa certyfikatu/klucza z kombinacji orgName_envName_vhName, który występuje w kolejności alfabetycznej. Na przykład żądanie jest wysyłane przez port 443 i w środowisku example są zdefiniowane 2 hosty wirtualne: prod:

  • nazwa hosta wirtualnego = default
  • nazwa hosta wirtualnego = test

W tym przykładzie router używa certyfikatu/klucza z hosta wirtualnego o nazwie default, ponieważ example_prod_default znajduje się alfabetycznie przed elementem example_prod_test.

Aby włączyć domyślnego hosta wirtualnego:

  1. W pierwszym węźle routera edytuj /opt/apigee/customer/application/router.properties. Jeśli taki plik nie istnieje, utwórz go.
  2. Dodaj do pliku tę właściwość, aby umożliwić zdefiniowanie domyślnego hosta wirtualnego: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Uruchom ponownie router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Powtórz te czynności na wszystkich routerach.

Zamiast używać certyfikatu/klucza z domyślnego hosta wirtualnego, możesz wyraźnie określić domyślny certyfikat/klucz na routerze. Aby zdefiniować domyślną parę kluczy i certyfikatów, wykonaj te czynności:

  1. W pierwszym węźle routera skopiuj certyfikat i klucz prywatny do lokalizacji w węźle routera, z którego może korzystać użytkownik Apigee. Na przykład: /opt/apigee/customer/application.
  2. Zmień własność plików na „apigee. user: 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
    ”
  3. Edytuj stronę /opt/apigee/customer/application/router.properties Jeśli taki plik nie istnieje, utwórz go.
  4. Dodaj do pliku te właściwości, aby móc określić domyślny certyfikat/klucz:
    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. Ustaw następujące właściwości w polu router.properties, aby określić lokalizację certyfikatu i klucza:
    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. Uruchom ponownie router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Powtórz te czynności na wszystkich routerach.

Obsługa SNI w przypadku żądań z Edge do backendu

Edge obsługuje używanie rozszerzenia SNI z komunikatorów Compute Engine do kierowania punktów końcowych w Apigee Edge w przypadku Cloud oraz wdrożeń w chmurze prywatnej. Domyślnie SNI jest włączony w procesorach Edge Edge dla chmury i wyłączony w chmurze prywatnej.

Korzystanie z SNI do backendu w chmurze prywatnej

Aby zachować zgodność wsteczną z istniejącymi docelowymi backendami, Apigee domyślnie wyłączył SNI. Jeśli docelowy backend jest skonfigurowany do obsługi SNI, możesz włączyć tę funkcję w sposób opisany poniżej dla swojej wersji Edge.

Inne konfiguracje specyficzne dla Edge nie są wymagane. Jeśli środowisko docelowe jest skonfigurowane pod kątem SNI, Edge je obsługuje. Edge automatycznie wyodrębnia nazwę hosta z adresu URL żądania i dodaje ją do żądania uzgadniania połączenia TLS.

Włącz SNI między Edge a backend w Edge 4.15.07.0x

Aby włączyć SNI, wykonaj następujące czynności:

  1. W pierwszym węźle procesora wiadomości otwórz plik /opt/apigee4/conf/apigee/message-processor/system.properties w edytorze.
  2. W polu system.properties ustaw tę właściwość na: 
    jsse.enableSNIExtension=true
  3. Uruchom ponownie firmy obsługujące wiadomości:
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Powtórz te czynności na wszystkich pozostałych procesorach wiadomości.

Włącz SNI między Edge a backend w Edge w wersji 4.16.01 i nowszych

Aby włączyć SNI, wykonaj następujące czynności:

  1. W pierwszym węźle procesora wiadomości edytuj /opt/apigee/customer/application/message-processor.properties. Jeśli taki plik nie istnieje, utwórz go.
  2. Dodaj do pliku tę właściwość: 
    conf_system_jsse.enableSNIExtension=true
  3. Uruchom ponownie procesor wiadomości: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Powtórz te czynności na wszystkich pozostałych procesorach wiadomości.