502 Bad Gateway – certyfikat podpisany samodzielnie w sieci

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod odpowiedzi HTTP 502 z komunikatem Bad Gateway w odpowiedzi na wywołania interfejsu API w Edge Microgateway.

Administrator może też otrzymać błąd self signed certificate in certificate chain podczas uruchamiania polecenia edgemicro configure.

Komunikat o błędzie

Klient zobaczy ten komunikat z odpowiedzią:

HTTP/1.1 502 Bad Gateway

2 typowe przykłady odpowiedzi z błędem:

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}

{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

Ten błąd może też wystąpić podczas uruchamiania polecenia edgemicro configure:

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Możliwe przyczyny

Przyczyna: serwer docelowy przedstawia certyfikat podpisany samodzielnie

Jeśli serwer docelowy przedstawi certyfikat podpisany samodzielnie w połączeniu wychodzącym, Edge Microgateway domyślnie zgłosi ten błąd, ponieważ nie ufa certyfikatom podpisanym samodzielnie.

Diagnostyka

W dziennikach (/var/tmp/edgemicro-`hostname`- *.log) możesz zobaczyć ten błąd:

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

Kod błędu SELF_SIGNED_CERT_IN_CHAIN wskazuje, że Edge Microgateway najprawdopodobniej otrzymał certyfikat podpisany samodzielnie z serwera docelowego. Aby to potwierdzić, wykonaj te czynności:

1. Uruchom to polecenie openssl, aby zweryfikować łańcuch certyfikatów serwera docelowego:

   echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
   

2. Jeśli łańcuch certyfikatów serwera docelowego jest rzeczywiście podpisany samodzielnie, to jest to przyczyna problemu. problemu.

   W tym przykładzie serwer docelowy przedstawia certyfikat podpisany samodzielnie:

   echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
   

   depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
   verify error:num=19:self signed certificate in certificate chain
   verify return:0
   DONE

Rozwiązanie

1. Skontaktuj się z zespołem odpowiedzialnym za serwer docelowy, aby uzyskać prawidłowy certyfikat TLS podpisany przez zaufany urząd certyfikacji .

2. Jeśli nie jest to możliwe, rozważ jedną z tych opcji, aby zezwolić na certyfikaty podpisane samodzielnie w Edge Microgateway.

   Opcja 1. Ustaw właściwość systemu, aby zezwolić Edge Microgateway na zaufanie wszystkim certyfikatom

   1. Jeśli używasz Dockera, zapoznaj się z artykułem Używanie urzędu certyfikacji, który nie jest zaufany przez Node.js

   2. W przeciwnym razie wyeksportuj zmienną środowiskową o nazwie NODE_EXTRA_CA_CERTS, wskazującą plik głównego urzędu certyfikacji.

      Jest to opisane w oficjalnej Node.js.

   Opcja 2. Skonfiguruj plik konfiguracyjny YAML Edge Microgateway, aby ufać temu konkretnemu certyfikatowi na tym serwerze docelowym

   1. Upewnij się, że masz certyfikat (lub łańcuch) serwera docelowego w formacie PEM. Aby przekonwertować inne formaty certyfikatów na format PEM, postępuj zgodnie z instrukcjami w artykule Konwertowanie certyfikatów na obsługiwany format.

   2. Jeśli istnieje łańcuch certyfikatów, upewnij się, że certyfikaty są w prawidłowej kolejności. Certyfikat liścia powinien zawsze znajdować się na początku, a następnie certyfikat pośredni i certyfikat główny. Więcej informacji na ten temat znajdziesz w artykule Weryfikowanie łańcucha certyfikatów.

      W tym przykładzie skonfigurowaliśmy zaufany plik urzędu certyfikacji dla untrusted-root.badssl.com.

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

   Instrukcje dotyczące konfigurowania tej opcji znajdziesz też w filmie Edge Microgateway Module – Configure 1-way and 2-way Southbound TLS. Więcej informacji znajdziesz w artykule Konfigurowanie protokołu SSL na serwerze Edge Microgateway.

Jeśli problem nadal występuje, przejdź do sekcji Informacje diagnostyczne, które musisz zebrać.

Przyczyna: serwer zarządzania Apigee Edge używa certyfikatu podpisanego samodzielnie

Podczas pierwszej konfiguracji Edge Microgateway musisz uruchomić polecenie edgemicro configure lub edgemicro private configure. To polecenie uruchomi klaster i połączy się z Apigee Edge, aby pobrać wymagane informacje.

W przypadku prywatnej chmury Edge adres URL serwera zarządzania jest określany przez argument -m. Jeśli włączysz TLS na serwerze zarządzania, Edge Microgateway spróbuje zweryfikować certyfikat przedstawiony przez serwer zarządzania.

Oto przykład polecenia edgemicro configure dla prywatnej chmury Edge:

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

Jeśli serwer zarządzania jest skonfigurowany z certyfikatem podpisanym samodzielnie, w danych wyjściowych konsoli zobaczysz ten błąd.

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Diagnostyka

1. W tym przypadku serwer zarządzania (management.apigee-dev.net) może zwracać certyfikat TLS podpisany samodzielnie.
2. Prawdopodobnie administrator systemu Apigee Edge udostępnił certyfikat i ma jego kopię.
3. W przeciwnym razie uruchom to polecenie, aby uzyskać informacje o certyfikacie:

   echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
   

4. Jeśli serwer zarządzania ma certyfikat podpisany samodzielnie, to jest to przyczyna tego problemu.

Rozwiązanie

1. Skontaktuj się z zespołem odpowiedzialnym za serwer docelowy, aby uzyskać prawidłowy certyfikat TLS podpisany przez zaufany urząd certyfikacji .

2. Jeśli nie jest to możliwe, wykonaj te czynności, aby zezwolić na certyfikaty podpisane samodzielnie w Edge Microgateway.

3. Ustaw właściwość systemu, aby zezwolić Edge Microgateway na zaufanie wszystkim certyfikatom.
4. Jeśli używasz Dockera, zapoznaj się z artykułem Używanie urzędu certyfikacji, który nie jest zaufany przez Node.js.
5. W przeciwnym razie wyeksportuj zmienną środowiskową o nazwie NODE_EXTRA_CA_CERTS, wskazującą plik głównego urzędu certyfikacji.Jest to opisane w oficjalnej Node.js.

Informacje diagnostyczne, które musisz zebrać

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

• Pliki dziennika: domyślny folder to /var/tmp, ale można go zastąpić w głównym pliku config.yaml (logging > dir parameter). Przed przekazaniem plików dziennika zespołowi pomocy Apigee Edge zalecamy zmianę log > level na info.
• Plik konfiguracyjny: główna konfiguracja Edge Microgateway znajduje się w pliku YAML w domyślnym folderze Edge Microgateway, $HOME/.edgemicro. Dostępny jest domyślny plik konfiguracyjny o nazwie default.yaml oraz plik dla każdego środowiska ORG-ENV-config.yaml. Prześlij ten plik w całości dla organizacji i środowiska, których dotyczy problem.

  Dokumenty referencyjne

  Konfigurowanie interfejsu Edge pod kątem korzystania z TLS w celu uzyskania dostępu do interfejsu Edge API