OCSP 대 CRL: 각 폐기 확인이 실제로 작동하는 방식

이 두 폐기 확인 중 하나는 인증서 하나에 대한 서명된 답변을 돌려주고, 다른 하나는 전체를 내려받는 서명된 목록을 돌려줍니다. 둘 다 자격 증명이 여전히 신뢰할 수 있는지 검증자에게 알리기 위한 것이지만, 실패하는 방식은 전혀 비슷하지 않습니다. 아래 순서는 운영자가 실제 운영 환경에서 마주치는 흐름을 따릅니다. 네트워크상의 바이트에서 시작해 연결을 거부하는 게이트웨이로 끝납니다. 단계를 건너뛰면 배포는 종이에만 존재하는 폐기 정책을 안고 남게 됩니다.

1단계: 각 확인이 무엇을 돌려주며 언제까지 쓸 수 있는가

CRL은 발급자가 폐기한 모든 인증서를 포괄하는 하나의 서명된 객체로 게시되므로, 검증자는 한 번 가져와 목록의 nextUpdate가 지날 때까지 재사용합니다. OCSP 응답은 더 좁습니다. 정확히 인증서 하나에 대해 답하며 thisUpdate, producedAt, 보통 nextUpdate도 함께 담습니다. 이 차이가 나머지 전부를 좌우합니다. 캐시된 CRL은 조용히 낡아 갑니다. 파일이 여전히 파싱되고 서명도 여전히 검증되기 때문입니다. 반면 만료된 OCSP 응답은 타임스탬프를 읽는 순간 명백히 무가치합니다.

따라서 캐싱이 가장 먼저 확정해야 할 항목입니다. 어느 구성 요소가 사본을 보관하고, 그 사본이 어느 상한을 따르는지입니다. 게이트웨이에서는 상한을 nextUpdate에서 안전 여유를 뺀 값으로 해야 하며, HTTP 캐시 헤더가 우연히 제안하는 값이어서는 안 됩니다. openssl crl -in issuer.crl -noout -lastupdate -nextupdate은 두 날짜를 모두 출력하고, nextUpdate가 이미 과거인 목록은 단지 오래된 것이 아니라 누락된 것으로 다루어야 합니다.

2단계: 인증서가 클라이언트를 어디로 안내하는가

리프 인증서는 보통 두 가지 단서를 담습니다. CRL 배포 지점 확장과 OCSP를 위한 기관 정보 접근 항목입니다. openssl x509 -in client.pem -noout -ext crlDistributionPoints이 첫 번째를 출력하고, 두 번째는 openssl x509 -in client.pem -noout -text의 AIA 섹션 아래에 있습니다. 어느 확장이든 지시일 뿐 의무는 아닙니다. 폐기 확인을 결코 구현하지 않는 클라이언트도 확장이 일 년 전에 죽은 응답자를 가리키는 인증서에 아무 문제 없이 연결됩니다.

배포 지점은 흔히 하나의 네트워크 세그먼트 안에서만 해석되는 내부 호스트를 지정하며, 일부 오래된 클라이언트는 ldap URL을 아예 거부합니다. 연결 가능성은 터널을 종료하는 호스트에서 시험하십시오. 자신의 노트북이 아니라, 실패가 실제로 문제가 되는 유일한 지점이기 때문입니다.

3단계: 장애 전에 fail-closed와 fail-open 중 하나를 고르십시오

응답자에 닿을 수 없거나 목록이 만료되면 결정을 강요받습니다. 연결을 거부하거나, 받아들이고 공백을 기록하는 것입니다. OpenSSL의 verify 하위 명령은 엄격한 선택을 명시적으로 만듭니다. -crl_check을 더하면 사용할 수 없는 CRL이 unable to get certificate CRL이 되고 검증이 실패하기 때문입니다. 대부분의 스택에서 소프트 실패는 플래그가 아니라 확인 자체가 없는 상태이며, 그래서 사고로 출하됩니다.

클라이언트가 실제로 어떤 동작을 하는지 보려면 응답자를 치우고 다시 연결하십시오. 그래도 터널이 올라온다면 건너뛴 확인을 기록한 로그 줄을 찾고, 사고 중에 누가 그 줄을 읽을지 자문하십시오. 같은 공급업체라도 프로토콜에 따라 다를 수 있으며, 같은 머신의 IKEv2 클라이언트와 OpenVPN 클라이언트는 서로 무관한 설정 항목을 읽습니다.

4단계: 트래픽이 허용되는 지점에서 확인이 실행됨을 증명하십시오

연결을 종료하거나 승인하는 프로세스를 찾은 다음, 폐기 확인을 켜는 설정 줄을 물어보십시오. 체인을 검증하지만 폐기를 한 번도 묻지 않는 게이트웨이는 문서에 있는 정책과 다른 정책을 적용하며, 인증서 체인의 어떤 스크린샷도 그 반대를 증명하지 못합니다. OpenVPN은 이 옵션을 crl-verify로 쓰고, strongSwan은 CRL과 OCSP 조회를 CA 설정 아래에 두며 거기에 crl_uris 또는 ocsp_uris을 지정합니다. 둘 중 어느 것도 지목할 수 없다면 확인이 없다고 가정하십시오.

OCSP 응답은 발급 CA가 서명했을 때, 또는 그 CA가 위임한 OCSPSigning 확장 키 사용 권한을 가진 응답자가 서명했을 때만 유효하므로, 무관한 서비스의 답변은 아무것도 증명하지 못합니다. 응답자를 직접 운영한다면 강한 의존성으로 감시하십시오. 죽은 서비스 하나가 모든 fail-closed 클라이언트의 장애가 한꺼번에 되기 때문입니다.

5단계: 인증서 하나를 일부러 폐기하십시오

테스트 인증서를 준비해 운영이 쓰는 것과 같은 경로로 폐기하고 응답자에게 직접 물어보십시오. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text은 폐기 시각과 함께 Cert Status: revoked을 보고해야 하며, good이라는 답은 폐기가 클라이언트가 묻는 응답자에 도달하지 못했음을 뜻합니다. 그다음 목록 경로로 같은 판단을 보려면 openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem을 실행하십시오. 종료 코드가 아니라 이유 문자열을 읽으십시오. 폐기 거부와 체인 오류는 모두 실패로 끝나기 때문입니다.

정말 중요한 단계는 마지막입니다. 실제 적용 지점에서 옛 프로필로 다시 연결해 거부가 폐기에서 비롯됨을 확인하십시오. 그다음 새롭고 유효한 인증서로 다시 연결해 리스너만 망가뜨린 것이 아님을 증명하십시오. 클라이언트에서 프로필을 지우는 것은 서버의 판단에 대해 아무것도 증명하지 못하며, 터널을 결코 종료하지 않는 머신에서 openssl verify이 성공하는 것도 마찬가지입니다. RFC 6960는 적합한 OCSP 응답에 무엇이 들어가는지 정의하며, 이 테스트가 읽는 상태 값도 포함합니다.