TLS/SSL 핸드셰이크 실패

<ph type="x-smartling-placeholder"></ph> 현재 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

가능한 원인

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

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

TLS/SSL 핸드셰이크가 성공하면 TLS/SSL 클라이언트와 서버가 각각 안전하게 보호할 수 있습니다 그렇지 않고 TLS/SSL 핸드셰이크 실패가 발생하면 연결이 종료되고 클라이언트가 503 Service Unavailable 오류가 수신됩니다.

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

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

프로토콜 불일치

TLS/SSL 핸드셰이크 실패는 클라이언트에서 사용하는 프로토콜을 서버에 연결할 수 있습니다. 참고 항목 <ph type="x-smartling-placeholder"></ph> 북쪽 경계 및 남쪽 경계 연결 이해

진단

  1. 오류가 북쪽 또는 southbound 연결. 이렇게 하는 방법에 대한 결정을 내리고 <ph type="x-smartling-placeholder"></ph> 문제의 원인 판단.
  2. 먼저 <ph type="x-smartling-placeholder"></ph> tcpdump 유틸리티를 사용하여 추가 정보를 수집합니다. <ph type="x-smartling-placeholder">
      </ph>
    • Private Cloud 사용자인 경우 tcpdump 데이터를 수집하고 저장하는 곳입니다. 클라이언트는 클라이언트 앱이 될 수 있습니다 (수신, 또는 노스바운드 연결) 또는 메시지 프로세서 (발신 또는 남쪽 연결용) 서버는 에지 라우터( 또는 백엔드 서버) 1단계에서 결정된 내용을 기반으로 할 수 있습니다.
    • 퍼블릭 클라우드 사용자인 경우 tcpdump 클라이언트 앱 (수신 연결 또는 노스바운드 연결의 경우) 또는 백엔드 서버의 데이터만 (발신 또는 남바운드 연결의 경우) 에지 라우터나 메시지 프로세서에 액세스할 수 없습니다.
    tcpdump -i any -s 0 host IP address -w File name
    드림 다음 페이지를 참조하세요. tcpdump 자세한 내용은 tcpdump 명령어와 함께 사용하면 됩니다
  3. Wireshark 도구를 사용하여 tcpdump 데이터 분석 또는 유사한 도구를 사용할 수 있습니다.
  4. 이 슬라이드에는 <ph type="x-smartling-placeholder"></ph> tcpdump에서 사용할 수 있습니다. <ph type="x-smartling-placeholder">
      </ph>
    • 이 예에서는 메시지 프로세서와 메시지 서버 사이에 TLS/SSL 핸드셰이크 실패가 발생했습니다. 백엔드 서버 (발신 또는 남바운드 연결)에 연결할 수 있습니다.
    • 아래 tcpdump 출력의 메시지 #4는 메시지 프로세서 (소스)가 "고객 안녕하세요." 백엔드 서버 (대상)로 전송됩니다.

    • Client Hello 메시지를 선택하면 메시지 프로세서가 TLSv1.2 프로토콜을 사용합니다.

    • 메시지 #5는 백엔드 서버가 'Client Hello'를 승인했음을 보여줍니다. 메시지 발신자: 메시지 프로세서의 일종입니다.
    • 백엔드 서버에서 즉시 Fatal Alert : Close Notify를 메시지 프로세서 (메시지 #6). 즉, TLS/SSL 핸드셰이크가 실패했으며 연결이 닫아야 합니다.

    • 메시지 #6을 좀 더 살펴보면 TLS/SSL 핸드셰이크 실패의 원인은 백엔드 서버는 아래와 같이 TLSv1.0 프로토콜만 지원합니다.

    • 메시지 프로세서가 사용하는 프로토콜과 백엔드 서버에서 다음과 같은 메시지를 보냈습니다. 치명적 경고 메시지: 닫기 알림을 선택합니다.

해상도

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

  1. TLSv1.2 프로토콜을 지원하도록 백엔드 서버를 업그레이드합니다. 이 방법은 프로토콜 TLSv1.2가 더 안전합니다.
  2. 어떤 이유로든 백엔드 서버를 즉시 업그레이드할 수 없는 경우 메시지 프로세서가 TLSv1.0 프로토콜을 사용하여 백엔드 서버를 초기화하려면 다음 단계를 따르세요. <ph type="x-smartling-placeholder">
      </ph>
    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. GCP 콘솔에서 <ph type="x-smartling-placeholder"></ph> 대상 서버를 선택한 다음 <ph type="x-smartling-placeholder"></ph> 이 관리 API를 사용하여 특정 프로토콜에서 프로토콜을 TLSv1.0으로 설정할 수 있습니다. 대상 서버 구성을 설정합니다.

암호화 불일치

클라이언트에서 사용하는 암호화 스위트 알고리즘이 Apigee Edge의 수신 (북쪽) 또는 발신 (남쪽) 연결에서 서버에서 지원합니다. 도 참조하세요. 북쪽 경계 및 남쪽 경계 연결 이해

진단

  1. 오류가 발생한 위치 확인 북쪽 또는 남쪽 연결 이러한 판단에 대한 자세한 안내는 다음을 참조하세요. 결정 문제의 근원이라고 할 수 있습니다.
  2. 먼저 <ph type="x-smartling-placeholder"></ph> tcpdump 유틸리티를 사용하여 추가 정보를 수집합니다. <ph type="x-smartling-placeholder">
      </ph>
    • Private Cloud 사용자인 경우 tcpdump 데이터를 수집하고 저장하는 곳입니다. 클라이언트는 클라이언트 앱이 될 수 있습니다 (수신, 또는 노스바운드 연결) 또는 메시지 프로세서 (발신 또는 남쪽 연결용) 서버는 에지 라우터( 또는 백엔드 서버) 1단계에서 결정된 내용을 기반으로 할 수 있습니다.
    • 퍼블릭 클라우드 사용자인 경우 tcpdump 클라이언트 앱 (수신 연결 또는 노스바운드 연결의 경우) 또는 백엔드 서버의 데이터만 (발신 또는 남바운드 연결의 경우) 에지 라우터나 메시지 프로세서에 액세스할 수 없습니다.
    tcpdump -i any -s 0 host IP address -w File name
    드림 다음 페이지를 참조하세요. tcpdump 명령어 사용에 대한 자세한 내용을 확인하세요.tcpdump 명령어
  3. Wireshark 도구를 사용하여 tcpdump 데이터 분석 또는 다른 익숙한 도구를 사용할 수도 있습니다.
  4. 다음은 Wireshark를 사용한 tcpdump 출력의 샘플 분석입니다. <ph type="x-smartling-placeholder">
      </ph>
    • 이 예에서는 클라이언트 애플리케이션과 에지 라우터 (북쪽 연결) 에지에서 tcpdump 출력이 수집되었습니다. 라우터에 연결합니다

    • 아래 tcpdump 출력의 메시지 4는 클라이언트 애플리케이션 (소스)이 "고객 안녕하세요." 메시지를 에지 라우터 (대상)에 보냅니다.

    • Client Hello 메시지를 선택하면 클라이언트 애플리케이션이 TLSv1.2 프로토콜

    • 메시지 #5는 에지 라우터가 '클라이언트 Hello'를 확인했음을 보여줍니다. 메시지 발신자: 클라이언트 애플리케이션에서 실행합니다
    • Edge 라우터는 즉시 Fatal Alert : Handshake Failure를 전송하여 클라이언트 애플리케이션 (메시지 #6) 즉, TLS/SSL 핸드셰이크가 실패했고 연결이 영업이 종료됩니다.
    • 메시지 #6을 자세히 살펴보면 다음과 같은 정보를 확인할 수 있습니다. <ph type="x-smartling-placeholder">
        </ph>
      • 에지 라우터는 TLSv1.2 프로토콜을 지원합니다. 이는 프로토콜이 에지 라우터 간의 연결을 제공합니다

      • 하지만 Edge 라우터는 여전히 Fatal Alert: Handshake(치명적 경고: 핸드셰이크)'를 Failure가 발생합니다.

    • 이 오류는 다음 문제 중 하나로 인해 발생할 수 있습니다. <ph type="x-smartling-placeholder">
        </ph>
      • 클라이언트 애플리케이션이 에지 라우터
      • 에지 라우터에 SNI가 사용 설정되어 있지만 클라이언트 애플리케이션에서 있습니다.
    • tcpdump 출력의 메시지 4에는 클라이언트에서 지원하는 암호화 스위트 알고리즘이 나열됩니다. 애플리케이션을 실행합니다.

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


    • 이 이름이 유효하면 TLS/SSL 핸드셰이크 실패가 클라이언트 애플리케이션에서 사용하는 암호화 스위트 알고리즘을 에지 라우터를 통해 연결할 수 있습니다

해상도

클라이언트가 암호화 스위트 알고리즘을 사용하는지 확인해야 합니다. 서버에서 지원해야 합니다 이전 도움말에서 설명한 문제를 해결하려면 다음 단계를 따르세요. 진단 섹션에서 다음을 다운로드하여 설치합니다. <ph type="x-smartling-placeholder"></ph> Java Cryptography Extension (JCE) 패키지를 만들고 Java 높은 암호화 스위트 알고리즘을 지원합니다.

잘못된 인증서

TLS/SSL 핸드셰이크 실패는 keystore/truststore에 잘못된 인증서가 있는 경우 발생합니다. Apigee Edge의 수신 (북쪽) 또는 발신 (남쪽) 연결에서 가능합니다. 참고 항목 <ph type="x-smartling-placeholder"></ph> 북쪽 경계 및 남쪽 경계 연결 이해

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

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

오류 메시지

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 프라이빗 및 퍼블릭 클라우드 사용자만 해당
인증서가 만료되었거나 알 수 없는 서버 또는 클라이언트 서버나 클라이언트가 북쪽이나 서로 통신하는 것입니다 Edge 프라이빗 클라우드 및 에지 퍼블릭 클라우드 사용자

호스트 이름 불일치

진단

  1. 다음 Edge 관리 API 호출에서 반환된 URL에 사용된 호스트 이름을 확인하세요. 
    curl -v https://myorg.domain.com/v1/getinfo
     드림 예를 들면 다음과 같습니다. 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. 특정 키 저장소에 저장된 인증서에 사용된 CN을 가져옵니다. 이 다음 에지 관리 API를 사용하여 인증서의 세부정보를 가져옵니다. <ph type="x-smartling-placeholder">
      </ph>
    1. <ph type="x-smartling-placeholder"></ph> 키 저장소에서 인증서 이름 가져오기:
      <ph type="x-smartling-placeholder">
      </ph> Private Cloud 사용자인 경우 다음과 같이 Management API를 사용합니다.
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
       드림 퍼블릭 클라우드 사용자인 경우 다음과 같이 Management API를 사용합니다.
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. <ph type="x-smartling-placeholder"></ph> Edge management API를 사용하여 키 저장소의 인증서 세부정보를 가져옵니다.

      Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      퍼블릭 클라우드 사용자인 경우:
      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.

      API 요청 URL에 사용된 호스트 이름 (위의 1단계 참고)과 제목이 이름이 일치하지 않으면 TLS/SSL 핸드셰이크 실패가 발생합니다.

해상도

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

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

참조

키 저장소 및 Truststores

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

진단

  1. 특정 키 저장소에 저장된 인증서에 사용된 CN을 가져옵니다. 이 다음 에지 관리 API를 사용하여 인증서의 세부정보를 가져옵니다. <ph type="x-smartling-placeholder">
      </ph>
    1. <ph type="x-smartling-placeholder"></ph> 키 저장소에서 인증서 이름 가져오기:
      <ph type="x-smartling-placeholder">
      </ph> Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      퍼블릭 클라우드 사용자인 경우:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. <ph type="x-smartling-placeholder"></ph> 키 저장소의 인증서 세부정보를 가져옵니다.
      <ph type="x-smartling-placeholder">
      </ph> Private Cloud 사용자인 경우:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      퍼블릭 클라우드 사용자인 경우:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. 인증서와 인증서 체인의 유효성을 검사하고 인증서를 준수하는지 확인 가이드라인에 나와 있는 가이드라인에 따라 <ph type="x-smartling-placeholder"></ph> 인증서 체인이 유효하고 완전한지 확인하기 위한 작동 방식 지정할 수도 있습니다 키 저장소에 저장된 인증서 체인이 불완전하거나 유효하지 않은 경우 TLS/SSL 핸드셰이크가 있습니다
    4. 다음 그래프는 유효하지 않은 인증서 체인이 있는 샘플 인증서를 보여줍니다. 여기서 중간 인증서와 루트 인증서가 일치하지 않는 경우:

      5. 샘플 중간 인증서 및 루트 인증서는 제목이 일치하지 않음


해상도

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

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

서버/클라이언트가 북쪽에서 잘못되거나 만료된 인증서를 보내는 경우 다른 쪽 끝 (서버/클라이언트)에서 인증서를 거부합니다. TLS/SSL 핸드셰이크 실패를 초래합니다

진단

  1. 오류가 북쪽 또는 southbound 연결. 이렇게 하는 방법에 대한 결정을 내리고 <ph type="x-smartling-placeholder"></ph> 문제의 원인 판단.
  2. 먼저 <ph type="x-smartling-placeholder"></ph> tcpdump 유틸리티를 사용하여 추가 정보를 수집합니다. <ph type="x-smartling-placeholder">
      </ph>
    • Private Cloud 사용자인 경우 tcpdump 데이터를 수집하고 저장하는 곳입니다. 클라이언트는 클라이언트 앱이 될 수 있습니다 (수신, 또는 노스바운드 연결) 또는 메시지 프로세서 (발신 또는 남쪽 연결용) 서버는 에지 라우터( 또는 백엔드 서버) 1단계에서 결정된 내용을 기반으로 할 수 있습니다.
    • 퍼블릭 클라우드 사용자인 경우 tcpdump 클라이언트 앱 (수신 연결 또는 노스바운드 연결의 경우) 또는 백엔드 서버의 데이터만 (발신 또는 남바운드 연결의 경우) 에지 라우터나 메시지 프로세서에 액세스할 수 없습니다.
    tcpdump -i any -s 0 host IP address -w File name
    드림 다음 페이지를 참조하세요. tcpdump 명령어 사용에 대한 자세한 내용을 확인하세요.tcpdump 명령어
  3. tcpdump Wireshark 또는 사용할 수 있습니다.
  4. tcpdump 출력에서 다음을 거부하는 호스트 (클라이언트 또는 서버)를 결정합니다. 인증서를 생성할 수 있습니다.
  5. 다음과 같은 경우 tcpdump 출력에서 다른 쪽에서 전송된 인증서를 검색할 수 있습니다. 암호화되지 않습니다 이 인증서가 인증서를 신뢰해야 합니다
  6. 메시지 프로세서와 메시지 프로세서 간의 SSL 통신에 대해서는 샘플 tcpdump를 검토합니다. 백엔드 서버입니다

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


    1. 메시지 프로세서 (클라이언트)는 "Client Hello"를 전송합니다. 백엔드 서버로 (서버)가 있습니다.
    2. 백엔드 서버에서는 'Server Hello'를 메시지 프로세서로 전달되며 #61.
    3. 또한 사용되는 프로토콜 및 암호화 스위트 알고리즘을 상호 검증합니다.
    4. 백엔드 서버는 메시지 #68의 메시지 프로세서입니다.
    5. 메시지 프로세서가 치명적인 경고 "설명: 인증서 알 수 없음'이라는 오류가 표시됩니다.
    6. 메시지 #70을 더 자세히 살펴본 결과, 다른 세부정보는 없습니다. 경고 메시지가 표시됩니다.


    7. 68 메시지를 검토하여 백엔드에서 보낸 인증서에 대한 세부정보를 확인하세요. Cloud CDN을 사용 설정합니다

    8. 백엔드 서버의 인증서 및 전체 체인을 모두 사용할 수 있습니다. '인증서' 아래에 섹션을 포함할 수 있습니다.
  7. 라우터 (북쪽) 또는 메시지 프로세서 (남쪽 방향)를 설정한 다음 단계: <ph type="x-smartling-placeholder">
      </ph>
    1. 특정 트러스트 저장소에 저장된 인증서와 인증서 체인을 가져옵니다. ( 라우터의 가상 호스트 구성과 대상 엔드포인트 구성에 대한 메시지 프로세서). 다음 API를 사용하여 인증서: <ph type="x-smartling-placeholder">
        </ph>
      1. <ph type="x-smartling-placeholder"></ph> 트러스트 저장소에서 인증서 이름을 가져옵니다. 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. <ph type="x-smartling-placeholder"></ph> 트러스트 저장소에서 인증서 세부정보를 가져옵니다. 
        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. 클라이언트 애플리케이션 (북쪽)에서 인증서를 알 수 없는 것으로 확인된 경우 대상 서버 (남쪽 바운드)를 로드하려면 다음 단계를 따르세요. <ph type="x-smartling-placeholder">
      </ph>
    1. 특정 인증서에 저장된 인증서에 사용된 전체 인증서 체인을 keystore. (라우터 및 대상 엔드포인트의 가상 호스트 구성 참조 구성). 다음 API를 사용하여 인증서 세부정보: <ph type="x-smartling-placeholder">
        </ph>
      1. <ph type="x-smartling-placeholder"></ph> 키 저장소에서 인증서 이름을 가져옵니다. 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      2. <ph type="x-smartling-placeholder"></ph> 키 저장소의 인증서 세부정보를 가져옵니다.
        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 <ph type="x-smartling-placeholder">
    </ph>
  • 라우터의 키 저장소에 저장된 인증서가 만료되었습니다.
  • 클라이언트 애플리케이션의 키 저장소에 저장된 인증서가 만료되었습니다 (양방향). SSL).
 새 인증서와 인증서의 전체 체인을 적절한 키 저장소의 키 저장소에 업로드합니다. 호스팅합니다
SouthBound <ph type="x-smartling-placeholder">
    </ph>
  • 대상 서버의 키 저장소에 저장된 인증서가 만료되었습니다.
  • 메시지 프로세서의 키 저장소에 저장된 인증서가 만료되었습니다 (양방향). SSL).
 새 인증서와 인증서의 전체 체인을 적절한 키 저장소의 키 저장소에 업로드합니다. 호스팅합니다
알 수 없는 인증서 NorthBound <ph type="x-smartling-placeholder">
    </ph>
  • 클라이언트 애플리케이션의 트러스트 저장소에 저장된 인증서가 일치하지 않습니다. 라우터의 인증서입니다.
  • 라우터의 트러스트 저장소에 저장된 인증서가 클라이언트와 일치하지 않습니다. 인증서 (양방향 SSL)를 사용합니다.
 유효한 인증서를 적절한 호스트의 truststore에 업로드합니다.
SouthBound <ph type="x-smartling-placeholder">
    </ph>
  • 대상 서버의 트러스트 저장소에 저장된 인증서가 메시지 프로세서의 인증서입니다.
  • 메시지 프로세서의 트러스트 저장소에 저장된 인증서가 일치하지 않습니다. 대상 서버의 인증서 (양방향 SSL)를 전송합니다.
 유효한 인증서를 적절한 호스트의 truststore에 업로드합니다.

SNI 사용 설정됨 서버

클라이언트가 서버와 통신할 때 TLS/SSL 핸드셰이크 실패가 발생할 수 있습니다. 이름 표시 (SNI) 사용 설정됨 서버에 SNI가 사용 설정되어 있지 않습니다. 이는 북쪽이나 북쪽에서 또는 남쪽 방면 연결을 설정할 수도 있습니다

먼저 사용 중인 서버의 호스트 이름과 포트 번호를 식별하고 SNI의 사용 설정 여부에 따라 달라집니다

SNI 지원 서버 식별

  1. openssl 명령어를 실행하고 관련 서버 호스트 이름 (Edge)에 연결을 시도합니다. 라우터 또는 백엔드 서버)를 서버 이름을 전달하지 않음으로 설정합니다. 
    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단계에서 다른 인증서를 받은 경우 지정된 서버에 SNI가 사용 설정되어 있음을 나타냅니다.

서버가 SNI를 사용하는 것으로 확인되면 다음 단계를 따르세요. TLS/SSL 핸드셰이크 실패가 클라이언트가 다른 네트워크와 통신할 수 없어 SNI 서버에 연결합니다

진단

  1. 오류가 북쪽 또는 southbound 연결. 이렇게 하는 방법에 대한 결정을 내리고 <ph type="x-smartling-placeholder"></ph> 문제의 원인 판단.
  2. 먼저 <ph type="x-smartling-placeholder"></ph> tcpdump 유틸리티를 사용하여 추가 정보를 수집합니다. <ph type="x-smartling-placeholder">
      </ph>
    • Private Cloud 사용자인 경우 tcpdump 데이터를 수집하고 저장하는 곳입니다. 클라이언트는 클라이언트 앱이 될 수 있습니다 (수신, 또는 노스바운드 연결) 또는 메시지 프로세서 (발신 또는 남쪽 연결용) 서버는 에지 라우터( 또는 백엔드 서버) 1단계에서 결정된 내용을 기반으로 할 수 있습니다.
    • 퍼블릭 클라우드 사용자인 경우 tcpdump 클라이언트 앱 (수신 연결 또는 노스바운드 연결의 경우) 또는 백엔드 서버의 데이터만 (발신 또는 남바운드 연결의 경우) 에지 라우터나 메시지 프로세서에 액세스할 수 없습니다.
    tcpdump -i any -s 0 host IP address -w File name
    드림 자세한 내용은 <ph type="x-smartling-placeholder"></ph> tcpdump 명령어 사용에 대한 자세한 내용을 확인하세요.tcpdump 명령어
  3. Wireshark 또는tcpdump 사용할 수 있습니다.
  4. 다음은 Wireshark를 사용한 tcpdump 분석 샘플입니다. <ph type="x-smartling-placeholder">
      </ph>
    1. 이 예시에서는 TLS/SSL 핸드셰이크 실패가 프로세서 및 백엔드 서버 (남쪽 연결)
    2. 아래 tcpdump 출력의 메시지 4는 메시지 프로세서 (소스)가 'Client Hello' 백엔드 서버 (대상)로 전송됩니다.

    3. 'Client Hello' 선택 메시지가 프로세서가 TLSv1.2 프로토콜을 사용하고 있습니다.

    4. 메시지 4는 백엔드 서버가 'Client Hello'를 승인했음을 보여줍니다. 메시지 전송됩니다.
    5. 백엔드 서버는 즉시 치명적인 알림 : 핸드셰이크 Failure(메시지 프로세서)입니다(메시지 #5). 즉, TLS/SSL 핸드셰이크는 실패하면 연결이 종료됩니다.
    6. 6번 메시지를 검토하여 다음 정보를 확인하세요. <ph type="x-smartling-placeholder">
        </ph>
      • 백엔드 서버는 TLSv1.2 프로토콜을 지원합니다. 이것은 프로토콜이 일치하는 것을 확인할 수 있습니다.
      • 하지만 백엔드 서버는 여전히 Fatal Alert: Handshake '실패'를 아래 그림과 같이 메시지 프로세서에 전달합니다.

    7. 이 오류는 다음 이유 중 하나로 인해 발생할 수 있습니다. <ph type="x-smartling-placeholder">
        </ph>
      • 메시지 프로세서는 백엔드 서버입니다
      • 백엔드 서버에 SNI가 사용 설정되어 있지만 클라이언트 애플리케이션에서 데이터를 전송하지 않습니다. 확인할 수 있습니다
    8. tcpdump 출력에서 메시지 #3 (Client Hello)을 자세히 검토합니다. Note that the 아래와 같이 확장 프로그램: server_name이 누락되었습니다.

    9. 이것은 메시지 프로세서가 server_name을 SNI 지원 백엔드 서버로 전달합니다.
    10. TLS/SSL 핸드셰이크 실패의 원인과 백엔드가 서버가 Fatal Alert: Handshake Failure를 메시지로 보냅니다. 프로세서.
  5. 다음에서 jsse.enableSNIExtension property이 메시지 프로세서에서 system.properties를 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 출력