Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

TLS/SSL 핸드셰이크 실패

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info

증상

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

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

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

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

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

프로토콜 불일치

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

진단

오류가 northbound 또는 southbound 연결에서 발생했는지 확인합니다. 이 결정을 내리는 방법에 관한 자세한 내용은 문제의 소스 확인을 참고하세요.
tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
- 프라이빗 클라우드 사용자인 경우 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 업스트림 연결의 경우) 또는 메시지 프로세서 (발신 또는 다운스트림 연결의 경우)일 수 있습니다. 서버는 1단계에서 결정한 내용에 따라 에지 라우터 (인바운드 또는 북바운드 연결용) 또는 백엔드 서버(아웃바운드 또는 사우스바운드 연결용)일 수 있습니다.
- 공개 클라우드 사용자인 경우 Edge 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 업스트림 연결용) 또는 백엔드 서버(발신 또는 다운스트림 연결용)에서만 tcpdump 데이터를 수집할 수 있습니다.
```
tcpdump -i any -s 0 host IP address -w File name
```
tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
Wireshark 도구 또는 유사한 도구를 사용하여 tcpdump 데이터를 분석합니다.
다음은 Wireshark를 사용하여 tcpdump를 분석한 샘플입니다.
- 이 예에서는 메시지 프로세서와 백엔드 서버 (발신 또는 남쪽 연결) 간에 TLS/SSL 핸드셰이크 실패가 발생했습니다.
- 아래 tcpdump 출력의 메시지 #4는 메시지 프로세서 (소스)가 백엔드 서버 (대상)에 'Client Hello' 메시지를 보냈음을 보여줍니다.
- Client Hello 메시지를 선택하면 아래와 같이 메시지 프로세서가 TLSv1.2 프로토콜을 사용하고 있음을 보여줍니다.
- 메시지 #5는 백엔드 서버가 메시지 프로세서의 'Client Hello' 메시지를 확인했음을 보여줍니다.
- 백엔드 서버는 즉시 메시지 프로세서에 심각한 알림 : 닫기 알림을 전송합니다 (메시지 #6). 이는 TLS/SSL 핸드셰이크가 실패했으며 연결이 닫힐 것임을 의미합니다.
- 메시지 #6을 자세히 살펴보면 TLS/SSL 핸드셰이크 실패의 원인이 백엔드 서버가 아래와 같이 TLSv1.0 프로토콜만 지원하기 때문인 것으로 나타납니다.
- 메시지 프로세서와 백엔드 서버에서 사용하는 프로토콜이 일치하지 않기 때문에 백엔드 서버에서 심각한 알림 메시지: 닫기 알림 메시지를 전송했습니다.

해상도

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

TLSv1.2 프로토콜을 지원하도록 백엔드 서버를 업그레이드합니다. 프로토콜 TLSv1.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 핸드셰이크 실패가 표시될 수 있습니다. Northbound 및 Southbound 연결 이해도 참고하세요.

진단

오류가 northbound 또는 southbound 연결에서 발생했는지 확인합니다. 이 결정을 내리는 방법에 관한 자세한 내용은 문제의 소스 확인을 참고하세요.
tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
- 프라이빗 클라우드 사용자인 경우 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 업스트림 연결의 경우) 또는 메시지 프로세서 (발신 또는 다운스트림 연결의 경우)일 수 있습니다. 서버는 1단계에서 결정한 내용에 따라 에지 라우터 (인바운드 또는 업스트림 연결용) 또는 백엔드 서버(아웃바운드 또는 다운스트림 연결용)일 수 있습니다.
- 공개 클라우드 사용자인 경우 Edge 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 업스트림 연결용) 또는 백엔드 서버(발신 또는 다운스트림 연결용)에서만 tcpdump 데이터를 수집할 수 있습니다.
```
tcpdump -i any -s 0 host IP address -w File name
```
tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
Wireshark 도구 또는 익숙한 다른 도구를 사용하여 tcpdump 데이터를 분석합니다.
다음은 Wireshark를 사용한 tcpdump 출력의 샘플 분석입니다.
- 이 예에서는 클라이언트 애플리케이션과 Edge 라우터 (북바운드 연결) 간에 TLS/SSL 핸드셰이크 실패가 발생했습니다. tcpdump 출력은 Edge 라우터에서 수집되었습니다.
- 아래 tcpdump 출력의 메시지 #4는 클라이언트 애플리케이션 (소스)이 Edge 라우터 (대상)에 'Client Hello' 메시지를 보냈음을 보여줍니다.
- Client Hello 메시지를 선택하면 클라이언트 애플리케이션이 TLSv1.2 프로토콜을 사용하고 있음을 확인할 수 있습니다.
- 메시지 #5는 Edge 라우터가 클라이언트 애플리케이션의 'Client Hello' 메시지를 승인했음을 보여줍니다.
- Edge 라우터는 즉시 클라이언트 애플리케이션에 심각한 알림 : 핸드셰이크 실패를 전송합니다 (메시지 #6). 이는 TLS/SSL 핸드셰이크가 실패하고 연결이 닫힌다는 의미입니다.
- 메일 #6을 자세히 살펴보면 다음 정보가 표시됩니다.
  - Edge Router는 TLSv1.2 프로토콜을 지원합니다. 이는 클라이언트 애플리케이션과 Edge 라우터 간에 프로토콜이 일치함을 의미합니다.
  - 하지만 Edge 라우터는 아래 스크린샷과 같이 클라이언트 애플리케이션에 심각한 알림: 핸드셰이크 실패를 전송합니다.
- 이 오류는 다음 문제 중 하나로 인해 발생할 수 있습니다.
  - 클라이언트 애플리케이션이 Edge 라우터에서 지원하는 암호화 스위트 알고리즘을 사용하지 않습니다.
  - Edge 라우터는 SNI가 사용 설정되어 있지만 클라이언트 애플리케이션이 서버 이름을 전송하지 않습니다.
- tcpdump 출력의 메시지 #4에는 클라이언트 애플리케이션에서 지원하는 암호화 스위트 알고리즘이 나열됩니다(아래 참고).
- Edge 라우터에서 지원하는 암호화 스위트 알고리즘 목록은 /opt/nginx/conf.d/0-default.conf 파일에 나열되어 있습니다. 이 예에서 Edge Router는 High Encryption 암호화 스위트 알고리즘만 지원합니다.
- 클라이언트 애플리케이션이 고도 암호화 암호화 스위트 알고리즘을 사용하지 않습니다. 이 불일치가 TLS/SSL 핸드셰이크 실패의 원인입니다.
- Edge 라우터에 SNI가 사용 설정되어 있으므로 tcpdump 출력에서 메시지 #4로 스크롤하고 아래 그림과 같이 클라이언트 애플리케이션이 서버 이름을 올바르게 전송하는지 확인합니다.
- 이 이름이 유효한 경우 클라이언트 애플리케이션에서 사용하는 암호화 스위트 알고리즘이 Edge 라우터에서 지원되지 않기 때문에 TLS/SSL 핸드셰이크 실패가 발생한 것으로 추론할 수 있습니다.

해상도

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

잘못된 인증서

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

문제가 업스트림인 경우 기본 원인에 따라 다른 오류 메시지가 표시될 수 있습니다.

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

오류 메시지

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 Private 및 Public Cloud 사용자
불완전하거나 잘못된 인증서 체인	인증서 체인이 완전하지 않거나 올바르지 않습니다.	Edge Private 및 Public Cloud 사용자에게만 해당
서버 또는 클라이언트에서 전송한 만료되었거나 알 수 없는 인증서	만료되었거나 알 수 없는 인증서가 북바운드 또는 남바운드 연결에서 서버나 클라이언트에 의해 전송됩니다.	Edge Private Cloud 및 Edge Public Cloud 사용자

호스트 이름 불일치

진단

다음 Edge 관리 API 호출에서 반환된 URL에 사용된 호스트 이름을 기록해 둡니다.
```
curl -v https://myorg.domain.com/v1/getinfo
```
예를 들면 다음과 같습니다.
```
curl -v https://api.enterprise.apigee.com/v1/getinfo
```

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

키 저장소에서 인증서 이름 가져오기:

프라이빗 클라우드 사용자인 경우 다음과 같이 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
```

Edge 관리 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
    },

기본 인증서의 주체 이름에 CN이 something.domain.com.로 되어 있습니다.

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

해상도

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

주체 CN에 와일드카드 인증서가 있는 인증서를 획득하고 (아직 없는 경우) 새 전체 인증서 체인을 키 저장소에 업로드합니다. 예를 들면 다음과 같습니다.
```
"subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
```
기존 주제 CN으로 인증서를 획득하되 (아직 없는 경우) your-org를 사용합니다.your-domain를 소유자 대체 이름으로 사용한 다음 전체 인증서 체인을 키 저장소에 업로드합니다.

참조

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

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

진단

특정 키 저장소에 저장된 인증서에 사용된 CN을 가져옵니다. 다음 Edge 관리 API를 사용하여 인증서의 세부정보를 가져올 수 있습니다.
1. 키 저장소에서 인증서 이름 가져오기:
  
  프라이빗 클라우드 사용자인 경우:
```
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. 키 저장소에 있는 인증서의 세부정보를 가져옵니다.
  
  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. 인증서와 인증서 체인을 검증하고 인증서 체인 작동 방식 도움말에 제공된 가이드라인을 준수하는지 확인하여 유효하고 완전한 인증서 체인인지 확인합니다. 키 저장소에 저장된 인증서 체인이 불완전하거나 유효하지 않으면 TLS/SSL 핸드셰이크 실패가 표시됩니다.
4. 다음 그래픽은 중간 인증서와 루트 인증서가 일치하지 않는 잘못된 인증서 체인이 있는 샘플 인증서를 보여줍니다.

해상도

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

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

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

진단

오류가 northbound 또는 southbound 연결에서 발생했는지 확인합니다. 이 결정을 내리는 방법에 관한 자세한 내용은 문제의 소스 확인을 참고하세요.
tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
- 프라이빗 클라우드 사용자인 경우 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 업스트림 연결의 경우) 또는 메시지 프로세서 (발신 또는 다운스트림 연결의 경우)일 수 있습니다. 서버는 1단계에서 결정한 내용에 따라 에지 라우터 (인바운드 또는 북바운드 연결용) 또는 백엔드 서버(아웃바운드 또는 사우스바운드 연결용)일 수 있습니다.
- 공개 클라우드 사용자인 경우 Edge 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 업스트림 연결용) 또는 백엔드 서버(발신 또는 다운스트림 연결용)에서만 tcpdump 데이터를 수집할 수 있습니다.
```
tcpdump -i any -s 0 host IP address -w File name
```
tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
Wireshark 또는 유사한 도구를 사용하여 tcpdump 데이터를 분석합니다.
tcpdump 출력에서 확인 단계 중에 인증서를 거부하는 호스트 (클라이언트 또는 서버)를 확인합니다.
데이터가 암호화되지 않은 경우 tcpdump 출력에서 다른 쪽에서 전송된 인증서를 가져올 수 있습니다. 이 값은 이 인증서가 트러스트 저장소에서 사용할 수 있는 인증서와 일치하는지 비교하는 데 유용합니다.
메시지 프로세서와 백엔드 서버 간의 SSL 통신에 대한 샘플 tcpdump를 검토합니다.
인증서 알 수 없음 오류를 보여주는 tcpdump 샘플
1. 메시지 프로세서 (클라이언트)는 메시지 #59에서 백엔드 서버(서버)에 'Client Hello'를 보냅니다.
2. 백엔드 서버는 메시지 #61에서 메시지 프로세서에 'Server Hello'를 보냅니다.
3. 사용된 프로토콜과 암호화 스위트 알고리즘을 상호 검증합니다.
4. 백엔드 서버는 메시지 #68에서 인증서와 Server Hello Done 메시지를 메시지 프로세서로 전송합니다.
5. 메시지 프로세서는 메시지 70에서 심각한 알림 '설명: 인증서 알 수 없음'을 전송합니다.
6. 메일 #70을 자세히 살펴보면 아래와 같이 알림 메시지 외에 추가 세부정보가 없습니다.
7. 다음 그래픽에 표시된 대로 백엔드 서버에서 전송한 인증서에 관한 세부정보를 확인하려면 메시지 #68을 검토하세요.
8. 백엔드 서버의 인증서와 전체 체인은 위의 그림과 같이 '인증서' 섹션 아래에 모두 있습니다.
위 예와 같이 라우터 (북바운드) 또는 메시지 프로세서 (남바운드)에서 인증서를 알 수 없는 것으로 확인한 경우 다음 단계를 따르세요.
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 핸드셰이크 실패의 원인이 됩니다.
클라이언트 애플리케이션 (북바운드) 또는 타겟 서버 (사우스바운드)에서 인증서를 알 수 없는 것으로 확인되면 다음 단계를 따르세요.
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 핸드셰이크 실패의 원인이 됩니다.
서버/클라이언트에서 보낸 인증서가 만료된 것으로 확인되면 수신 클라이언트/서버가 인증서를 거부하고 tcpdump에 다음 알림 메시지가 표시됩니다.
알림 (수준: 심각, 설명: 인증서 만료됨)
적절한 호스트의 키 저장소에 있는 인증서가 만료되었는지 확인합니다.

해상도

위 예에 나온 문제를 해결하려면 유효한 백엔드 서버의 인증서를 메시지 프로세서의 트러스트 저장소에 업로드하세요.

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

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

SNI 사용 설정 서버

클라이언트가 서버 이름 표시 (SNI) 사용 설정 서버와 통신하지만 클라이언트에 SNI가 사용 설정되어 있지 않으면 TLS/SSL 핸드셰이크 실패가 발생할 수 있습니다. 이 문제는 Edge의 북바운드 또는 사우스바운드 연결에서 발생할 수 있습니다.

먼저 사용 중인 서버의 호스트 이름과 포트 번호를 확인하고 SNI가 사용 설정되어 있는지 확인해야 합니다.

SNI 사용 설정 서버 식별

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
```
openssl 명령어를 실행하고 아래와 같이 서버 이름을 전달하여 관련 서버 호스트 이름(Edge 라우터 또는 백엔드 서버)에 연결해 보세요.
```
openssl s_client -connect hostname:port -servername hostname
```
1단계에서 핸드셰이크 실패가 발생하거나 1단계와 2단계에서 다른 인증서를 가져오는 경우 지정된 서버에서 SNI가 사용 설정되어 있음을 나타냅니다.

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

진단

오류가 northbound 또는 southbound 연결에서 발생했는지 확인합니다. 이 결정을 내리는 방법에 관한 자세한 내용은 문제의 소스 확인을 참고하세요.
tcpdump 유틸리티를 실행하여 추가 정보를 수집합니다.
- 프라이빗 클라우드 사용자인 경우 관련 클라이언트 또는 서버에서 tcpdump 데이터를 수집할 수 있습니다. 클라이언트는 클라이언트 앱 (수신 또는 업스트림 연결의 경우) 또는 메시지 프로세서 (발신 또는 다운스트림 연결의 경우)일 수 있습니다. 서버는 1단계에서 결정한 내용에 따라 에지 라우터 (인바운드 또는 북바운드 연결용) 또는 백엔드 서버(아웃바운드 또는 사우스바운드 연결용)일 수 있습니다.
- 공개 클라우드 사용자인 경우 Edge 라우터나 메시지 프로세서에 액세스할 수 없으므로 클라이언트 앱 (수신 또는 업스트림 연결용) 또는 백엔드 서버(발신 또는 다운스트림 연결용)에서만 tcpdump 데이터를 수집할 수 있습니다.
```
tcpdump -i any -s 0 host IP address -w File name
```
tcpdump 명령어 사용에 대한 자세한 내용은 tcpdump 데이터를 참고하세요.
Wireshark 또는 유사한 도구를 사용하여 tcpdump 출력을 분석합니다.
다음은 Wireshark를 사용한 tcpdump의 샘플 분석입니다.
1. 이 예에서는 Edge 메시지 프로세서와 백엔드 서버 (다운스트림 연결) 간에 TLS/SSL 핸드셰이크 실패가 발생했습니다.
2. 아래 tcpdump 출력의 메시지 #4는 메시지 프로세서 (소스)가 백엔드 서버 (대상)에 'Client Hello' 메시지를 보냈음을 보여줍니다.
3. 'Client Hello' 메시지를 선택하면 메시지 프로세서가 TLSv1.2 프로토콜을 사용하고 있음을 알 수 있습니다.
4. 메시지 #4는 백엔드 서버가 메시지 프로세서의 'Client Hello' 메시지를 확인했음을 보여줍니다.
5. 백엔드 서버는 즉시 메시지 프로세서에 심각한 알림 : 핸드셰이크 실패를 전송합니다 (메시지 #5). 즉, TLS/SSL 핸드셰이크가 실패하고 연결이 닫힙니다.
6. 메시지 #6을 검토하여 다음 정보를 확인하세요.
  - 백엔드 서버는 TLSv1.2 프로토콜을 지원합니다. 이는 메시지 프로세서와 백엔드 서버 간에 프로토콜이 일치했음을 의미합니다.
  - 하지만 백엔드 서버는 아래 그림과 같이 메시지 프로세서에 심각한 경고: 핸드셰이크 실패를 전송합니다.
7. 이 오류는 다음 이유 중 하나로 인해 발생할 수 있습니다.
  - 메시지 프로세서가 백엔드 서버에서 지원하는 암호화 스위트 알고리즘을 사용하지 않습니다.
  - 백엔드 서버는 SNI가 사용 설정되어 있지만 클라이언트 애플리케이션이 서버 이름을 전송하지 않습니다.
8. tcpdump 출력에서 메시지 #3 (Client Hello)을 자세히 검토합니다. 아래와 같이 Extension: server_name이 누락되어 있습니다.
9. 이는 메시지 프로세서가 SNI 지원 백엔드 서버에 server_name을 전송하지 않았음을 확인합니다.
10. 이로 인해 TLS/SSL 핸드셰이크가 실패하고 백엔드 서버가 메시지 프로세서에 심각한 알림: 핸드셰이크 실패를 전송합니다.
메시지 프로세서에서 system.properties의 jsse.enableSNIExtension property가 false로 설정되어 있는지 확인하여 메시지 프로세서가 SNI 지원 서버와 통신하도록 설정되어 있지 않음을 확인합니다.

해상도

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

/opt/apigee/customer/application/message-processor.properties 파일을 만듭니다 (아직 없는 경우).
이 파일에 다음 줄을 추가합니다. conf_system_jsse.enableSNIExtension=true

이 파일의 소유자를 apigee:apigee로 변경합니다.

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

메시지 프로세서를 다시 시작합니다.

/opt/apigee/apigee-service/bin/apigee-service message-processor restart

메시지 프로세서가 두 개 이상인 경우 모든 메시지 프로세서에서 1~4단계를 반복합니다.

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