Ta strona została przetłumaczona przez Cloud Translation API.

Nieudane uzgadnianie połączenia SSL – nieprawidłowy certyfikat klienta

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 503 z komunikat „Service Unavailable” (Usługa niedostępna) w odpowiedzi na żądanie do interfejsu API. W zrzucie interfejsu możesz zauważyć, że błąd error.cause to Received fatal alert: bad_certificate w docelowym przepływie żądań dla nieudanego żądania do interfejsu API.

Jeśli masz dostęp do dzienników przetwarzania wiadomości, zobaczysz komunikat o błędzie: Received fatal alert: bad_certificate dla nieudanego żądania do interfejsu API. Ten błąd jest zaobserwowany podczas uzgadniania połączenia SSL między procesorem wiadomości a serwerem backendu przy użyciu dwukierunkowej konfiguracji TLS.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 503 Service Unavailable

Możesz też zobaczyć następujący komunikat o błędzie:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

Użytkownicy Private Cloud zobaczą ten błąd w przypadku konkretnego żądania do interfejsu API w logach procesora wiadomości /opt/apigee/var/log/edge-message-processor/system.log:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

Możliwe przyczyny

Możliwe przyczyny tego problemu:

Przyczyna	Opis	Instrukcje dotyczące rozwiązywania problemów dotyczące
Brak certyfikatu klienta	Magazyn kluczy używany w docelowym punkcie końcowym serwera docelowego nie ma żadnego certyfikatu klienta.	Użytkownicy chmury prywatnej i publicznej na serwerach brzegowych
Niezgodność urzędu certyfikacji	Urząd certyfikacji certyfikatu liścia (pierwszego certyfikatu w łańcuchu certyfikatów) w magazynie kluczy procesora wiadomości nie pasuje do żadnego z urzędów certyfikacji zaakceptowanych przez serwer backendu.	Użytkownicy chmury prywatnej i publicznej na serwerach brzegowych

Najczęstsze kroki diagnostyki

Włącz śledzenie w interfejsie Edge, wywołaj interfejs API i odtwórz problem.
W wynikach śledzenia UI przejdź do poszczególnych faz i określ, gdzie występują wystąpił błąd. Ten błąd wystąpił w docelowym przepływie żądań.
Zapoznaj się z przepływem danych, w którym pojawia się błąd – błąd powinien się pojawić w tym przykładowym logu czasu:
Jak widać na zrzucie ekranu powyżej, błąd error.cause to „Odebrano alert krytyczny: bad_certificate”.

Jeśli jesteś użytkownikiem Private Cloud, wykonaj te czynności:

Aby uzyskać identyfikator wiadomości nieudanego żądania do interfejsu API, określ wartość nagłówka błędu „X-Apigee.Message-ID” w fazie wskazywanej przez AX w śledzeniu.

Wyszukaj ten identyfikator wiadomości w dzienniku procesora wiadomości /opt/apigee/var/log/edge-message-processor/system.log i określ jeśli możesz znaleźć dodatkowe informacje na temat błędu:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

W logu procesora wiadomości był zrzut stosu związany z błędem Received fatal alert: bad_certificate, ale nie dodatkowe informacje wskazujące przyczynę tego problemu.

Aby dokładniej zbadać ten problem, musisz przechwycić pakiety TCP/IP za pomocą Narzędzie tcpdump.
1. Jeśli jesteś użytkownikiem Private Cloud, możesz przechwytywać Pakiety TCP/IP na serwerze backendu lub w procesorze wiadomości. Najlepiej przechwyć je na serwerze backendu, gdy pakiety są odszyfrowywane do serwera backendu.
2. Jeśli jesteś użytkownikiem Public Cloud Cloud, przechwyć port TCP/IP na serwerze backendu.
3. Po wybraniu miejsca, w którym chcesz przechwytywać pakiety TCP/IP, użyj poniżej tcpdump do przechwytywania pakietów TCP/IP.
Przeanalizuj pakiety TCP/IP przy użyciu narzędzia Wireshark lub podobnego narzędzia, które już znasz.

Analiza przykładowych danych pakietów TCP/IP za pomocą narzędzia Wireshark:

alt_text

Komunikat nr 4 w powyższym pliku tcpdump pokazuje, że procesor wiadomości (źródło) wysłał komunikat „Client Hello” (Witaj w kliencie) do serwera backendu (do miejsca docelowego).
Komunikat nr 5 pokazuje, że serwer backendu potwierdził komunikat „Client Hello” z procesora wiadomości.
Serwer backendu wysyła komunikat „Server Hello”. wraz z certyfikatem, a następnie żąda od klienta wysłania certyfikatu w wiadomości nr 7.
Procesor wiadomości kończy weryfikację certyfikatu i potwierdza wiadomość ServerHello serwera backendu w wiadomości nr 8.
Procesor wiadomości wysyła swój certyfikat do serwera backendu w wiadomości nr 9.
Serwer backendu potwierdza odbiór Certyfikat w wiadomości nr 11.
Natychmiast jednak do Procesor wiadomości (komunikat 12). Oznacza to, że certyfikat wysłany przez ze względu na problem z procesorem wiadomości, w związku z czym weryfikacja certyfikatu zakończyła się niepowodzeniem do serwera backendu. W rezultacie nie udało się uzgadniać połączenia SSL, a połączenie zostanie zamknięte.
Spójrzmy teraz na wiadomość nr 9, aby sprawdzić zawartość certyfikatu wysłanego przez procesor wiadomości:
Jak możesz zauważyć, serwer backendu nie otrzymał żadnego certyfikatu z klienta. (Długość certyfikatu: 0). Dlatego serwer backendu wysyła alert krytyczny: nieprawidłowy certyfikat.
Zwykle dzieje się tak, gdy klient, czyli procesor wiadomości (proces oparty na Javie):
1. nie ma żadnego certyfikatu klienta w swoim magazynie kluczy;
2. Nie udało się wysłać certyfikatu klienta. Może się tak zdarzyć, jeśli nie może znaleźć Certyfikat wystawiony przez jeden z dozwolonych urzędów certyfikacji serwera backendu. Czyli: jeśli urząd certyfikacji certyfikatu liścia klienta (tj. pierwszy certyfikat w łańcuchu) nie pasuje do żadnego z certyfikatów serwera backendu urzędy certyfikacji, to podmiot przetwarzający wiadomości nie wyśle certyfikatu.

Przyjrzyjmy się każdej z tych przyczyn z osobna.

Przyczyna: brak certyfikatu klienta

Diagnostyka

Jeśli w magazynie kluczy nie ma certyfikatu określonego w sekcji Informacje o SSL docelowego punktu końcowego lub serwera docelowego używanego w docelowym punkcie końcowym, to właśnie jest przyczyną tego błędu.

Aby sprawdzić, czy to jest przyczyną, wykonaj te czynności:

Określ magazyn kluczy używany w docelowym punkcie końcowym lub na serwerze docelowym dla określonego serwera proxy interfejsu API, wykonując te czynności:
1. Pobierz nazwę referencyjną magazynu kluczy z elementu Keystore. w sekcji SSLInfo w docelowym punkcie końcowym lub na serwerze docelowym.
  Przyjrzyjmy się przykładowej sekcji SSLInfo w docelowej konfiguracji punktu końcowego:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. W powyższym przykładzie nazwa referencyjna magazynu kluczy to „myKeystoreRef”.
3. Otwórz interfejs Edge i wybierz API proxy -> Konfiguracje środowiska.
  Wybierz kartę Pliki referencyjne i wyszukaj nazwę referencji magazynu kluczy. Zanotuj nazwę w kolumnie Plik referencyjny dla konkretnego magazynu kluczy. Będzie to nazwa magazynu kluczy.
4. W powyższym przykładzie możesz zauważyć, że myKeystoreRef zawiera odwołanie do „moj_magazyn kluczy”. Nazwa magazynu kluczy to myKeystore.
Sprawdź, czy ten magazyn kluczy zawiera certyfikat, korzystając z interfejsu Edge lub Wyświetl listę certyfikatów dla interfejsu Keystore API.
Jeśli magazyn kluczy nie zawiera certyfikatów, przejdź do Przyczyna: niezgodność z urzędem certyfikacji.
Jeśli magazyn kluczy nie zawiera żadnego certyfikatu, to właśnie jest przyczyną certyfikat klienta nie jest wysyłany przez procesor wiadomości.

Rozdzielczość

Sprawdź, czy do odpowiedniego magazynu kluczy w procesorze wiadomości przesłano prawidłowy i kompletny łańcuch certyfikatów klienta.

Przyczyna: niezgodność z urzędem certyfikacji

Zwykle gdy serwer żąda od klienta wysłania certyfikatu, wskazuje zbiór zaakceptowanych wystawców lub urzędów certyfikacji. Jeśli wystawca lub urząd certyfikacji certyfikatu liścia (tzn. pierwszy certyfikatu w łańcuchu certyfikatów) w magazynie kluczy procesora wiadomości nie są zgodne z żadnym z urzędów certyfikacji zaakceptowanych przez serwer backendu, procesor wiadomości (czyli proces oparty na języku Java). nie wysyła certyfikatu do serwera backendu.

Aby sprawdzić, czy tak jest w Twoim przypadku, wykonaj te czynności:

Wyświetl listę certyfikatów dla interfejsu Keystore API.
Uzyskaj szczegóły każdego certyfikatu uzyskanego w kroku 1 powyżej za pomocą Uzyskiwanie certyfikatu interfejsu Keystore API

Zanotuj wystawcę certyfikatu liścia (czyli pierwszego certyfikatu w łańcuchu certyfikatów) zapisanego w magazynie kluczy.

Przykładowy certyfikat w zakresie liści

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

W powyższym przykładzie wystawcą/urzędem certyfikacji jest "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

Ustal na serwerze backendu listę zaakceptowanych wystawców lub urzędów certyfikacji, korzystając z jednej z tych metod:
Metoda nr 1: użyj poniższego polecenia opensl:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
Zapoznaj się z sekcją „Akceptowane nazwy urzędów certyfikacji klienta”. w danych wyjściowych tego polecenia, jak pokazano poniżej:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
Metoda nr 2: sprawdź pakiet Certificate Request w Pakiety TCP/IP, w przypadku których serwer backendu żąda od klienta przesłania certyfikatu:

W przykładowych pakietach TCP/IP pokazanych powyżej Certificate Request pakiet to komunikat nr 7. Więcej informacji znajdziesz w sekcji „Nazwy wyróżniające”, który zawiera listę akceptowanych urzędów certyfikacji serwera backendu.

Uwaga: lista „akceptowanych urzędów certyfikacji” serwera backendu jest wypełniane przez dodanie wydawców wszystkich certyfikatów przechowywanych w Truststore serwera backendu.
Sprawdź, czy urząd certyfikacji uzyskany w kroku 3 jest zgodny z listą zaakceptowanych wystawców lub urzędów certyfikacji na serwerze backendu uzyskanych w kroku 4. Jeśli wystąpi niezgodność, procesor wiadomości nie wyśle certyfikatu klienta. do serwera backendu.

W przykładzie powyżej widać, że wydawca certyfikatu liścia klienta w magazynie kluczy procesora wiadomości nie pasuje do żadnego Akceptowane urzędy certyfikacji Dlatego procesor wiadomości nie wysłanie certyfikatu klienta do serwera backendu. Powoduje to niepowodzenie uzgadniania połączenia SSL, a serwer backendu wysyła „Fatal alert: bad_certificate” .

Rozdzielczość

Sprawdź, czy certyfikat z wystawcą lub urzędem certyfikacji zgodnym wystawca lub urząd certyfikacji certyfikatu liścia klienta (pierwszy certyfikat). w łańcuchu) jest przechowywana w Truststore serwera backendu.
W przykładzie opisanym w tym Poradniku certyfikat u wystawcy "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" została dodana do magazynu Truststore serwera backendu w celu rozwiązania problemu.

Jeśli problem nadal występuje, przejdź do artykułu Wymagane zbieranie informacji diagnostycznych.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, Zbierz poniższe informacje diagnostyczne. Skontaktuj się z nimi i udostępnij im: Obsługa Apigee:

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
1. Nazwa organizacji
2. Nazwa środowiska
3. Nazwa serwera proxy interfejsu API
4. Wykonaj polecenie curl, aby odtworzyć błąd
5. Plik śledzenia pokazujący błąd
6. Pakiety TCP/IP przechwycone przez serwer backendu
Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
1. Zaobserwowano pełny komunikat o błędzie
2. Pakiet serwera proxy interfejsu API
3. Plik śledzenia pokazujący błąd
4. Logi procesora wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Pakiety TCP/IP przechwycone przez serwer backendu lub procesor wiadomości.
6. Dane wyjściowe Uzyskaj certyfikat dla interfejsu Keystore API.
Informacje o wypróbowanych sekcjach tego Poradnika i innych które pomogą nam szybko rozwiązać ten problem.