Korzystanie z rozszerzenia SNI w przeglądarce Edge

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Wskazanie nazwy serwera (SNI) umożliwia obsługę wielu celów HTTPS przy użyciu tego samego adresu IP i portu bez konieczności używania przez te cele tego samego certyfikatu TLS. Gdy SNI jest włączone na kliencie, klient przekazuje nazwę hosta docelowego punktu końcowego w ramach początkowego uzgadniania połączenia TLS. Pozwala to serwerowi TLS określić, który certyfikat TLS należy użyć do sprawdzenia żądania.

Jeśli na przykład docel żądania to 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 klienta do serwera proxy 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 API w przeglądarce Edge

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

Informacje o hostach wirtualnych i aliasach hostów

W Edge host wirtualny definiuje adres IP i port lub nazwę i port DNS, na których udostępniany jest serwer proxy API, a w rozszerzeniu adres URL, którego aplikacje używają do uzyskiwania dostępu do serwera proxy API. Adres IP lub nazwa DNS odpowiadają routerowi brzegowemu, a numer portu to otwarty port na routerze.

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

Kombinacja aliasu hosta i numeru portu dla hosta wirtualnego musi być niepowtarzalna dla wszystkich hostów wirtualnych w instalacji Edge. Oznacza to, że kilka 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 jest uzyskiwany za pomocą protokołu HTTP, czy szyfrowanego protokołu HTTPS z użyciem TLS. Podczas konfigurowania hosta wirtualnego do korzystania z protokołu HTTPS powiązać go z magazynem kluczy zawierającym certyfikat i klucz prywatny używane przez hosta wirtualnego podczas uzgadniania połączenia TLS.

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

Jak działa SNI z aliasami hosta

SNI umożliwia zdefiniowanie wielu hostów wirtualnych na tym samym porcie, z których każdy ma inne klucze i certyfikaty TLS. Następnie urządzenie Edge określa hosta wirtualnego i parę certyfikat/klucz używaną przez TLS na podstawie rozszerzenia server_namew żądaniu uścisku dłoni TLS.

Edge Router odczytuje rozszerzenie server_name w żądaniu TLS handshake, a następnie użyje go do wyszukania aliasów hostów ze wszystkich hostów wirtualnych. Jeśli router wykryje dopasowanie do aliasu hosta, użyje certyfikatu i klucza TLS z hosta wirtualnego powiązanego z aliasem hosta. Jeśli nie zostanie znalezione dopasowanie, proces TLS handshake się nie powiedzie.

Zamiast dopuścić do niepowodzenia uzgadniania połączenia TLS, możesz zdefiniować domyślną parę certyfikat/klucz, jak opisano w kolejnych sekcjach.

Definiowanie domyślnego certyfikatu i klucza w Edge for the Cloud

Apigee udostępnia certyfikat TLS i klucz prywatny, aby obsługiwać HTTPS. Wielu klientów woli używać własnego certyfikatu i klucza prywatnego w momencie wdrażania, ale interfejsy API można wdrażać, używając certyfikatu i klucza Apigee.

W przypadku Edge for the 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 dostarczonego przez Apigee, czyli *.apigee.net.

Definiowanie domyślnej pary certyfikat/klucz w Edge w Private Cloud

Jeśli w Edge for Private Cloud nie zostanie znalezione dopasowanie 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 tak, aby używał certyfikatu/klucza z domyślnego hosta wirtualnego na porcie. Domyślny host wirtualny jest zdefiniowany przez kombinację nazwy organizacji, nazwy środowiska i nazwy hosta wirtualnego w tej postaci:

orgName_envName_vhName

Router używa certyfikatu/klucza z kombinacji orgName_envName_vhName, która jest pierwsza w kolejności alfabetycznej. Na przykład żądanie przychodzi przez port 443, a w środowisku prod dla organizacji example zdefiniowane są 2 hosty wirtualne:

  • 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 występuje w kolejności alfabetycznej przed example_prod_test.

Aby włączyć domyślny host wirtualny:

  1. W pierwszym węźle Router zmień wartość /opt/apigee/customer/application/router.properties. Jeśli plik nie istnieje, utwórz go.
  2. Aby zdefiniować domyślny host wirtualny, dodaj do pliku tę właściwość: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Ponownie uruchom router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Powtórz te czynności w przypadku wszystkich pozostałych routerów.

Zamiast używać certyfikatu lub klucza domyślnego hosta wirtualnego możesz jawnie zdefiniować certyfikat lub klucz domyślny na routerze. Aby zdefiniować jawny domyślny klucz i certyfikat:

  1. Na pierwszym węźle Router skopiuj certyfikat i klucz prywatny do lokalizacji na węźle Router, do której ma dostęp użytkownik apigee. Na przykład: /opt/apigee/customer/application.
  2. Zmień własność plików na użytkownika „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 plik nie istnieje, utwórz go.
  4. Aby określić domyślny certyfikat lub klucz, dodaj do pliku te właściwości:
    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. Aby określić lokalizację certyfikatu i klucza, ustaw w router.properties te właściwości: 
    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. Ponownie uruchom router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Powtórz te czynności w przypadku wszystkich pozostałych routerów.

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

Edge obsługuje użycie SNI z procesorów wiadomości do kierowania na punkty końcowe w Apigee Edge w chmurze i w przypadku wdrożeń w chmurze prywatnej. Domyślnie SNI jest włączone w procesorach wiadomości krawędziowych w chmurze i wyłączone w chmurze prywatnej.

Przekazywanie SNI do zaplecza w Edge w chmurze prywatnej

Aby zapewnić zgodność wsteczną z istniejącymi backendami docelowymi, w przypadku usługi Edge for Private Cloud usługa Apigee domyślnie wyłączyła SNI. Jeśli docelowy backend jest skonfigurowany pod kątem obsługi SNI, możesz włączyć tę funkcję w swojej wersji Edge w sposób opisany poniżej.

Nie musisz konfigurować innych ustawień Edge. Jeśli środowisko docelowe jest skonfigurowane pod kątem SNI, przeglądarka Edge je obsługuje. Edge automatycznie wyodrębnia nazwę hosta z adresu URL żądania i dodaje ją do żądania uzgadniania połączenia TLS.

Włączanie SNI między Edge a backendem w przypadku Edge w wersji 4.15.07.0x

Aby włączyć SNI:

  1. W przypadku pierwszego węzła Message Processor otwórz plik /opt/apigee4/conf/apigee/message-processor/system.properties w edytorze.
  2. Ustaw w sekcji system.properties tę właściwość na wartość „true”: 
    jsse.enableSNIExtension=true
  3. Ponownie uruchom przetwarzacze wiadomości: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Powtórz te czynności w przypadku wszystkich pozostałych procesorów wiadomości.

Włączanie SNI między Edge a backendem w przypadku Edge w wersji 4.16.01 lub nowszej

Aby włączyć SNI:

  1. W pierwszym węźle przetwarzania wiadomości zmień wartość /opt/apigee/customer/application/message-processor.properties. Jeśli plik nie istnieje, utwórz go.
  2. Dodaj do pliku tę właściwość: 
    conf_system_jsse.enableSNIExtension=true
  3. Ponownie uruchom przetwarzacz wiadomości: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Powtórz te czynności w przypadku wszystkich pozostałych procesorów wiadomości.