인증서가 유효한데도 새 VPN 로그인이 실패한다면: CRL을 확인하세요

몇 달이나 남은 인증서와 즉시 실패하는 로그인은 서로 다른 시계를 가진 서로 다른 두 객체를 가리킵니다. 서버가 연결을 거부하는 것은 서버가 참조하는 폐기된 인증서 목록이 자체 만료일을 넘겼기 때문이며, 사용자 인증서가 낡았기 때문이 아닙니다. 사용자 인증서를 갱신해도 그 목록에는 아무 효과가 없습니다.

두 일정을 분리하는 것이 진단의 전부이며, 수정의 형태도 달라집니다.

두 개의 시계, 그리고 그중 하나만 인증서입니다

인증서는 유효 기간 창을 가집니다. 인증서 폐기 목록은 자체 창과 함께 발급자와 서명을 가지며, 검증자는 다음 업데이트 시각이 지난 목록을 신뢰하지 않습니다. 그런 일이 생기면 클라이언트는 완전히 유효한 인증서를 제시하는데도 서버는 목록에 관한 메시지와 함께 연결을 끊습니다. 사용자는 그 메시지를 '인증서가 만료되었다'로 읽고 갱신 요청을 엉뚱한 곳으로 보냅니다.

두 객체는 소유자도 다르며, 인증서는 발급한 CA에서 오는 반면, 목록은 그 CA를 운영하는 사람이 일정에 따라 생성합니다. 사용자는 목록을 갱신할 수 없고, 인증서를 재발급해도 목록을 연장할 수 없습니다.

서비스가 실제로 로드하는 목록을 읽으세요

예상하는 파일이 아니라 실행 중인 구성에서 시작하세요. crl-verify 의 경로는 절대 경로일 수도, 프로필 기준 상대 경로일 수도, 이미지에 구워 넣은 사본일 수도 있으며, 검증자는 그 사본을 읽습니다. openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate 로 제자리에서 확인하고 날짜를 서버 시계와 비교하세요.

그다음 파일이 정말 사용 중인 파일인지 확인하세요. openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout 로 서명을 검사하면 필드를 조용히 출력하는 대신 검증 결과를 보고하며, 다른 CA가 서명한 목록이나 두 번째 디렉터리에 남은 오래된 사본은 만료된 목록과 똑같이 실패합니다.

처음부터가 아니라 폐기 데이터베이스에서 다시 생성하세요

새 목록은 승인된 서명 절차를 통해 CA의 현재 폐기 데이터베이스에서 나와야 합니다. 빈 목록을 생성하거나 인덱스의 오래된 백업에서 다시 생성하면 그 백업 이후에 추가된 모든 신원의 폐기가 조용히 해제됩니다. 이는 로그인 장애를 보안 회귀로 바꾸며, 증상이 사라지기 때문에 아무도 알아차리지 못합니다.

생성 단계를 나머지 CA 도구와 함께 버전 관리에 두어 주기와 서명 키가 기억이 아니라 문서로 남게 하세요. 명령, 서명자, 게시 대상을 명시한 런북 항목이면 충분합니다. 그러면 당직 중인 누구나 어느 인덱스 파일이 권위 있는지 추측하지 않고 다시 생성할 수 있습니다. 목록의 일련번호와 다음 업데이트 시각을 배포 기록과 함께 저장하세요.

검증자가 보는 곳에 배포하세요

새 목록을 서비스가 읽는 경로로 복사하고, 서비스 계정은 읽을 수 있지만 다른 사람은 읽을 수 없도록 소유권과 모드를 설정한 뒤 문서화된 동작에 따라 다시 로드하거나 재시작하세요. 데몬이 시작 시 목록을 캐시한다면 다시 로드하지 않고 파일을 바꿔도 실행 중인 프로세스가 알아차릴 것은 없습니다. 다시 로드한 뒤 프로세스가 보고하는 타임스탬프를 확인하세요.

여러 서비스가 클라이언트를 검증한다면 각각에 배포하세요. 한 엔드포인트를 업데이트하고 다른 하나를 이전 사본으로 남겨두면 두 번째로 몰리는 사용자에게만 나타나는 장애가 생깁니다. 그 엔드포인트의 짧은 목록을 같은 런북에 두세요. 배포 후에는 사본이 도착했다고 가정하지 말고 각 엔드포인트가 보고하는 목록 날짜를 확인하세요.

다음 기한이 지나기 전에 보이게 하세요

게시 주기를 길게 하면 프로세스를 만들지 않고도 이 사건의 빈도를 낮출 수 있습니다. 운영자 정책에서 주기를 고른 뒤, 다시 생성하고 배포할 충분한 여유를 두고 배포된 목록의 다음 업데이트 필드에 경보를 설정하세요. 실패하는 것은 배포된 사본이므로 CA 호스트가 아니라 배포된 사본에 경보를 설정하세요.

배포 후에는 양방향을 모두 검증하세요. 허용된 사용자는 연결되고, 알려진 폐기 신원은 여전히 실패해야 하며, 두 번째 확인이 불완전한 재생성을 잡아내는 검사이며, 바로 이 목적으로 유지하는 테스트 프로필에 대해 명령 하나면 됩니다.