잘못된 VPN 인증서를 폐기했나요? 복구 옵션과 한계

누군가 CA 콘솔에서 인증서를 폐기했고 이제 사용자가 연결할 수 없다. 첫 번째 본능은 실행 취소를 찾는 것이지만 대부분의 PKI에는 그런 것이 없으며, 폐기는 일련번호에 대한 선언된 사실이고 지원되는 되돌림 경로는 새 인증서이지 뒤집힌 기록이 아니다. 아래 점검을 순서대로 진행하라—어떤 복구가 허용되는지는 사유 코드와 키가 노출된 적이 있는지에 달려 있다.

사람이 아니라 인증서를 식별하라

일반 이름은 반복된다. 지난 분기에 재등록한 사용자는 같은 CN과 다른 일련번호를 가진 인증서를 두 개 가질 수 있으며, 하나를 폐기해도 다른 하나는 계속 작동한다. 먼저 정확한 객체를 확정하라:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

일련번호, 발급자, 폐기 날짜, CRL에 기록된 사유를 적어 두고, 해당 일련번호를 제시하는 장치를 확인하라. 폐기된 인증서가 노트북, 휴대폰, 예비 라우터에 여전히 설치되어 있을 수 있고, 그중 하나에만 도달하는 교체는 두 번째 사고를 만든다.

빠른 동작 확인은 아무것도 바꾸지 않고 상태를 확인한다:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

인증서를 폐기됨으로 보고하면 CRL과 클라이언트가 일치하고, 깨끗하게 검증되면 손에 든 클라이언트는 폐기된 것이 아니며 조사는 계속된다.

CA가 보류를 사용했는지 영구 폐기를 사용했는지 확인하라

RFC 5280은 certificateHold을 임시 상태로, removeFromCRL을 이를 해제하는 신호로 정의한다. 그 수명 주기는 실제하지만 일반적인 실행 취소 버튼은 아니다. 사유 코드를 읽으면 발급자가 해제를 지원할 의도가 있었는지 알 수 있다.

함정은 임시 의도가 임시 기록을 의미한다고 가정하는 것이다. CA 항목이 keyCompromise 또는 cessationOfOperation를 담고 있으면 버튼을 누른 사람의 의도와 무관하게 인증서는 영구 폐기된 것이다. 반대로 보류 해제를 구현하지 않는 CA에서 certificateHold로 표시된 항목은 해제가 결코 게시되지 않으므로 사실상 영구적이다.

OpenSSL 기반 CA는 한계를 보여 주며, ca 명령은 certificateHold과 removeFromCRL을 포함한 -crl_reason 값을 받지만 델타 CRL은 생성하지 않는다. OpenSSL CA 문서가 CRL 출력에 대해 이 한계를 명시한다. 일련번호를 단순히 생략한 전체 CRL은 "이 항목은 해제되었다"고 말하는 델타와 다른 게시 모델이므로, OpenSSL 기반 VPN CA에 removeFromCRL을 붙여 넣어도 표준에 정의된 해제가 생성되지 않는다.

키가 노출되었을 수 있다면 교체하라

폐기된 인증서는 이 키를 더 이상 신뢰할 수 없을지 모른다는 선언이다. 폐기가 실질적으로 올바랐다면 — 노트북 분실, 공유 드라이브로 키 복사, 티켓에 개인 키 붙여 넣기 — 같은 인증서를 복원하는 것은 의도대로 작동하던 보안 결정을 뒤집는 것이다.

등록 절차를 통해 새 키 쌍을 발급하고 새 프로필을 배포하며, 이전 일련번호는 수명 전체 동안 폐기된 상태로 두어라. 일련번호나 지문으로 신원을 고정하는 모든 것을 갱신하라—허용 목록, 장치 인벤토리, 특정 인증서를 기대하는 모니터링도 포함된다.

이전 인증서를 복원하려는 편의성 논리는 현실적이지만 조용히가 아니라 명시적으로 답해야 한다. "사용자가 오늘 접속해야 한다"는 발급을 앞당길 이유이지, 책임질 수 없는 키의 폐기를 되돌릴 이유가 아니다.

행정적 실수였다면 통제 하에 교체하라

폐기가 단순히 잘못되었고 키가 한 번도 노출되지 않았다면, 복구는 편집이 아니라 여전히 통제된 교체다. 발급자가 지원하는 절차를 사용하고 일련번호와 발급 이력을 그대로 유지하며, 두 가지 유혹적인 지름길을 피하라: index.txt의 상태 문자를 R에서 다시 V로 되돌리는 것과, 새 인증서가 일련번호를 재사용할 수 있도록 발급 행을 삭제하는 것이다.

OpenSSL CA에서 데이터베이스는 탭으로 구분되어 있어 잘못 읽기 쉽고, 그래서 수동 편집이 매력적으로 보인다:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

읽되 쓰지 마라. 파일을 편집하면 감사 흔적 없이 다음 CRL이 바뀌고, 원래 행을 아직 보유한 다른 CA 인스턴스나 백업은 나중에 그것과 어긋난다.

교체 인증서를 발급한 뒤 일반 메커니즘으로 새 CRL을 게시하고 클라이언트가 가져가게 하라. CRL을 제거하거나 수명을 영으로 줄이거나 클라이언트 프로필에서 폐기 확인을 비활성화하면, CA가 지금까지 게시한 다른 모든 폐기를 약화시켜 사용자 한 명을 고치는 셈이다.

새 허용을 확인하고 기록을 보존하라

이미 열려 있던 세션이 아니라 새 연결로 테스트하라. 살아 있는 터널은 새 핸드셰이크가 수행하는 허용 점검을 다시 실행하지 않을 수 있고, CRL 캐시 때문에 클라이언트는 갱신될 때까지 계속 연결할 수 있다. 연결을 끊고 다시 연결한 뒤 서버 로그에서 어떤 일련번호가 허용되었는지 확인하라.

아직 기억이 생생할 때 무슨 일이 있었는지 기록하라: 어떤 일련번호가, 누구에 의해, 어떤 사유로 폐기되었고, 어떤 교체가 발급되었으며, CRL이 언제 다시 게시되었는지. 그 기록이 다음 폐기 검토를 가능하게 하고, 실수가 숨겨지지 않고 처리되었다는 증거가 된다.

앞으로 짧은 중단에는 배포에 그런 기능이 있다면, ID 계층에서 비활성화된 계정, 제거된 그룹 멤버십, 보류된 클라이언트 프로필 같은 허용 일시중지 메커니즘을 사용하라. 이렇게 하면 임시 정책 결정을 발급된 인증서가 여전히 신뢰할 만한가라는 질문과 분리할 수 있다—처음에 잃어버린 것이 바로 이 구분이었다.