Korzystanie z rozszerzenia SNI w przeglądarce Edge

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Wskazanie nazwy serwera (SNI) umożliwia obsługę wielu celów HTTPS z tego samego adresu IP i portu bez konieczności używania tego samego certyfikatu TLS. Gdy rozszerzenie SNI jest włączone w kliencie, przekazuje nazwę hosta docelowego punktu końcowego w ramach początkowego uzgadniania połączenia TLS. Dzięki temu serwer TLS będzie mógł określić, którego certyfikatu TLS należy użyć do zweryfikowania żądania.

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

Edge obsługuje SNI dla:

  • Żądania wysyłane 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.

Dodatkowe informacje na temat SNI:

Obsługa SNI dla żądania wysyłanego do serwera proxy interfejsu API w Edge

Obsługa SNI dla żądań wysyłanych do serwerów proxy interfejsów 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ę DNS i port, na których jest dostępny serwer proxy interfejsu API, a także adres URL, którego aplikacje używają, aby uzyskać dostęp do serwera proxy interfejsu API. Adres IP/nazwa DNS odpowiada routerowi brzegowemu, a numer portu to otwarty port w routerze.

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

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

Dodatkowe informacje o hostach wirtualnych znajdziesz w tych artykułach:

Jak SNI działa z aliasami hostów

SNI umożliwia skonfigurowanie wielu hostów wirtualnych na tym samym porcie, z których każdy ma inne certyfikaty i klucze TLS. Następnie Edge określa hosta wirtualny oraz parę certyfikat/klucz używany przez protokół TLS na podstawie rozszerzenia server_name w żądaniu uzgadniania połączenia TLS.

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

Zamiast nieudanego uzgadniania połączenia TLS możesz zdefiniować domyślną parę certyfikat/klucz w sposób opisany w następnych sekcjach.

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

Apigee udostępnia certyfikat TLS i klucz prywatny do obsługi protokołu HTTPS. Wielu klientów woli używać własnego certyfikatu i klucza prywatnego podczas wdrażania, ale możliwe jest wdrażanie interfejsów API za pomocą certyfikatu i klucza Apigee.

Jeśli w Edge dla chmury router nie może dopasować nagłówka SNI do aliasu hosta lub klient nie obsługuje SNI, router używa domyślnego certyfikatu dostarczonego przez Apigee, którym jest *.apigee.net.

Definiowanie domyślnej pary certyfikatu i klucza w Edge dla chmury Private Cloud

Jeśli w Edge dla chmury prywatnej nie znaleziono dopasowania między rozszerzeniem server_name a aliasami hosta 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 definiowany przez połączenie nazwy organizacji, nazwy środowiska i nazwy hosta wirtualnego w formacie:

orgName_envName_vhName

Router używa certyfikatu/klucza z kombinacji klucza orgName_envName_vhName, która pojawia się na początku w kolejności alfabetycznej. Na przykład żądanie jest wysyłane przez port 443, a dla organizacji example w środowisku prod są zdefiniowane 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ś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. Ponownie uruchom router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Powtórz te kroki dla wszystkich pozostałych routerów.

Zamiast używać certyfikatu lub klucza z domyślnego hosta wirtualnego, możesz bezpośrednio zdefiniować domyślny certyfikat/klucz w routerze. Aby zdefiniować wyraźną domyślną parę certyfikat/klucz, wykonaj te czynności:

  1. W pierwszym węźle routera skopiuj certyfikat i klucz prywatny do lokalizacji w węźle routera, do której użytkownik apigee. Na przykład: /opt/apigee/customer/application.
  2. Zmień własność plików na użytkownika „apigee.”: 
    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 umożliwić określenie domyślnego certyfikatu lub klucza:
    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 obiekcie 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. Ponownie uruchom router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Powtórz te kroki dla wszystkich pozostałych routerów.

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

Edge obsługuje korzystanie z SNI z procesorów wiadomości do docelowych punktów końcowych w Apigee Edge w przypadku Cloud i wdrożeń w chmurze Private Cloud. Domyślnie usługa SNI jest włączona w brzegowych procesorach wiadomości w chmurze i wyłączona w chmurze prywatnej.

Używanie SNI z backendem w Edge dla Private Cloud

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

Żadna inna konfiguracja specyficzna dla brzegu nie jest wymagana. 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 backendem dla Edge w wersji 4.15.07.0x

Aby włączyć SNI, wykonaj te czynności:

  1. W pierwszym węźle procesora wiadomości otwórz plik /opt/apigee4/conf/apigee/message-processor/system.properties w edytorze.
  2. Ustaw wartość „true” dla tej właściwości w komponencie system.properties: 
    jsse.enableSNIExtension=true
  3. Ponownie uruchom procesory wiadomości: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Powtórz te kroki w przypadku wszystkich pozostałych procesorów do przetwarzania wiadomości.

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

Aby włączyć SNI, wykonaj te 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. Ponownie uruchom procesor wiadomości: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Powtórz te kroki w przypadku wszystkich pozostałych procesorów do przetwarzania wiadomości.