503 서비스 사용 불가 - SSL 핸드셰이크 실패

API 모니터링

절차 #1: API 모니터링 사용

API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.

1. <ph type="x-smartling-placeholder"></ph> 다음 계정으로 Apigee Edge UI에 로그인: 역할을 수행하는 것이 좋습니다.

2. 문제를 조사하려는 조직으로 전환합니다.

   
3. 분석 > API 모니터링 > 조사 페이지를 엽니다.
4. 오류가 관찰된 특정 기간을 선택합니다.

5. 시간을 기준으로 결함 코드를 표시합니다.

   <ph type="x-smartling-placeholder">

6. 오류 코드가 있는 셀을 선택합니다. messaging.adaptors.http.flow.SslHandshakeFailed(아래 그림) 아래:

   ( 더 크게 보기)

   

7. 오류 코드에 대한 정보 messaging.adaptors.http.flow.SslHandshakeFailed는 다음과 같이 표시됩니다. 다음과 같습니다.

   ( 더 크게 보기)

   

8. 로그 보기 를 클릭하고 실패한 요청의 행을 펼칩니다.

   ( 더 크게 보기)

   
9. 로그 창에서 다음 세부정보를 확인합니다. <ph type="x-smartling-placeholder">
   </ph>
   • 요청 메시지 ID
   • 상태 코드: 503
   • 오류 소스: target
   • 오류 코드: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

절차 #2: Trace 도구 사용

Trace 도구를 사용하여 오류를 진단하는 방법은 다음과 같습니다.

1. 추적 세션을 사용 설정하고 다음 중 하나를 수행합니다. <ph type="x-smartling-placeholder">
   </ph>
   • 오류 코드와 함께 503 Service Unavailable 오류 대기 발생 시간 messaging.adaptors.http.flow.SslHandshakeFailed 또는
   • 문제를 재현할 수 있는 경우 API를 호출하여 문제를 재현합니다. 503 Service Unavailable

2. 모든 FlowInfos 표시가 사용 설정되어 있는지 확인합니다.

   
3. 실패한 요청 중 하나를 선택하고 trace를 검토합니다.
4. 추적의 여러 단계를 살펴보고 오류가 발생한 위치를 찾습니다.

5. 오류는 일반적으로 Target Request Flow Started(대상 요청 흐름 시작됨) 단계 다음에 표시됩니다. 다음과 같습니다.

   ( 더 크게 보기)

   
6. 트레이스에서 다음 값을 확인합니다. <ph type="x-smartling-placeholder">
   </ph>
   • 오류: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException
   • SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 오류 값은 SSL 핸드셰이크가 실패했음을 나타냅니다. Apigee Edge의 메시지 프로세서가 백엔드 서버의 있습니다.
7. 트레이스의 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.

8. 아래로 스크롤하여 단계 세부정보 오류 헤더 섹션으로 이동한 후 X-Apigee-fault-code 및 X-Apigee-fault-source의 값 X-Apigee-Message-ID:

   ( 더 크게 보기)

   
9. X-Apigee-fault-code, X-Apigee-fault-source, 및 X-Apigee-Message-ID:

오류 헤더	값
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

절차 #3: NGINX 액세스 로그 사용

NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.

1. Private Cloud 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP 503 Service Unavailable에 대한 주요 정보입니다.

2. NGINX 액세스 로그를 확인합니다.

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

   <ph type="x-smartling-placeholder">
3. 오류 코드와 함께 503 오류가 있는지 검색하여 확인합니다. 특정 기간 동안 messaging.adaptors.http.flow.SslHandshakeFailed ( 여전히 503로 실패하는 요청이 있는지 확인하세요.

4. X-Apigee-fault-code가 일치하는 503 오류가 발견된 경우 messaging.adaptors.http.flow.SslHandshakeFailed의 값, X-Apigee-fault-source.의 값을 결정합니다.

   NGINX 액세스 로그의 샘플 503 오류:

   ( 더 크게 보기)

   

   NGINX 액세스 로그의 위 샘플 항목에는 다음과 같은 값이 있습니다. X-Apigee-fault-code 및 X-Apigee-fault-code

   헤더	값
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

메시지 프로세서 로그

절차 #4: 메시지 프로세서 로그 사용

1. API 모니터링, Trace 도구, 또는 NGINX 액세스 로그를 기록합니다.일반적인 진단 단계

2. 메시지 프로세서 로그에서 특정 요청 메시지 ID 검색 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 다음 현상은 다음 오류가 반환됩니다.

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   위의 오류는 메시지 프로세서 간의 SSL 핸드셰이크가 실패했음을 나타냅니다. 백엔드 서버가 포함됩니다

   그러면 아래와 같이 자세한 스택 트레이스가 포함된 예외가 발생합니다.

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   다음과 같은 이유로 핸드셰이크 실패가 발생합니다.

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   이는 Apigee Edge의 메시지 프로세서가 SSL 핸드셰이크가 실패했음을 나타냅니다. 백엔드 서버의 인증서를 확인할 수 없습니다.

1단계

1단계: 백엔드 서버의 인증서 체인 결정

다음 방법 중 하나를 사용하여 백엔드 서버의 인증서 체인을 확인합니다.

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

2단계

2단계: 백엔드 서버의 인증서와 메시지 프로세서의 트러스트 저장소

1. 백엔드 서버의 인증서 체인을 결정합니다.
2. 다음을 사용하여 메시지 프로세서의 트러스트 저장소에 저장된 인증서를 확인합니다. 다음 단계를 따르세요. <ph type="x-smartling-placeholder">
   </ph>

   1. TrustStore 요소에서 truststore 참조 이름 가져오기 (TargetEndpoint의 SSLInfo 섹션)

      TargetEndpoint의 샘플 SSLInfo 섹션을 살펴보겠습니다. 구성:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. 위의 예에서 TrustStore 참조 이름은 다음과 같습니다. myCompanyTruststoreRef

   3. Edge UI에서 환경 > 참조. 특정 truststore 참조의 Reference 열 사용 중인 트러스트 저장소 이름을 지정합니다

      ( 더 크게 보기)

      

   4. 위의 예에서 트러스트 저장소 이름은 다음과 같습니다.

      myCompanyTruststoreRef: myCompanyTruststore

3. 트러스트 저장소에 저장된 인증서 가져오기 (이전 단계에서 결정) 다음 API를 사용합니다.

   1. <ph type="x-smartling-placeholder"></ph> 키 저장소 또는 트러스트 저장소의 모든 인증서 가져오기. 이 API는 특정 트러스트 저장소에 있는 인증서를 사용합니다

      퍼블릭 클라우드 사용자:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Private Cloud 사용자:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      위치:

      • ORGANIZATION_NAME는 조직의 이름입니다.
      • ENVIRONMENT_NAME은 환경 이름입니다.
      • KEYSTORE_NAME은 키 저장소의 이름입니다.
      • $TOKEN이 OAuth 2.0 액세스 토큰 받기
      • 이 예에서 사용된 curl 옵션은 다음에 설명되어 있습니다. curl 사용

      샘플 출력:

      트러스트 저장소 myCompanyTruststore 예시의 인증서는 다음과 같습니다.

      [
        "serverCert"
      ]
      

   2. <ph type="x-smartling-placeholder"></ph> 키 저장소 또는 트러스트 저장소에서 특정 인증서의 인증서 세부정보 가져오기 이 API는 특정 인증서에 대한 정보를 트러스트 저장소

      퍼블릭 클라우드 사용자:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Private Cloud 사용자

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      위치:

      • ORGANIZATION_NAME는 조직의 이름입니다.
      • ENVIRONMENT_NAME은 환경 이름입니다.
      • KEYSTORE_NAME은 키 저장소의 이름입니다.
      • CERT_NAME은 인증서 이름입니다.
      • $TOKEN이 OAuth 2.0 액세스 토큰 받기
      • 이 예에서 사용된 curl 옵션은 다음에 설명되어 있습니다. curl 사용

      샘플 출력

      serverCert 세부정보에는 다음과 같은 제목과 발급기관이 표시됩니다.

      리프/엔티티 인증서:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      중급 인증서:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. 1단계에서 받은 실제 서버 인증서와 3단계에서 가져온 truststore에 저장된 데이터 세트와 일치해야 합니다. 일치하지 않을 경우 문제를 일으킬 수 있습니다

   위의 예에서 한 번에 하나의 인증서를 살펴보겠습니다.

   1. 리프 인증서:

      백엔드 서버에서:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      메시지 프로세서 (클라이언트)의 트러스트 저장소에서 다음을 실행합니다.

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      트러스트 저장소에 저장된 리프 인증서가 백엔드의 리프 인증서와 일치합니다. 있습니다.

   2. 중급 인증서:

      백엔드 서버에서:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      메시지 프로세서 (클라이언트)의 트러스트 저장소에서 다음을 실행합니다.

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      트러스트 저장소에 저장된 중간 인증서가 인증서의 백엔드 서버입니다

   3. 루트 인증서:

      백엔드 서버에서:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      루트 인증서가 메시지 프로세서의 트러스트 저장소

   4. truststore에 루트 인증서가 누락되었으므로 메시지 프로세서에서 다음과 같은 예외가 발생합니다.

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      오류 코드와 함께 503 Service Unavailable를 반환합니다. 클라이언트에게 messaging.adaptors.http.flow.SslHandshakeFailed 애플리케이션을 실행할 수 있습니다

올바른 FQDN

올바른 FQDN, 유효하고 완전한 인증서로 백엔드 서버의 키 저장소 업데이트 체인:

1. 올바른 FQDN을 가진 백엔드 서버의 인증서가 없으면 적절한 CA (인증 기관)에서 적절한 인증서를 조달합니다.

2. 서비스 계정 보안을 유효하고 완전한 백엔드 서버의 인증서 체인이어야 합니다.

   <ph type="x-smartling-placeholder">
3. 올바른 FQDN을 가진 유효하고 완전한 인증서 체인이 있으면 호스트 이름과 동일한 리프 또는 엔티티 인증서에 있는 백엔드 서버 지정된 경우 백엔드 키 저장소를 전체 인증서 체인입니다

올바른 백엔드 서버

올바른 백엔드 서버의 호스트 이름으로 대상 엔드포인트를 업데이트합니다.

1. 호스트 이름이 대상 엔드포인트에 잘못 지정된 경우 대상 엔드포인트가 백엔드의 FQDN과 일치하는 올바른 호스트 이름을 갖도록 함 서버의 인증서를 받습니다

2. API 프록시에 변경사항을 저장합니다.

   위에 설명된 예에서 백엔드 서버 호스트 이름이 잘못 백엔드 서버의 인증서에서 FQDN을 사용하여 문제를 해결할 수 있습니다. 다음과 같이 backend.apigee.net입니다.

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>