Korzystanie z rozszerzenia SNI w przeglądarce Edge

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja 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 przez te cele. Gdy SNI jest włączony na kliencie, klient przekazuje nazwę hosta docelowego punktu końcowego jako część początkowej wartości Uzgadnianie połączenia TLS. Dzięki temu serwer TLS może określić, który certyfikat TLS należy użyć do weryfikacji do danej prośby.

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

Edge obsługuje rozszerzenie SNI w tych przypadkach:

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

Dodatkowe informacje na temat SNI znajdziesz tutaj:

Obsługa SNI dla żądania do serwera proxy interfejsu API włączona Krawędź

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

Informacje o środowisku wirtualnym hosty i aliasy hostów

W przypadku Edge host wirtualny definiuje adres IP i port lub nazwę i port DNS. dostęp do serwera proxy interfejsu API oraz, co za tym idzie, 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 w Router.

Podczas tworzenia hosta wirtualnego określasz także alias hosta wirtualnego. Zwykle jest to nazwa DNS hosta wirtualnego. Podczas określania serwera proxy interfejsu API, obsługuje żądanie, router porównuje nagłówek Host żądania przychodzącego z nagłówkiem 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 i hostach wirtualnych. 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 za pomocą protokołu HTTP, za pomocą zaszyfrowanego protokołu HTTPS z użyciem TLS. Podczas konfigurowania hosta wirtualnego do korzystania z HTTPS: powiąż hosta wirtualnego z magazynem kluczy zawierającym certyfikat i klucz prywatny, używane przez hosta wirtualnego podczas uzgadniania połączenia TLS.

Dodatkowe informacje na temat hostów wirtualnych znajdziesz tutaj:

Jak działa SNI aliasy hostów

SNI umożliwia definiowanie na tym samym porcie wielu hostów wirtualnych, z których każdy ma inny Certyfikaty i klucze TLS. Edge określa hosta wirtualnego i parę certyfikatów/kluczy używaną przez TLS. na podstawie server_name w żądaniu uzgadniania połączenia TLS.

Router brzegowy odczytuje rozszerzenie server_name podczas uzgadniania połączenia TLS a następnie używa go do wyszukiwania aliasów hostów na wszystkich hostów. Jeśli router wykryje dopasowanie do aliasu hosta, używa certyfikatu i klucza TLS z hosta wirtualnego powiązanego z aliasem hosta. Jeśli nie zostanie znalezione dopasowanie, uzgadnianie połączenia TLS się nie powiedzie.

Zamiast uzgadniania połączenia TLS możesz zdefiniować domyślną parę certyfikat/klucz: opisane w następnych sekcjach.

Definiowanie domyślnej pary certyfikatów/kluczy w Edge dla chmury

Apigee udostępnia certyfikat TLS i klucz prywatny do obsługi HTTPS. Wielu klientów wykorzystują własny certyfikat i klucz prywatny podczas wdrażania, możesz wdrożyć swoje interfejsy API, za pomocą certyfikatu i klucza Apigee.

W Edge dla chmury, 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ów i kluczy w Edge dla chmury prywatnej

W Edge dla chmury prywatnej, jeśli nie znaleziono dopasowania między rozszerzeniem server_name a aliasami hosta ze wszystkich hostów wirtualnych, a jeśli klient wysyłający żądanie nie obsługuje rozszerzenia SNI, możesz skonfigurować Router umożliwiający używanie certyfikatu/klucza z domyślnego hosta wirtualnego na porcie. Domyślnym hostem wirtualnym jest zdefiniowaną przez połączenie nazwy organizacji, nazwy środowiska i nazwy hosta wirtualnego w polu formularz:

orgName_envName_vhName

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

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

W tym przykładzie router używa certyfikatu/klucza z hosta wirtualnego o nazwie default bo example_prod_default pojawia się 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 plik nie istnieje, utwórz go.
  2. Dodaj do pliku tę właściwość, by zdefiniować 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 na wszystkich pozostałych routerach.

Zamiast używać certyfikatu/klucza z domyślnego hosta wirtualnego, możesz bezpośrednio zdefiniować domyślny certyfikat/klucz w routerze. Zdefiniuj konkretną wartość domyślną, korzystając z poniższej procedury para certyfikatów/kluczy:

  1. W pierwszym węźle routera skopiuj certyfikat i klucz prywatny do lokalizacji w węźle routera. który jest dostępny dla użytkownika Apigee. Na przykład: /opt/apigee/customer/application.
  2. Zmień własność plików na „apigee”. użytkownik: 
    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. Dodaj do pliku te właściwości, które pozwolą Ci 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 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 na wszystkich pozostałych routerach.

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

Edge obsługuje użycie SNI z procesorów wiadomości do docelowych punktów końcowych w Apigee Edge dla Cloud i wdrożenia w chmurze prywatnej. Domyślnie rozszerzenie SNI jest włączone w procesorach obsługujących wiadomości na serwerach brzegowych dla chmury i wyłączono w chmurze prywatnej.

Zastosowanie SNI do backendu w Edge dla chmury prywatnej

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

Nie jest wymagana żadna inna konfiguracja Edge. Jeśli środowisko docelowe jest skonfigurowane na Obsługuje SNI, Edge. Edge automatycznie wyodrębnia nazwę hosta z adresu URL żądania i ją dodaje 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 tę właściwość na „true” w elemencie system.properties: 
    jsse.enableSNIExtension=true
  3. Uruchom ponownie procesory wiadomości: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Powtórz te kroki na wszystkich pozostałych procesorach wiadomości.

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

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 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 na wszystkich pozostałych procesorach wiadomości.