400 잘못된 요청 - SSL 인증서 오류

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

증상

클라이언트 애플리케이션은 다음과 함께 HTTP 400 - Bad request 응답을 수신합니다. 'SSL 인증서 오류'라는 메시지가 표시됩니다. 이 오류는 일반적으로 에지 라우터에서 전송됩니다. 두 가지 방법으로 TLS 설정을 사용 설정할 수 있습니다

오류 메시지

클라이언트 애플리케이션이 다음과 같은 응답 코드를 받습니다.

HTTP/1.1 400 Bad Request

이어서 아래 HTML 오류 페이지가 표시됩니다.

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

가능한 원인

이 문제의 가능한 원인은 다음과 같습니다.

원인 설명 해당하는 문제 해결 안내
만료된 클라이언트 인증서 클라이언트가 보낸 인증서가 만료되었습니다. Edge 프라이빗 및 퍼블릭 클라우드 사용자
클라이언트가 잘못된 인증서를 보냈습니다 이 오류는 클라이언트 애플리케이션에서 보낸 인증서가 일치하지 않을 때 발생합니다. Edge 라우터의 truststore에 저장된 인증서로 바꿉니다. Edge 프라이빗 및 퍼블릭 클라우드 사용자
Truststore에 클라이언트 루트 인증서가 누락됨 이 오류는 클라이언트의 CA 서명 루트 인증서가 트러스트 저장소입니다 Edge 프라이빗 및 퍼블릭 클라우드 사용자
에지 라우터에 클라이언트 인증서가 로드되지 않음 이 오류는 트러스트 저장소에 업로드된 클라이언트 인증서가 로드되지 않은 경우 발생합니다. 에 있습니다. Edge 프라이빗 클라우드 사용자

원인: 클라이언트 인증서 만료

이 문제는 일반적으로 양방향 TLS에서 발생합니다. 클라이언트에서 보낸 인증서가 만료되었을 때 양방향 TLS에서는 클라이언트와 서버 모두 자신의 공개 인증서를 사용하여 핸드셰이크를 달성합니다. 클라이언트가 서버 인증서의 유효성을 검사합니다. 서버가 클라이언트 인증서의 유효성을 검사합니다.

Edge에서 양방향 TLS는 가상 호스트에서 구현됩니다. 서버 인증서가 키 저장소에 추가되고 클라이언트 인증서가 트러스트 저장소에 추가됩니다.

TLS 핸드셰이크 중에 클라이언트 인증서가 만료된 것으로 확인되면 서버가 그러면 'SSL 인증서 오류'라는 메시지와 함께 400 - 잘못된 요청이 전송됩니다.

진단

  1. Edge UI에 로그인하고 특정 가상 호스트 구성 보기 (관리 > 가상 호스트) API 요청을 받게 됩니다. 또는 Get virtual host API를 관리 API를 사용하여 특정 가상 호스트의 정의를 가져옵니다.

    일반적으로 양방향 TLS 통신을 위한 가상 호스트는 다음과 같습니다.

    <VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

  2. 가상 호스트에 사용된 트러스트 저장소 참조를 확인합니다. 위의 예에서 Truststore 참조 이름은 myTruststoreRef입니다.

  3. Truststore 참조가 가리키는 Truststore를 확인합니다.
    1. Edge UI에서 관리자 > 환경 > 참고 자료 Truststore 참조 이름을 검색합니다.

    2. 특정 Truststore 참조의 참조 열에 있는 이름을 기록해 둡니다. 이 이름이 Truststore 이름이 됩니다.

      <ph type="x-smartling-placeholder">
      </ph> 다음을 보여주는 Edge UI 참조
      그림 1

      위의 예에서 myTruststoreRef에는 myTruststore에게 전송합니다. 따라서 트러스트 저장소 이름은 myTruststore입니다.

  4. 관리 > 환경 > TLS 키 저장소를 사용하려면 TLS로 이동합니다. 키 저장소를 찾고 3단계에서 찾은 Truststore를 찾습니다.

  5. 아래와 같이 특정 Truststore 아래에서 인증서를 선택합니다 (위의 3단계에서 결정).

    <ph type="x-smartling-placeholder">
    </ph>
    그림 2

    위의 예에서 별칭이 client-cert-markw인 인증서는 만료되었습니다.

  6. 트러스트 저장소의 인증서 별칭에 대해 인증서가 만료되었는지 확인합니다.
  7. 인증서가 만료되지 않았다면 다른 원인에 대한 일반적인 진단 단계로 이동합니다.

해상도

새 인증서를 조달하고 인증서를 업로드합니다.

  1. 새 트러스트 저장소를 만듭니다(예: myNewTruststore).
  2. 새로 만든 트러스트 저장소에 새 인증서를 업로드합니다.

  3. 새 가상 호스트를 가리키도록 특정 가상 호스트에 사용되는 Trustore 참조를 수정합니다. 여기에 제공된 단계를 사용하여 참조 수정

    위에 설명된 예에서 참조인 myTruststoreRef to myNewTruststore를 가리킵니다.

다른 원인을 위한 일반적인 진단 단계

  1. 이 문제를 조사하려면 tcpdump 도구
    1. Private Cloud 사용자인 경우 클라이언트 애플리케이션이나 라우터.
    2. 퍼블릭 클라우드 사용자인 경우 클라이언트 애플리케이션에서 TCP/IP 패킷을 캡처합니다.

    3. TCP/IP 패킷을 캡처할 위치를 결정한 후 다음을 사용합니다. tcpdump 명령어를 사용하여 TCP/IP 패킷을 캡처합니다.

      tcpdump -i any -s 0 host <IP address> -w <File name>

      참고: 라우터에서 TCP/IP 패킷을 가져오는 경우 tcpdump 명령어에 있는 클라이언트 애플리케이션의 공개 IP 주소입니다.

      클라이언트 애플리케이션에서 TCP/IP 패킷을 받는 경우 공개 IP를 사용합니다. tcpdump 명령어의 가상 호스트에 사용된 호스트 이름의 주소입니다.

      tcpdump 참조하기 를 참조하세요.

  2. Wireshark 도구 또는 익숙한 유사 도구를 사용할 수 있습니다.

다음은 Wireshark 도구를 사용하여 샘플 TCP/IP 패킷 데이터를 분석한 것입니다.

  1. tcpdump의 패킷 #30 (아래 이미지)은 클라이언트 애플리케이션 (소스)이 "Client Hello"라고 메시지를 라우터 (대상)로 보냅니다.
  2. 패킷 #34는 라우터가 클라이언트 애플리케이션에서 클라이언트 Hello 메시지를 승인했음을 보여줍니다.
  3. 라우터는 '서버 Hello'로 패킷 #35에서 보낸 후 인증서를 전송하고 클라이언트 애플리케이션이 패킷 #38에서 인증서를 보내도록 요청합니다.
  4. 라우터가 'Certificate Request' 패킷을 전송하는 패킷 #38에서 '고유 이름' 이 섹션에서는 클라이언트 인증서, 인증서 체인, 라우터 (서버)가 허용하는 인증 기관입니다.
    5. <ph type="x-smartling-placeholder">
    </ph>
    그림 3

  5. 클라이언트 애플리케이션은 패킷 41번에서 인증서를 전송합니다. 인증서 확인 섹션을 확인하고 클라이언트 애플리케이션에서 전송한 인증서를 확인합니다.

    <ph type="x-smartling-placeholder">
    </ph>
    그림 4
  6. 클라이언트에서 인증서의 주체와 발급자 및 체인이 전송되었는지 확인 애플리케이션 (패킷 #41)이 라우터에서 수락된 인증서 및 해당 체인과 일치합니다. (패킷 #38). 일치하지 않는 것이 오류의 원인입니다. 따라서 라우터는 (서버) 암호화된 경보 (패킷 #57)를 보낸 후 FIN, ACK (패킷 58)을 클라이언트 애플리케이션과 결국 연결이 종료됩니다.
  7. 인증서와 인증서 체인의 불일치는 다음에 설명된 시나리오에 의해 발생할 수 있습니다. 다음 섹션을 참조하세요.

원인: 클라이언트가 보낸 잘못된 인증서

이러한 문제는 일반적으로 인증서의 주체/발급자가 클라이언트 애플리케이션이 라우터 (서버)의 트러스트 저장소에 저장된 인증서 또는 체인과 일치하지 않습니다.

진단

  1. Edge UI에 로그인하고 특정 가상 호스트 구성 보기 (관리 > 가상 호스트) API 요청을 받게 됩니다. Get virtual host API를 사용하여 관리 API를 사용하여 특정 가상 호스트의 정의를 가져옵니다.

    일반적으로 양방향 TLS 통신을 위한 가상 호스트는 다음과 같습니다.

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. 가상 호스트에 사용된 트러스트 저장소 참조를 확인합니다.

    위의 예에서 Truststore 참조 이름은 myCompanyTruststoreRef입니다.

  3. Truststore 참조가 가리키는 Truststore를 확인합니다.
    1. Edge UI에서 관리자 > 환경 참조 Truststore 참조 이름을 검색합니다.

    2. 특정 Truststore 참조의 참조 열에 있는 이름을 기록해 둡니다. 이 이름이 Truststore 이름이 됩니다.

      <ph type="x-smartling-placeholder">
      </ph> Edge UI 표시 트러스트 저장소 참조
      그림 5

      위의 예에서 myCompanyTruststoreRef에는 myCompanyTruststore에 대한 참조입니다. 따라서 트러스트 저장소 이름은 myCompanyTruststore입니다.

  4. 다음 API를 사용하여 Truststore에 저장된 인증서 (이전 단계에서 결정)를 가져옵니다. <ph type="x-smartling-placeholder">
      </ph>

    1. keystore 또는 truststore API의 인증서를 나열합니다.

      이 API는 특정 Truststore의 모든 인증서를 나열합니다.

    2. keystore 또는 truststore API에서 인증서 세부정보를 가져옵니다.

      이 API는 특정 Truststore의 특정 인증서에 대한 정보를 반환합니다.

  5. 각 인증서 및 체인의 발급자와 주체가 myCompanyTruststore는 인증서 및 해당 체인의 인증서와 일치하며 위의 TCP/IP 패킷 (패킷 #38 참조)에서 볼 수 있습니다. 불일치가 있는 경우 트러스트 저장소에 업로드된 인증서가 에지 라우터에 로드되지 않고 있는 경우 원인: 에지 라우터에 클라이언트 인증서가 로드되지 않음으로 이동합니다.
  6. 5단계에서 불일치가 발견되지 않았다면 클라이언트 애플리케이션이 올바른 인증서와 체인을 보내지 않아야 합니다.

해상도

클라이언트 애플리케이션에서 올바른 인증서와 체인이 Edge로 전송되는지 확인합니다.

원인: Truststore에 클라이언트 루트 인증서 누락

이 오류는 클라이언트의 CA 서명 루트 인증서가 트러스트 저장소입니다

진단

  1. Edge UI에 로그인하고 API가 포함된 특정 가상 호스트 구성을 봅니다. 요청이 이루어지는 경우 (관리 > 가상 호스트 > virtual_host) 또는 <ph type="x-smartling-placeholder"></ph> 가상 호스트 API 가져오기: 특정 가상 호스트의 정의를 가져옵니다.

    일반적으로 양방향 TLS 통신을 위한 가상 호스트는 다음과 같습니다.

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. 가상 호스트에 사용되는 트러스트 저장소 참조를 결정합니다. 이전 예에서 truststore 참조 이름은 myCompanyTruststoreRef입니다.
  3. 트러스트 저장소 참조에서 사용 중인 실제 트러스트 저장소를 확인합니다.
  4. Edge UI에서 관리자 > 환경 > 참조 및 검색 를 입력합니다.

  5. 특정 truststore 참조의 truststore 이름은 참조 열에서 확인할 수 있습니다.

    <ph type="x-smartling-placeholder">
    </ph>
    그림 6

    이 예에서는 myCompanyTruststoreRef에 myCompanyTruststore를 사용하세요. 따라서 트러스트 저장소는 이름은 myCompanyTruststore입니다.

  6. 다음을 사용하여 truststore에 저장된 인증서 (이전 단계에서 결정)를 가져옵니다. 다음 API를 포함합니다. <ph type="x-smartling-placeholder">
      </ph>
    1. <ph type="x-smartling-placeholder"></ph> keystore 또는 truststore API의 인증서를 나열합니다. 이 API는 인증서를 저장합니다
    2. <ph type="x-smartling-placeholder"></ph> 키 저장소 또는 truststore API에서 인증서 세부정보 가져오기 이 API는 특정 인증서를 가져올 수 있습니다

  7. 인증서에 루트 인증서를 포함한 전체 체인이 포함되어 있는지 확인합니다. 100% 업타임 체크를 제공합니다 (그림 4 참고). 트러스트 저장소 루트 인증서와 클라이언트의 리프 인증서 또는 리프가 중간 인증서입니다. 트러스트 저장소에 클라이언트의 유효한 루트 인증서가 누락된 경우 이것이 오류의 원인입니다

    그러나 루트 인증서를 포함하여 클라이언트의 전체 인증서 체인이 있는 경우, 이는 신뢰할 수 있는 저장소에 업로드된 인증서가 트러스트 저장소가 에지 라우터에 로드되지 않았을 수 있습니다. 이러한 경우 원인: 클라이언트 인증서가 Edge Router에 로드되지 않았습니다.

해상도

루트 인증서를 포함하여 올바른 클라이언트의 인증서를 사용할 수 있는지 확인합니다. Apigee Edge 라우터의 Truststore에 있습니다

원인: 클라이언트 인증서가 에지 라우터에 로드되지 않음

  1. 퍼블릭 클라우드 사용자인 경우 Apigee Edge 지원팀에 문의하세요.
  2. Private Cloud 사용자인 경우 각 라우터에서 아래 안내를 따르세요. <ph type="x-smartling-placeholder">
      </ph>
    1. /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem 파일이 있는지 확인합니다. 지정할 수도 있습니다 이 파일이 존재하지 않으면 해결 방법 섹션을 참조하세요.
    2. 파일이 있으면 아래 openssl 명령어를 사용하여 다음과 같은 인증서를 제공합니다. 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. 인증서 발급자, 제목, 만료일을 확인합니다. 다음 중 하나라도 일치하지 않는 경우 Edge UI의 Truststore에서 관찰된 내용 또는 관리 API를 사용하여 확인한 경우 오류의 원인을 보여줍니다.
    4. 라우터에서 업로드된 인증서를 새로고침하지 않았을 수 있습니다.

해상도

아래 단계에 따라 최신 인증서가 로드되도록 라우터를 다시 시작합니다.

apigee-service edge-router restart

API를 다시 실행하고 결과를 확인합니다. 문제가 지속되면 다음으로 이동하세요. 진단 정보 수집.

진단 정보 수집

위의 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집하세요. 수집한 정보를 Apigee Edge 지원팀에 문의하여 공유하세요.

  1. 퍼블릭 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
      </ph>
    1. 조직 이름
    2. 환경 이름
    3. API 프록시 이름
    4. 가상 호스트 이름
    5. 호스트 별칭 이름
    6. curl 명령어를 완료하여 오류를 재현하세요.
    7. 클라이언트 애플리케이션에서 캡처된 TCP/IP 패킷
  2. 프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
      </ph>
    1. Get virtual host API를 사용한 가상 호스트 이름 및 정의
    2. 호스트 별칭 이름
    3. 오류 메시지 완료 확인됨
    4. 클라이언트 애플리케이션 또는 라우터에서 캡처된 TCP/IP 패킷
    5. List the certificate from the keystore API의 출력 API 및 Get cert details API(인증서 세부정보 가져오기 API)를 사용하여 가져온 각 인증서의 세부정보
  3. 이 플레이북의 어떤 섹션을 시도했는지 및 도움이 될 만한 기타 정보에 관한 세부정보 빠르게 해결할 수 있도록 도와 드리겠습니다.