리프 인증서는 유효, 체인은 만료: 깊이를 읽으세요

서버 인증서를 확인하면 시계에 아직 몇 달이 남아 있는데도 클라이언트가 만료 메시지와 함께 연결을 거부합니다. 당신이 읽은 날짜는 리프의 것이고, 불만은 경로 더 깊은 곳에 있는 무엇일 수 있습니다. 검증은 체인을 따라가며, 이 순회가 선택하는 모든 인증서는 자체 유효 기간에서 실패할 수 있습니다. 무엇이 실패했는지 갱신하기 전에 읽으세요.

깊이는 실패한 인증서를 지목한다

OpenSSL 진단에서 깊이 0은 대상 인증서이고 깊이 1은 서명한 발급자이며, 더 큰 숫자는 신뢰 앵커를 향해 계속됩니다. 깊이 1에서 보고된 만료는 리프의 현재 notAfter 과 모순되지 않으므로, 보이는 인증서를 다시 확인해도 오류를 절대 설명하지 못합니다.

실패한 인증서의 지문을 해당 subject와 함께 기록하세요. 서로 다른 인증서가 같은 CA 이름을 가질 수 있기 때문입니다. 교차 서명이 바로 그 상황을 만듭니다: 같은 기관이 서로 다른 유효 날짜로 두 번 이상 나타나며, 검증자는 예상하지 못한 쪽을 골랐습니다. 익숙한 레이블은 식별자가 아니며, 지문이 같은 이름을 공유하는 두 객체를 구분합니다.

인증서 역할이 두 개 이상인 제품도 주의하세요. OpenVPN Access Server에서 웹 인터페이스를 보호하는 인증서는 VPN 연결에 쓰이는 인증서와 별개이므로, 관리 페이지를 여는 브라우저는 터널 경로에 대해 아무것도 증명하지 않습니다.

신뢰 입력은 체인 후보와 같지 않다

검증자에게 두 입력을 분리해서 명시적으로 주세요. 신뢰 파일은 당신이 받아들이는 앵커를 담고, 신뢰되지 않는 번들은 경로를 만들기 위해 제공된 중간 인증서를 담습니다. 이를 섞는 것이 사람들이 실수로 중간 인증서를 루트로 승격하고 나서 같은 오류가 컴퓨터 사이에서 따라다니는 이유를 궁금해하는 방식입니다.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

기본 경로와 저장소를 -no-CApath -no-CAstore 로 비활성화하면 테스트가 정직해집니다. 결과는 당신이 지정한 파일에 달려 있고, 워크스테이션이 우연히 신뢰하는 것에는 달려 있지 않습니다. OpenSSL 검증 참조는 이 옵션과 그들이 생성하는 진단을 문서화합니다.

-show_chain 은 검증이 성공할 때 만들어진 체인을 출력하며, 경로가 의도한 것인지 확인하는 데 유용합니다. 실패하면 보고된 깊이와 subject를 유지하세요. 그 두 필드가 다음 독자에게 어떤 인증서를 검사할지 알려줍니다.

이것이 하지 않는 일은 각 클라이언트의 정책을 재현하는 것입니다. 핀, 용도 제한, 클라이언트별 신원 확인은 클라이언트에 있고 이 명령에는 없습니다. 서버에서 검증이 통과하는데도 연결이 실패할 때 검사할 설정은 그것들입니다. 두 진단을 분리하세요. 그렇지 않으면 핀 고정 오류를 쫓다가 건강한 인증서를 갱신하게 됩니다.

검사가 증명하는 것과 빠뜨리는 것

이것은 당신이 제공한 신뢰 파일에 대한 경로 및 용도 검사입니다. HTTPS 이름 검사에는 적절한 옵션으로 예상 호스트 이름을 추가하세요. VPN 연결에는 클라이언트에 구성된 신원 검사를 유지하고 해당 클라이언트가 실제로 읽는 신뢰 자료를 사용하세요.

서버가 보내는 것은 후보 집합이며, 당신의 클라이언트가 결국 만들 경로가 아닙니다. 로컬 신뢰와 라이브러리의 구성 규칙이 모두 결과를 형성하므로, 같은 응답이 한 컴퓨터에서는 검증되고 다른 컴퓨터에서는 실패할 수 있습니다. 동일한 평가를 가정하기 전에 실패하는 클라이언트의 관리형 신뢰 저장소와 TLS 구현을 작동하는 클라이언트의 것과 비교하세요. 그곳의 차이가 „이 노트북에서만 실패한다“는 많은 보고를 설명합니다.

각 인증서의 기간을 하나씩 보는 대신 집합으로 보려면 다음과 같이 출력하세요:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

그 두 번째 명령은 각 파일을 손으로 디코딩하지 않고 subject와 발급자를 나열하며, 이렇게 리프는 여전히 괜찮아 보이는데 날짜가 지난 중간 인증서를 발견합니다.

검증을 약화시키지 않고 경로를 수리하세요

만료된 중간 인증서나 오래된 교차 서명 인증서가 제공되면 발급자의 현재 지원되는 체인을 구해 서비스의 문서화된 인증서 워크플로로 배포하세요. 클라이언트에 의도한 관리형 앵커가 없으면 관리형 신뢰 구성이나 클라이언트 소프트웨어를 업데이트하세요. 메시지를 조용히 하려고 번들의 모든 인증서를 루트로 표시하는 지름길에 저항하세요.

루트 처리에는 주석이 필요합니다. 요약이 종종 그것을 과장하기 때문입니다. RFC 5280은 앵커를 예상 경로 밖에 있는 입력으로 취급하고, OpenSSL은 자체 루트 CA 인증서를 포함하는 유효성 검사를 문서화합니다. 두 진술 모두 각자의 시스템에서는 사실입니다. 한 라이브러리의 루트 만료 동작을 모든 클라이언트에 일반화하면 자신감 있는 잘못된 답이 나옵니다.

변경 후 영향을 받은 클라이언트에서 새 인증을 강제하고 특정 만료 메시지가 사라졌는지 확인하세요. 리프 자체가 부적합한 경우에만 리프를 갱신하세요. 시간 검사를 비활성화하거나 과거 교차 인증서를 복원하는 것은 유효한 현재 경로를 만들지 않습니다. 다음 실패를 미룰 뿐입니다.