하나의 공통 이름, 두 개의 인증서: 허용 목록인가 폐기인가?
같은 공통 이름으로 인증서를 재발급해도 이전 인증서는 유효하게 남습니다. 이름 허용 목록으로는 둘을 구분할 수 없고, CRL이나 일련번호 확인만이 구분합니다.
같은 공통 이름으로 노트북 인증서를 재발급하면 교체처럼 느껴지고, 모두가 이전 인증서는 이미 죽었다고 가정합니다. 그렇지 않습니다. 이전 인증서는 같은 기관이 서명한 유효한 인증서로 남아 있으며, 이름으로 클라이언트를 허용하는 모든 통제는 계속 그것을 허용합니다. 신원 확인과 자격 증명 확인을 구분하는 것은 일련번호이며, 수정은 바로 그 지점에 있어야 합니다.
서버가 사용하는 이름 정책부터 확인하세요
두 가지 통제가 혼동됩니다: 클라이언트가 자신이 누구라고 주장하는지로 허용하는 것과, 특정 인증서 하나를 서비스에서 제거하는 것입니다. 첫째는 이름 확인이고, 둘째는 폐기 확인입니다. 서로 다른 질문에 답하며, 한 배포에 하나만 있고 다른 하나가 없을 수 있습니다.
서버 구성을 읽고 어떤 신원 원본이 사용되는지 기록하세요. username-as-common-name 를 사용하면 인증된 사용자 이름이 클라이언트별 조회의 실효 이름이 됩니다. 이를 사용하지 않으면 인증서의 주체 공통 이름이 사용됩니다. 답이 무엇이든, 허용 목록을 건드리기 전에 적어 두세요.
두 경로는 같은 인증서에 대해 서로 다른 허용 이름 집합을 만듭니다. 여기서 추측하면 잘못된 파일을 편집하고 통제가 작동하지 않는다고 결론내리게 됩니다.
실제로 클라이언트를 허용하는 것이 무엇인지 확인하세요
일치하는 파일이 있는 client-config-dir 는 클라이언트별 옵션을 제공하지만, 그 자체로는 허용 규칙이 아닙니다. 이름으로 허용하려면 ccd-exclusive 가 필요하며, 이는 일치하는 파일이 없는 클라이언트를 거부합니다. 운영 중인 배포에서 이를 켜면 파일이 없는 모든 이름의 연결이 끊기므로, 무엇이든 바꾸기 전에 파일 수를 세세요.
grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/세는 것이 곧 확인입니다: 디렉터리 목록을 연결할 것으로 예상하는 신원과 비교하세요.
다음으로 각 파일 이름이 대소문자와 공백을 포함해 실효 신원과 정확히 일치하는지 확인하세요. office-laptop 에 대한 파일은 주체가 Office-Laptop 로 표시된 인증서에는 아무 효과가 없습니다. 끝의 공백도 일반 목록에서는 숨겨지므로, 존재해 보이는 파일이 읽히지 않은 채 남습니다.
게이트웨이가 읽는 CRL을 확인하세요
CRL은 폐기된 인증서를 발급자와 일련번호로 지정하며, 그것이 이름 확인에 없는 세밀함입니다. 두 인증서는 같은 공통 이름을 공유하면서 일련번호가 다를 수 있습니다, 그리고 일련번호 수준의 목록만이 둘을 구분합니다.
파일을 신뢰하기 전에 설정된 경로, 발급일, 다음 갱신 필드를 확인하세요.
openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subjectCRL의 일련번호를 유지하려는 인증서의 일련번호와 비교하세요. 그 비교가 곧 시험이며, 한 번 눈으로 하는 것이 아무도 읽지 않은 스크립트를 신뢰하는 것보다 낫습니다. 갱신된 CRL을 게이트웨이가 이미 읽는 경로로 배포하세요. 잘못된 디렉터리에 있는 CRL은 아무것도 강제하지 못하며, 어떤 클라이언트 로그도 그것을 언급하지 않습니다.
교체한 다음 두 결과를 모두 증명하세요
같은 공통 이름으로 대체 인증서를 발급하고 두 일련번호를 모두 기록한 다음에야 이전 것을 폐기하세요. 그 순서는 변경을 준비하는 동안 작동하는 신원을 사용 가능하게 유지합니다.
대체 인증서를 먼저 시험하세요: 인증에 성공하고 그 이름이 부여받은 것에 도달해야 합니다. 그런 다음 이전 인증서를 시험해 거부되는지 확인하세요, 성공적인 교체는 폐기에 대해 아무것도 말해주지 않기 때문입니다. 둘 다 여전히 연결되면 폐기 입력이 읽히지 않거나 이전 일련번호가 목록에 없었던 것입니다. 둘 다 연결되지 않으면 자격 증명이 아니라 허용 규칙을 망가뜨린 것입니다.
이미 수립된 세션은 별개입니다, 게이트웨이가 활성 연결을 끊도록 설정되지 않은 한 폐기는 새 인증에만 적용됩니다. 즉시 제거가 필요한지 누군가에게 약속하기 전에 결정하세요.
이름 확인이 결코 할 수 없는 일
허용 목록은 이 신원이 연결될 수 있는지에 답합니다. 그 신원이 어떤 인증서를 사용했는지는 말할 수 없으며, 자격 증명이 유효하고 폐기되지 않은 동안 이전 자격 증명을 계속 허용합니다. 그 간극은 사고 중에 드러납니다, 대체 인증서가 몇 달 전에 발급되었는데 이전 것이 여전히 작동할 때입니다.
인증서 수준 통제가 필요하면 인증서를 지정하는 메커니즘을 사용하세요: CRL 항목, 또는 운영자가 유지하는 지문을 검사하는 검증 훅입니다. 둘 다 유지 비용이 들고, 둘 다 자신이 검사하는 대상에 대해 정직합니다. OpenVPN 2.6 설명서에서 crl-verify 와 클라이언트별 허용을 별도 옵션으로 문서화합니다, 그런 이유에서입니다.
어떤 통제가 어떤 일을 하는지 적어 두고, 부정 사례를 시험하세요. 연결을 거부하는 모습을 한 번도 보지 못한 폐기는 작동하기를 바라는 구성일 뿐입니다.