TLS/SSL 핸드셰이크 실패

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

증상

TLS/SSL 핸드셰이크 실패는 클라이언트와 서버가 TLS/SSL 프로토콜을 사용하여 통신을 설정할 수 없을 때 발생합니다. Apigee Edge에서 이 오류가 발생하면 클라이언트 애플리케이션에 서비스를 사용할 수 없음이라는 메시지와 함께 HTTP 상태 503이 수신됩니다. 이 오류는 TLS/SSL 핸드셰이크 실패가 발생하는 모든 API 호출 후 표시됩니다.

오류 메시지

HTTP/1.1 503 Service Unavailable

TLS/SSL 핸드셰이크 실패가 발생하는 경우에도 이 오류 메시지가 표시될 수 있습니다.

Received fatal alert: handshake_failure

가능한 원인

TLS (전송 계층 보안)는 브라우저나 앱 같은 웹 서버와 웹 클라이언트 간에 암호화된 링크를 설정하기 위한 표준 보안 기술입니다. 핸드셰이크는 TLS/SSL 클라이언트 및 서버가 통신할 수 있는 보안 키 집합을 설정할 수 있도록 하는 프로세스입니다. 이 과정에서 클라이언트와 서버는 다음을 수행합니다.

  1. 사용할 프로토콜 버전에 동의합니다.
  2. 사용할 암호화 알고리즘을 선택합니다.
  3. 디지털 인증서를 교환하고 검증하여 서로를 인증합니다.

TLS/SSL 핸드셰이크가 성공하면 TLS/SSL 클라이언트와 서버가 데이터를 서로 안전하게 전송합니다. 그렇지 않은 경우 TLS/SSL 핸드셰이크 실패가 발생하면 연결이 종료되고 클라이언트에서 503 Service Unavailable 오류가 수신됩니다.

TLS/SSL 핸드셰이크 실패의 가능한 원인은 다음과 같습니다.

원인 설명 문제 해결 단계를 수행할 수 있는 사용자
프로토콜 불일치 클라이언트가 사용하는 프로토콜을 서버에서 지원하지 않습니다. 프라이빗 및 퍼블릭 클라우드 사용자
암호화 묶음 불일치 클라이언트에서 사용하는 암호화 스위트가 서버에서 지원되지 않습니다. 프라이빗 및 퍼블릭 클라우드 사용자
잘못된 인증서 클라이언트에서 사용하는 URL의 호스트 이름이 서버 측에 저장된 인증서의 호스트 이름과 일치하지 않습니다. 프라이빗 및 퍼블릭 클라우드 사용자
클라이언트 또는 서버 측에 불완전하거나 잘못된 인증서 체인이 저장되어 있습니다. 프라이빗 및 퍼블릭 클라우드 사용자
잘못되거나 만료된 인증서가 클라이언트에서 서버로 전송되거나 서버에서 클라이언트로 전송됩니다. 프라이빗 및 퍼블릭 클라우드 사용자
SNI 지원 서버 백엔드 서버에는 SNI (서버 이름 표시)가 사용 설정되어 있지만 클라이언트는 SNI 서버와 통신할 수 없습니다. 프라이빗 클라우드 사용자만

프로토콜 불일치

수신 (북쪽 경계) 또는 발신 (남쪽 경계) 연결에서 클라이언트에서 사용하는 프로토콜을 서버에서 지원하지 않는 경우 TLS/SSL 핸드셰이크 실패가 발생합니다. 북쪽 방면 및 남쪽 방면 연결 이해도 참고하세요.

진단

  1. 오류가 북쪽 경계 연결 또는 남쪽 경계 연결 중 어디에서 발생했는지 확인합니다. 이 판단에 대한 자세한 안내는 문제의 원인 확인을 참조하세요.
  2. tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
    • Private Cloud 사용자는 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 북쪽 경계 연결의 경우) 또는 메시지 프로세서 (발신 또는 남쪽 연결의 경우)일 수 있습니다. 1단계에서 결정한 정보에 따라 에지 라우터 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)일 수 있습니다.
    • 퍼블릭 클라우드 사용자는 에지 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)에서만 tcpdump 데이터를 수집할 수 있습니다.
    tcpdump -i any -s 0 host IP address -w File name
    tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
  3. Wireshark 도구 또는 유사한 도구를 사용하여 tcpdump 데이터를 분석합니다.
  4. 다음은 Wireshark를 사용한 tcpdump의 샘플 분석입니다.
    • 이 예시에서는 메시지 프로세서와 백엔드 서버 (발신 또는 남쪽 연결) 사이에서 TLS/SSL 핸드셰이크 실패가 발생했습니다.
    • 아래 tcpdump 출력의 메시지 4는 메시지 프로세서 (소스)가 백엔드 서버 (대상)로 'Client Hello' 메시지를 보냈음을 보여줍니다.

    • Client Hello 메시지를 선택하면 아래와 같이 메시지 프로세서가 TLSv1.2 프로토콜을 사용 중임을 보여줍니다.

    • 메시지 5는 백엔드 서버가 메시지 프로세서의 'Client Hello' 메시지를 확인했음을 보여줍니다.
    • 백엔드 서버가 즉시 Fatal Alert : Close Notify를 메시지 프로세서 (메시지 6)에 보냅니다. 즉, TLS/SSL 핸드셰이크가 실패하고 연결이 종료됩니다.

    • 메시지 6을 자세히 살펴보면 TLS/SSL 핸드셰이크 실패의 원인이 아래와 같이 백엔드 서버가 TLSv1.0 프로토콜만 지원한다는 것을 알 수 있습니다.

    • 메시지 프로세서에서 사용하는 프로토콜과 백엔드 서버가 일치하지 않기 때문에 백엔드 서버에서 Fatal Alert Message: Close Notify 메시지를 보냈습니다.

해상도

메시지 프로세서는 자바 8에서 실행되며 기본적으로 TLSv1.2 프로토콜을 사용합니다. 백엔드 서버가 TLSv1.2 프로토콜을 지원하지 않으면 다음 단계 중 하나를 수행하여 이 문제를 해결할 수 있습니다.

  1. TLSv1.2 프로토콜을 지원하도록 백엔드 서버를 업그레이드하세요. 프로토콜 TLSv1.2가 보다 안전하므로 이 방법을 사용하는 것이 좋습니다.
  2. 어떤 이유로든 백엔드 서버를 즉시 업그레이드할 수 없는 경우 다음 단계에 따라 메시지 프로세서가 TLSv1.0 프로토콜을 사용하여 백엔드 서버와 통신하도록 할 수 있습니다.
    1. 프록시의 TargetEndpoint 정의에서 대상 서버를 지정하지 않은 경우 아래와 같이 Protocol 요소를 TLSv1.0로 설정합니다. 
      <TargetEndpoint name="default">
 …
 <HTTPTargetConnection>
   <SSLInfo>
       <Enabled>true</Enabled>
       <Protocols>
           <Protocol>TLSv1.0</Protocol>
       </Protocols>
   </SSLInfo>
   <URL>https://myservice.com</URL>
 </HTTPTargetConnection>
 …
</TargetEndpoint>
    2. 프록시에 대상 서버를 구성한 경우 이 관리 API를 사용하여 특정 대상 서버 구성에서 프로토콜을 TLSv1.0으로 설정합니다.

암호화 불일치

Apigee Edge의 수신 (노스바운드) 또는 발신 (남바운드) 연결에서 서버에서 클라이언트가 사용하는 암호화 제품군 알고리즘을 지원하지 않는 경우 TLS/SSL 핸드셰이크 실패가 발생할 수 있습니다. 북쪽 방면 및 남쪽 방면 연결 이해도 참고하세요.

진단

  1. 오류가 북쪽 경계 연결 또는 남쪽 경계 연결 중 어디에서 발생했는지 확인합니다. 이 판단에 대한 추가 지침은 문제의 원인 확인을 참조하세요.
  2. tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
    • Private Cloud 사용자는 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 북쪽 경계 연결의 경우) 또는 메시지 프로세서 (발신 또는 남쪽 연결의 경우)일 수 있습니다. 1단계에서 결정한 정보에 따라 에지 라우터 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)일 수 있습니다.
    • 퍼블릭 클라우드 사용자는 에지 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)에서만 tcpdump 데이터를 수집할 수 있습니다.
    tcpdump -i any -s 0 host IP address -w File name
    tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
  3. Wireshark 도구 또는 익숙한 다른 도구를 사용하여 tcpdump 데이터를 분석합니다.
  4. 다음은 Wireshark를 사용한 tcpdump 출력의 샘플 분석입니다.
    • 이 예시에서는 클라이언트 애플리케이션과 에지 라우터 (북쪽 연결 연결) 간에 TLS/SSL 핸드셰이크 오류가 발생했습니다. tcpdump 출력이 Edge 라우터에서 수집되었습니다.

    • 아래 tcpdump 출력의 메시지 4는 클라이언트 애플리케이션 (소스)이 에지 라우터 (대상)에 '클라이언트 Hello' 메시지를 보냈음을 보여줍니다.

    • 클라이언트 Hello 메시지를 선택하면 클라이언트 애플리케이션이 TLSv1.2 프로토콜을 사용 중임을 보여줍니다.

    • 메시지 5는 에지 라우터가 클라이언트 애플리케이션의 '클라이언트 Hello' 메시지를 승인하는 것을 보여줍니다.
    • 에지 라우터는 클라이언트 애플리케이션에 Fatal Alert : Handshake Failure를 즉시 전송합니다 (메시지 #6). 즉, TLS/SSL 핸드셰이크가 실패하고 연결이 종료됩니다.
    • 메시지 6을 자세히 살펴보면 다음 정보를 확인할 수 있습니다.
      • 에지 라우터는 TLSv1.2 프로토콜을 지원합니다. 즉, 클라이언트 애플리케이션과 에지 라우터 간에 프로토콜이 일치합니다.

      • 하지만 에지 라우터는 아래 스크린샷과 같이 클라이언트 애플리케이션에 Fatal Alert: Handshake Failure를 계속 전송합니다.

    • 이 오류는 다음 문제 중 하나로 인해 발생할 수 있습니다.
      • 클라이언트 애플리케이션이 Edge Router에서 지원하는 암호화 스위트 알고리즘을 사용하지 않습니다.
      • Edge Router는 SNI를 지원하지만 클라이언트 애플리케이션이 서버 이름을 전송하지 않습니다.
    • tcpdump 출력의 메시지 4에는 아래와 같이 클라이언트 애플리케이션에서 지원하는 암호화 스위트 알고리즘이 나열됩니다.

    • Edge Router에서 지원하는 암호화 스위트 알고리즘 목록은 /opt/nginx/conf.d/0-default.conf 파일에 나열되어 있습니다. 이 예시에서 에지 라우터는 높은 암호화 스위트 알고리즘만 지원합니다.
    • 클라이언트 애플리케이션은 높은 암호화 스위트 알고리즘을 사용하지 않습니다. 이 불일치는 TLS/SSL 핸드셰이크 실패의 원인입니다.
    • 에지 라우터는 SNI를 지원하므로 tcpdump 출력의 메시지 4까지 아래로 스크롤하고 아래 그림과 같이 클라이언트 애플리케이션이 서버 이름을 올바르게 전송하고 있는지 확인합니다.


    • 이 이름이 유효하면 클라이언트 애플리케이션에서 사용하는 암호화 제품군 알고리즘이 에지 라우터에서 지원되지 않으므로 TLS/SSL 핸드셰이크 실패가 발생한 것으로 추론할 수 있습니다.

해상도

클라이언트가 서버에서 지원하는 암호화 스위트 알고리즘을 사용해야 합니다. 이전 진단 섹션에 설명된 문제를 해결하려면 JCE (Java Cryptography Extension) 패키지를 다운로드하고 설치한 후 자바 설치에 포함하여 높은 암호화 기술 스위트 알고리즘을 지원합니다.

잘못된 인증서

키 저장소/트러스트 저장소에 잘못된 인증서가 있는 경우 Apigee Edge의 수신 (노스바운드) 또는 발신 (남쪽바운드) 연결에서 TLS/SSL 핸드셰이크가 실패합니다. 북쪽 방면 및 남쪽 방면 연결 이해도 참고하세요.

문제가 북쪽 경계에 있는 경우 근본 원인에 따라 다른 오류 메시지가 표시될 수 있습니다.

다음 섹션에는 오류 메시지 예와 이 문제를 진단하고 해결하는 단계가 나와 있습니다.

오류 메시지

TLS/SSL 핸드셰이크 실패의 원인에 따라 다른 오류 메시지가 표시될 수 있습니다. 다음은 API 프록시를 호출할 때 표시될 수 있는 오류 메시지 샘플입니다.

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

가능한 원인

이 문제의 일반적인 원인은 다음과 같습니다.

원인 설명 문제 해결 단계를 수행할 수 있는 사용자
호스트 이름 불일치 URL에 사용된 호스트 이름과 라우터의 키 저장소에 있는 인증서가 일치하지 않습니다. 예를 들어 URL에 사용된 호스트 이름이 myorg.domain.com이지만 인증서의 CN에 CN=something.domain.com.인 호스트 이름이 있으면 불일치가 발생합니다.

 에지 프라이빗 및 퍼블릭 클라우드 사용자
불완전하거나 잘못된 인증서 체인 인증서 체인이 완전하지 않거나 올바르지 않습니다. Edge 프라이빗 및 퍼블릭 클라우드 사용자만 해당
서버 또는 클라이언트에서 전송한 만료되었거나 알 수 없는 인증서 북쪽 경계 또는 남쪽 경계 연결에서 만료되거나 알 수 없는 인증서를 서버 또는 클라이언트에서 전송합니다. Edge 프라이빗 클라우드 및 에지 퍼블릭 클라우드 사용자

호스트 이름 불일치

진단

  1. 다음 Edge 관리 API 호출에서 반환된 URL에 사용된 호스트 이름을 확인합니다. 
    curl -v https://myorg.domain.com/v1/getinfo
    예를 들면 다음과 같습니다. 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. 특정 키 저장소에 저장된 인증서에 사용된 CN을 가져옵니다. 다음 Edge 관리 API를 사용하여 인증서의 세부정보를 가져올 수 있습니다.
    1. 키 저장소의 인증서 이름 가져오기:

      Private Cloud 사용자인 경우 다음과 같이 Management API를 사용합니다.
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Public Cloud 사용자인 경우 다음과 같이 Management API를 사용합니다.
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. Edge 관리 API를 사용하여 키 저장소의 인증서 세부정보를 가져옵니다.

      Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Public Cloud 사용자인 경우:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

      샘플 인증서:

      "certInfo": [
    {
      "basicConstraints": "CA:FALSE",
      "expiryDate": 1456258950000,
      "isValid": "No",
      "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
      "publicKey": "RSA Public Key, 2048 bits",
      "serialNumber": "07:bc:a7:39:03:f1:56",
      "sigAlgName": "SHA1withRSA",
      "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
      "validFrom": 1358287055000,
      "version": 3
    },

      기본 인증서의 주체 이름에 something.domain.com.와 같은 CN이 있습니다.

      API 요청 URL에 사용된 호스트 이름 (위의 1단계 참고)과 인증서의 주체 이름이 일치하지 않기 때문에 TLS/SSL 핸드셰이크 실패가 발생합니다.

해상도

이 문제는 다음 두 가지 방법 중 하나로 해결할 수 있습니다.

  • 주체 CN에 와일드 카드 인증서가 포함된 인증서를 가져온 후 (아직 없는 경우) 새로운 전체 인증서 체인을 키 저장소에 업로드합니다. 예를 들면 다음과 같습니다. 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • 기존 주체 CN으로 인증서가 없는 경우 your-org를 사용합니다.your-domain를 주체 대체 이름으로 지정한 다음, 전체 인증서 체인을 키 저장소에 업로드합니다.

참조

키 저장소 및 트러스트 저장소

인증서 체인이 불완전하거나 잘못됨

진단

  1. 특정 키 저장소에 저장된 인증서에 사용된 CN을 가져옵니다. 다음 Edge 관리 API를 사용하여 인증서의 세부정보를 가져올 수 있습니다.
    1. 키 저장소의 인증서 이름 가져오기:

      Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Public Cloud 사용자인 경우:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. 키 저장소의 인증서 세부정보를 가져옵니다.

      Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Public Cloud 사용자인 경우:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. 인증서와 체인의 유효성을 검사하고 인증서 체인이 유효하고 완전한 인증서 체인인지 확인하기 위해 인증서 체인 작동 방식 문서에 제공된 가이드라인을 준수하는지 확인합니다. 키 저장소에 저장된 인증서 체인이 불완전하거나 잘못된 경우 TLS/SSL 핸드셰이크 실패가 표시됩니다.
    4. 다음 그래프는 중간 인증서와 루트 인증서가 일치하지 않는 잘못된 인증서 체인이 있는 샘플 인증서를 보여줍니다.

      5. 발급기관과 대상이 일치하지 않는 중간 인증서 및 루트 인증서 샘플


해상도

  1. 완전하고 유효한 인증서 체인이 포함된 인증서를 가져옵니다 (아직 없는 경우).
  2. 다음 openssl 명령어를 실행하여 인증서 체인이 올바르고 완전한지 확인합니다. 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. 검증된 인증서 체인을 키 저장소에 업로드합니다.

서버 또는 클라이언트에서 전송한 만료되었거나 알 수 없는 인증서

북쪽 경계 또는 남쪽 경계 연결에서 서버/클라이언트에서 잘못되거나 만료된 인증서를 보내면 다른 쪽 (서버/클라이언트)에서 인증서를 거부하여 TLS/SSL 핸드셰이크가 실패합니다.

진단

  1. 오류가 북쪽 경계 연결 또는 남쪽 경계 연결 중 어디에서 발생했는지 확인합니다. 이 판단에 대한 자세한 안내는 문제의 원인 확인을 참조하세요.
  2. tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
    • Private Cloud 사용자는 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 북쪽 경계 연결의 경우) 또는 메시지 프로세서 (발신 또는 남쪽 연결의 경우)일 수 있습니다. 1단계에서 결정한 정보에 따라 에지 라우터 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)일 수 있습니다.
    • 퍼블릭 클라우드 사용자는 에지 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)에서만 tcpdump 데이터를 수집할 수 있습니다.
    tcpdump -i any -s 0 host IP address -w File name
    tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
  3. Wireshark 또는 유사한 도구를 사용하여 tcpdump 데이터를 분석합니다.
  4. tcpdump 출력에서 확인 단계에서 인증서를 거부하는 호스트 (클라이언트 또는 서버)를 확인합니다.
  5. 데이터가 암호화되지 않은 경우 tcpdump 출력에서 반대쪽에서 전송된 인증서를 검색할 수 있습니다. 이 인증서가 트러스트 저장소에서 사용 가능한 인증서와 일치하는지 비교하는 데 유용합니다.
  6. 메시지 프로세서와 백엔드 서버 간의 SSL 통신을 위한 샘플 tcpdump를 검토합니다.

    인증서 알 수 없는 오류를 보여주는 샘플 tcpdump


    1. 메시지 프로세서 (클라이언트)는 메시지 #59에서 '클라이언트 Hello'를 백엔드 서버(서버)로 전송합니다.
    2. 백엔드 서버가 메시지 #61에서 메시지 프로세서에 'Server Hello'를 전송합니다.
    3. 사용된 프로토콜과 암호화 스위트 알고리즘을 상호 검증합니다.
    4. 백엔드 서버가 메시지 #68에서 Certificate 및 Server Hello Done 메시지를 메시지 프로세서에 보냅니다.
    5. 메시지 프로세서가 메시지 #70에 치명적 알림 "Description: Certificate Unknown"을 보냅니다.
    6. 메시지 #70을 자세히 살펴보면 아래와 같이 알림 메시지 외에는 추가 세부정보가 없습니다.


    7. 다음 그래픽과 같이 메시지 #68을 검토하여 백엔드 서버에서 전송한 인증서에 대한 세부정보를 가져옵니다.

    8. 백엔드 서버의 인증서와 전체 체인은 위 그림과 같이 '인증서' 섹션에서 모두 확인할 수 있습니다.
  7. 위의 예와 같이 라우터 (북쪽바운드) 또는 메시지 프로세서 (남쪽바운드)에서 인증서를 알 수 없는 경우 다음 단계를 따르세요.
    1. 특정 트러스트 저장소에 저장된 인증서와 체인을 가져옵니다. (라우터의 가상 호스트 구성과 메시지 프로세서의 대상 엔드포인트 구성을 참조하세요.) 다음 API를 사용하여 인증서의 세부정보를 가져올 수 있습니다.
      1. 트러스트 저장소의 인증서 이름을 가져옵니다. 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. 트러스트 저장소의 인증서 세부정보를 가져옵니다. 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
    2. 라우터 (노스바운드) 또는 메시지 프로세서 (남쪽 바운드)의 트러스트 저장소에 저장된 인증서가 클라이언트 애플리케이션 (북쪽 경계)이나 대상 서버 (남쪽 바운드)의 키 저장소에 저장된 인증서나 tcpdump 출력에서 가져온 인증서와 일치하는지 확인합니다. 일치하지 않으면 TLS/SSL 핸드셰이크 실패의 원인입니다.
  8. 클라이언트 애플리케이션 (노스바운드) 또는 대상 서버 (남쪽 바운드)에서 인증서를 알 수 없는 경우 다음 단계를 따르세요.
    1. 특정 키 저장소에 저장된 인증서에 사용된 전체 인증서 체인을 가져옵니다. 메시지 프로세서의 라우터 및 대상 엔드포인트 구성을 참조하세요. 다음 API를 사용하여 인증서의 세부정보를 가져올 수 있습니다.
      1. 키 저장소의 인증서 이름을 가져옵니다. 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      2. 키 저장소의 인증서 세부정보를 가져옵니다.
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    2. 라우터 (북쪽바운드) 또는 메시지 프로세서 (남쪽바운)의 키 저장소에 저장된 인증서가 클라이언트 애플리케이션 (북쪽바운드)이나 대상 서버 (남쪽바운드)의 트러스트 저장소 또는 tcpdump 출력에서 가져온 인증서와 일치하는지 확인합니다. 일치하지 않으면 SSL 핸드셰이크 실패의 원인입니다.
  9. 서버/클라이언트에서 보낸 인증서가 만료된 것으로 확인되면 수신 클라이언트/서버가 인증서를 거부하고 tcpdump에 다음과 같은 알림 메시지가 표시됩니다.

    알림 (수준: 치명적, 설명: 인증서가 만료됨)

  10. 해당 호스트의 키 저장소에 있는 인증서가 만료되었는지 확인합니다.

해상도

위 예시에서 확인된 문제를 해결하려면 유효한 백엔드 서버의 인증서를 메시지 프로세서의 trustore에 업로드합니다.

다음 표에는 문제의 원인에 따라 문제 해결 단계가 요약되어 있습니다.

원인 설명 해결 방법
만료된 인증서 NorthBound
  • 라우터의 키 저장소에 저장된 인증서가 만료되었습니다.
  • 클라이언트 애플리케이션의 키 저장소에 저장된 인증서가 만료되었습니다 (2방향 SSL).
 새 인증서와 전체 체인을 적절한 호스트의 키 저장소에 업로드합니다.
SouthBound
  • 대상 서버의 키 저장소에 저장된 인증서가 만료되었습니다.
  • 메시지 프로세서의 키 저장소에 저장된 인증서가 만료되었습니다 (양방향 SSL).
 새 인증서와 전체 체인을 적절한 호스트의 키 저장소에 업로드합니다.
알 수 없는 인증서 NorthBound
  • 클라이언트 애플리케이션의 트러스트 저장소에 저장된 인증서가 라우터의 인증서와 일치하지 않습니다.
  • 라우터의 트러스트 저장소에 저장된 인증서가 클라이언트 애플리케이션의 인증서 (2방향 SSL)와 일치하지 않습니다.
 적절한 호스트의 트러스트 저장소에 유효한 인증서를 업로드합니다.
SouthBound
  • 대상 서버의 트러스트 저장소에 저장된 인증서가 메시지 프로세서의 인증서와 일치하지 않습니다.
  • 메시지 프로세서의 트러스트 저장소에 저장된 인증서가 대상 서버의 인증서 (양방향 SSL)와 일치하지 않습니다.
 적절한 호스트의 트러스트 저장소에 유효한 인증서를 업로드합니다.

SNI 지원 서버

TLS/SSL 핸드셰이크 실패는 클라이언트가 SNI (서버 이름 표시)가 사용 설정된 서버와 통신하지만 클라이언트가 SNI를 사용 설정하지 않은 경우에 발생할 수 있습니다. 이는 Edge의 북쪽 방면 또는 남쪽 연결에서 발생할 수 있습니다.

먼저 사용 중인 서버의 호스트 이름과 포트 번호를 식별하고 SNI 사용 설정 여부를 확인해야 합니다.

SNI 지원 서버 식별

  1. openssl 명령어를 실행하고 아래와 같이 서버 이름을 전달하지 않고 관련 서버 호스트 이름 (에지 라우터 또는 백엔드 서버)에 연결해 봅니다. 
    openssl s_client -connect hostname:port
    인증서를 가져올 수 있으며 간혹 openssl 명령어에서 핸드셰이크 실패가 발생하는 경우가 있습니다.
    CONNECTED(00000003)
9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593
  2. openssl 명령어를 실행하고 아래와 같이 서버 이름을 전달하여 관련 서버 호스트 이름(에지 라우터 또는 백엔드 서버)에 연결을 시도합니다. 
    openssl s_client -connect hostname:port -servername hostname
  3. 1단계에서 핸드셰이크 실패가 발생하거나 1단계와 2단계에서 다른 인증서를 받으면 지정된 서버가 SNI가 사용 설정된 것입니다.

서버에 SNI가 사용 설정된 것을 확인한 후 아래 단계에 따라 TLS/SSL 핸드셰이크 실패가 클라이언트가 SNI 서버와 통신할 수 없어 발생한 것인지 확인할 수 있습니다.

진단

  1. 오류가 북쪽 경계 연결 또는 남쪽 경계 연결 중 어디에서 발생했는지 확인합니다. 이 판단에 대한 자세한 안내는 문제의 원인 확인을 참조하세요.
  2. tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
    • Private Cloud 사용자는 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 북쪽 경계 연결의 경우) 또는 메시지 프로세서 (발신 또는 남쪽 연결의 경우)일 수 있습니다. 1단계에서 결정한 정보에 따라 에지 라우터 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)일 수 있습니다.
    • 퍼블릭 클라우드 사용자는 에지 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 북쪽 연결의 경우) 또는 백엔드 서버(발신 또는 남쪽 연결의 경우)에서만 tcpdump 데이터를 수집할 수 있습니다.
    tcpdump -i any -s 0 host IP address -w File name
    tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
  3. Wireshark 또는 유사한 도구를 사용하여 tcpdump 출력을 분석합니다.
  4. 다음은 Wireshark를 사용한 tcpdump의 샘플 분석입니다.
    1. 이 예시에서는 에지 메시지 프로세서와 백엔드 서버 (남쪽 연결) 간에 TLS/SSL 핸드셰이크가 발생했습니다.
    2. 아래 tcpdump 출력의 메시지 4는 메시지 프로세서 (소스)가 백엔드 서버 (대상)로 'Client Hello' 메시지를 보냈음을 보여줍니다.

    3. '클라이언트 Hello' 메시지를 선택하면 메시지 프로세서가 TLSv1.2 프로토콜을 사용 중임을 보여줍니다.

    4. 메시지 4는 백엔드 서버가 메시지 프로세서의 'Client Hello' 메시지를 확인했음을 보여줍니다.
    5. 백엔드 서버가 즉시 메시지 프로세서에 Fatal Alert : Handshake Failure를 전송합니다 (메시지 #5). 즉, TLS/SSL 핸드셰이크가 실패하고 연결이 종료됩니다.
    6. 메시지 6을 검토하여 다음 정보를 확인합니다.
      • 백엔드 서버는 TLSv1.2 프로토콜을 지원합니다. 즉, 메시지 프로세서와 백엔드 서버 간에 프로토콜이 일치함을 의미합니다.
      • 하지만 백엔드 서버는 아래 그림과 같이 여전히 Fatal Alert: Handshake Failure를 메시지 프로세서에 전송합니다.

    7. 이 오류는 다음 이유 중 하나로 인해 발생할 수 있습니다.
      • 메시지 프로세서가 백엔드 서버에서 지원하는 암호화 스위트 알고리즘을 사용하지 않습니다.
      • 백엔드 서버가 SNI를 사용 설정했지만 클라이언트 애플리케이션이 서버 이름을 전송하지 않습니다.
    8. tcpdump 출력의 메시지 #3 (클라이언트 Hello)을 자세히 검토합니다. 아래와 같이 Extension: server_name이 누락되었습니다.

    9. 이는 메시지 프로세서가 server_name을 SNI 지원 백엔드 서버로 전송하지 않았음을 확인합니다.
    10. 이는 TLS/SSL 핸드셰이크 실패의 원인이며 백엔드 서버가 메시지 프로세서에 Fatal Alert: Handshake Failure를 보내는 이유입니다.
  5. 메시지 프로세서에서 system.properties의 jsse.enableSNIExtension property가 false로 설정되어 있는지 확인하여 메시지 프로세서가 SNI 지원 서버와 통신할 수 없도록 설정되어 있는지 확인합니다.

해상도

다음 단계를 수행하여 메시지 프로세서가 SNI 지원 서버와 통신할 수 있도록 합니다.

  1. /opt/apigee/customer/application/message-processor.properties 파일을 만듭니다 (파일이 아직 없는 경우).
  2. 이 파일에 conf_system_jsse.enableSNIExtension=true 줄을 추가합니다.
  3. 이 파일의 소유자를 apigee:apigee(으)로 chown: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. 메시지 프로세서를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. 메시지 프로세서가 두 개 이상 있으면 모든 메시지 프로세서에서 1~4단계를 반복합니다.

TLS/SSL 핸드셰이크 실패의 원인을 파악하여 문제를 해결할 수 없거나 추가 지원이 필요한 경우 Apigee Edge 지원팀에 문의하세요. 문제에 대한 전체 세부정보를 tcpdump 출력과 함께 공유합니다.