폐기된 VPN 인증서가 여전히 연결되나요? CRL 적용을 확인하세요

인증서를 폐기하고 새 목록을 생성했는데도 예전 프로필이 여전히 터널을 엽니다. 폐기 자체가 고장 난 것은 아니며, CRL은 일련번호가 더 이상 유효하지 않다는 서명된 선언이며, TLS를 종료하는 구성 요소가 올바른 발급자에 대해 그것을 로드하고 승인 결정을 내리기 전에야 접근이 바뀝니다. 이런 사례의 대부분이 바로 거기에 있으며, 그래서 폐기와 거부는 서로 다른 사실입니다.

아래 다섯 가지 점검을 순서대로 수행하되, 이후의 점검은 이전 점검이 옳다고 전제하므로 처음 성립하지 않는 곳에서 멈추세요.

어느 구성 요소가 승인 결정을 내리는지 확인하세요

목록을 적용할 수 있는 것은 클라이언트 인증서를 검증하는 프로세스뿐이므로 그 프로세스를 지목하세요. OpenVPN 서버에서는 crl-verify으로 구성된 데몬 자체입니다. ocserv에서는 ocserv.conf 안의 crl 줄입니다. strongSwan에서는 입력이 로드된 CRL과 strictcrlpolicy입니다. VPN 앞에서 TLS를 종료하는 프록시나 장비가 실제 검증자일 수도 있으며, 그렇다면 그 뒤의 데몬은 클라이언트 인증서를 결코 보지 못합니다.

WireGuard는 다른 범주입니다. 인증서도 폐기 목록도 없으며, 피어는 구성의 공개 키로 허용되므로 접근을 끝내는 것은 그 키를 제거하는 일입니다. WireGuard만 쓰는 배포에서 CRL을 찾는다면 그런 메커니즘은 없습니다.

클라이언트 측 함정도 조심하세요. 서버 인증서가 마음에 들지 않아 연결을 거부하는 클라이언트는 서버의 체인을 적용하는 것이지 자기 자격 증명을 폐기하는 것이 아닙니다. 사용자 인증서는 그 인증서가 검증되는 곳에서만 폐기되며, 그것은 거의 항상 서버 측입니다.

목록이 어느 발급자를 위해 서명되었는지 확인하세요

CRL은 하나의 발급 CA로 제한됩니다. 루트와 중간이 있으면 리프 인증서는 중간에서 나오므로 중요한 목록은 중간의 CRL이고, 루트의 목록은 그 리프에 대해 아무 말도 하지 않습니다. 잘못된 파일을 가리키는 검증자는 그것을 즐겁게 파싱하고 일치하는 항목을 찾지 못한 채 모두를 받아들입니다.

데몬을 건드리기 전에 짝을 확인하세요. 인증서의 발급자는 목록의 subject와 일치해야 합니다:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

둘 다 같은 CA에서 오면 인증서에 인쇄된 일련번호가 목록에 나타나야 하는 값입니다. 일치하지 않으면 잘못된 CRL이나 그 잘못된 사본을 들고 있는 것입니다.

유효성도 같은 점검에 속합니다. 과거의 nextUpdate는 목록을 오래되게 만들고, 닫힌 방식으로 실패하는 검증자는 폐기된 것만이 아니라 모든 클라이언트를 거부합니다.

일련번호가 데몬이 로드한 사본에 있는지 확인하세요

폐기는 CA 데이터베이스에 항목을 쓰고, 재생성은 새 파일을 씁니다. 둘 다 시작할 때 예전 사본을 로드한 실행 중인 데몬에는 닿지 않습니다. 목록을 덤프하고 일련번호를 찾으세요:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

그다음 구현이 파일을 어떻게 가져오는지 확인하세요. OpenVPN은 crl-verify에 주어진 경로를 시작할 때 한 번 읽으므로 새 목록에는 재시작이나 재시작 신호가 필요하며, 같은 옵션을 디렉터리로 향하게 하면 연결마다 다시 읽히므로 그래서 디렉터리 모드가 있습니다. strongSwan은 자격 증명을 다시 로드해야 하며, 예를 들어 swanctl --load-creds을 사용합니다. 디스크의 파일이 올바른 것과 검증자가 그것을 쓰는 것은 서로 다른 사실입니다.

목록이 없거나 만료된 경우의 정책을 확인하세요

이것은 많은 배포가 명시적으로 결정한 적 없는 판단이며, 폐기가 당신을 보호하는지 모두를 밖으로 잠그는지 결정합니다. fail-closed는 쓸 만한 폐기 정보가 없으면 거부가 일어난다는 뜻이고, fail-open은 그것 없이도 검증자가 계속한다는 뜻입니다. strongSwan은 선택을 strictcrlpolicy로 노출합니다. OpenVPN은 crl-verify으로 읽거나 파싱할 수 없는 파일에서 시작을 거부하며, 만료된 목록은 조용한 승인 대신 만료된 CRL에 관한 TLS 검증 오류로 나타납니다.

어느 방향을 고르든 자동화가 선택보다 중요하며, nextUpdate 전에 CRL을 재생성하는 작업과 배포된 사본이 낡을 때의 경고가 있으면 어느 정책도 사건이 되지 않습니다. OCSP를 쓰는 온라인 확인은 신선도를 응답자로 옮기지만 같은 규칙이 적용되며, 응답을 확인하도록 구성되지 않은 검증자는 아무것도 바꾸지 않기 때문입니다.

활성 세션을 확인하고, 그다음 키의 사본을 확인하세요

폐기는 인증서 검증 중에 평가되며, 이는 연결할 때와 재협상할 때 일어납니다. 성립된 세션은 재협상할 때까지 계속 동작하며, OpenVPN의 기본값은 reneg-sec 3600으로 한 시간에 한 번입니다. 그 사람이 지금 네트워크에서 나가야 한다면 목록 게시와 함께 세션도 종료하고, 다시 연결이 거부되는지 확인하세요.

자격 증명을 그 사본과 분리하세요. 노트북 한 대에서 프로필을 지워도 같은 개인 키의 다른 사본이 인증하는 것을 막지 못하며, 모든 사본을 무용지물로 만드는 것은 폐기이고, 그것도 이전 점검이 성립할 때만 효과가 있습니다. 교체 장치에는 자체 인증서를 주어 하나를 다른 하나를 건드리지 않고 폐기할 수 있게 하세요.

끝났다고 판단하기 전에 검증 구성 요소가 식별되었고, 목록의 발급자가 리프의 발급자와 일치하고, 폐기된 일련번호가 데몬이 실제로 로드한 사본에 있으며, 없거나 만료된 목록에 대한 정책이 의도적이고 모니터링되며, 활성 세션이 기다리는 대신 종료되었는지 확인하세요. 이 모든 것의 형식은 RFC 5280에 규정되어 있습니다.