인증서 폐기 확인이 실패한다: 어느 호스트가 무엇에 도달하지 못하는가

인증서가 유효 기간 안에 있어도 VPN은 여전히 인증 실패를 보고할 수 있고, 누군가는 인증서가 폐기되었다고 결론짓는다. 이것은 세 가지 서로 다른 사실이다. 폐기 데이터는 검증을 수행하는 장치가 인증서 내부에 명시된 게시 지점에서 직접 가져와야 한다. 그 장치가 지점에 도달하지 못하면, 확인은 인증서 상태와 무관한 이유로 실패한다.

가져오기 경로는 검증자의 것

검증자를 식별하는 것부터 시작한다. 노트북이 게이트웨이 인증서를 확인하면 노트북이 가져오기를 수행한다. 게이트웨이가 클라이언트 인증서를 확인하면 게이트웨이가 수행한다. 백엔드 인증 서비스는 자체 네트워크 위치를 가진 세 번째 검증자로 추가될 수 있다. 각각 인터넷으로 가는 경로와 프록시 구성이 다르다. 관리자 워크스테이션에서 수집한 증거는 DMZ 내부의 서버에 대해 아무것도 말해주지 않는다.

무엇이든 바꾸기 전에 인증서, 검증자, 시도 시각, 정확한 상태 코드를 기록한다.

인증서에서 게시 지점을 읽는다

인증서는 자신의 상태가 어디에 있는지 밝힌다. CA 주소를 추측하는 대신 그 필드를 읽는다.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

첫 번째 확장은 CRL 배포 지점을 나열하고, 두 번째는 기관 정보 접근 방식을 나열하며, 여기에는 OCSP 상태와 발급자 인증서 가져오기가 포함될 수 있다. 이들은 서로 다른 메커니즘이며, OCSP 응답자는 CRL 파일이 아니다. 게시 호스트는 CA 머신이 아니라 일반 웹 서버인 경우가 많다. 오프라인 발급자가 서명한 CRL을 다른 서버가 배포할 수 있기 때문이다. 따라서 CA에 대한 접근이라고 서술된 방화벽 규칙은 구현하거나 검토하기에 너무 모호하다.

검증하는 장치에서 가져오기를 시험한다

실제로 검증을 수행하는 환경에서 승인된 인증서 자료를 사용하고 개인 키 없이 가져오기 시험을 실행한다.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil 실행은 체인을 검증하고 어떤 URL 가져오기가 성공했는지 실패했는지 보고한다. 반면 curl 호출은 같은 호스트에서 게시 주소 하나만 시험하고 상태 코드만 반환한다. 도달 가능한 주소에서의 가져오기 실패는 내용이나 서명 문제를 가리키고, 연결 오류는 라우팅, DNS, 프록시를 가리킨다. 두 결과를 모두 보관한다. 가져오기 하나가 성공했다고 해서 체인 전체가 쓸 수 있는 것은 아니다. 예시의 호스트와 경로를 인증서에서 찾은 배포 지점으로 바꾼다.

누락된 데이터와 폐기 상태를 구분한다

네 가지 결과는 밖에서 보면 비슷하다. 지점에 도달할 수 없거나, 목록이 오래되었거나, 목록이 잘못된 발급자에 의해 서명되었거나, 인증서가 정말 폐기된 경우다. 상태 결과인 것은 마지막 하나뿐이며, 접근을 제거할 근거가 되는 것도 그것뿐이다. 캐싱은 상황을 더 복잡하게 만든다. 이전에 가져온 데이터가 다음 새로 고침까지 깨진 게시 경로를 감출 수 있기 때문이다. 폐기 확인을 끄거나, 무관한 인증서를 지우거나, 게이트웨이를 재부팅하는 것은 모두 진단을 활동으로 대체하는 일이다.

수정 후에는 새 인증을 강제하고 의도한 상태 가져오기가 성공하는지 확인한다. 통제된 시험 신원이 있다면 그것이 여전히 거부되는지 확인한다. 확인을 없애서 얻은 가용성은 복구가 아니기 때문이다.