VPN 클라이언트가 인증서를 신뢰하기 전에 확인하는 것

VPN 클라이언트가 인증서를 검증할 수 없다고 알리고, 대화 상자는 거기서 끝납니다. 파일은 있고 서버도 동작하며, 같은 프로필이 지난달 다른 노트북에서 작동했습니다. 그 한 줄 경고 아래에서 클라이언트는 피어 인증서를, 설정한 인증 기관이 서명 경로를 보증하는지, 그 경로가 인증 기관에 닿는지, 피어 이름이 요청한 이름인지, 인증서가 지금 이 용도로 쓸 수 있는지라는 네 관문에 통과시켰습니다. 닫힌 관문을 찾으면 수리는 대개 파일 하나이며, 그 단계를 건너뛰면 오후 내내 번들을 다시 가져오게 됩니다.

프로필을 편집하기 전에 대화 상자를 읽으십시오

인증서 오류 문구는 설치한 VPN 제품이 아니라 그 아래 라이브러리가 만들므로, 정확한 문자열이 첫 번째 증거입니다. «로컬 발급자 인증서를 가져올 수 없습니다»는 경로나 신뢰 앵커를 가리킵니다. «인증서가 만료되었거나 아직 유효하지 않습니다»는 시간을 가리킵니다. «지원되지 않는 인증서 용도»는 확장 키 사용을 가리킵니다. 이름 불일치는 어떤 이름을 원했는지 알려 줍니다. 네 가지 중 어느 것도 클라이언트 재설치로 고쳐지지 않습니다.

무엇이든 바꾸기 전에 로그 수준을 올리십시오. OpenVPN은 --verb 4으로 실행하면 핸드셰이크 주변의 검증 실패를 보고하고, strongSwan은 자신의 신원과 체인 결정을 charon 로그에 기록합니다. 그다음 사람들은 보통 디스크의 파일을 시험하지만 프로필은 더 오래된 사본을 내장하기 때문에, 어떤 인증서를 검사하는지 확인하십시오. 프로필이 PEM 블록을 내장하면 내장된 인증서가 시험 대상입니다.

인증 기관은 권한이 아니라 신원에 서명합니다

인증 기관은 이름과 서명 키를 보유합니다. 자신의 정책에 따라 공개 키를 그 이름에 묶는 인증서를 발급하며, 유효 기간과 사용 제약이 함께 붙습니다. 클라이언트는 발급자를 알아보는 데 인증 기관의 인증서만 필요하고, 서명 키는 결코 필요하지 않으며, 그 키를 클라이언트에 배포하면 배포가 신뢰하는 어떤 신원이든 만들 수 있는 능력을 주게 됩니다.

인증 기관을 신뢰하면 그것이 서명한 모든 인증서가 후보가 되며, 올바른 피어가 되는 것은 아닙니다. 같은 내부 CA의 웹 서버 인증서도 후보입니다. 그래서 이름과 용도 관문이 있고, 침해된 CA 키가 단일 서버보다 더 중요한 것은 그 키가 인증 기관이 발급한 모든 신원에 닿기 때문입니다. 기기마다 클라이언트 인증서를 따로 발급하면, 분실한 노트북은 배포 전체의 키 교체가 아니라 한 건의 폐기가 됩니다.

클라이언트가 구축하려는 경로를 다시 구축하십시오

경로는 피어 인증서에서 시작해 중간 인증서가 없거나 여러 개를 거쳐 신뢰 저장소의 루트에 이릅니다. 중간 인증서 누락은 가장 흔한 체인 고장이며, 클라이언트 쪽에서는 신뢰되지 않는 루트와 똑같이 보입니다. 먼저 리프를 읽고, 그다음 배포하려는 자료로 OpenSSL이 경로를 구축하게 하십시오.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

종료 상태가 성공이면 그 파일들로 경로가 구축된 것이고, 실패하면 도달하지 못한 인증서의 이름이 나옵니다. openssl verify이 성공하는데 클라이언트가 계속 거부한다면, 차이는 서버가 실제로 보내는 내용이나 프로필이 읽는 신뢰 파일에 있습니다. OpenVPN에서는 중간 인증서를 서버 인증서 파일에 함께 넣거나 --extra-certs으로 따로 줄 수 있으며, 같은 주체 이름 아래 두 개의 루트를 담은 번들은 클라이언트 하나를 잘못된 가지로 보냅니다.

이름과 용도는 별개의 관문

체인 구축은 이름이 당신의 것인지 묻지 않습니다. OpenVPN은 프로필이 --verify-x509-name을 설정할 때만 확인하며, 일반 이름만 맞추던 옛 습관은 신원이 subjectAltName에 사는 인증서에서 깨집니다. IKEv2 배포는 설정된 신원을 SAN 항목이나 식별 이름과 맞추며 어느 쪽인지는 클라이언트에 따라 다르고, wildcard나 %any 값은 있다고 생각한 비교를 조용히 끕니다.

다음은 시간과 용도입니다. 시계가 몇 시간 앞선 노트북은 아직 유효하지 않은 인증서를 거부하고, 만료된 중간 인증서는 리프가 유효해도 경로를 실패시킵니다. 용도 실패는 확장 키 사용에 serverAuth가 없는 인증서나 핸드셰이크 서명을 허용하지 않는 keyUsage에서 오며, OpenSSL은 이를 지원되지 않는 인증서 용도로 보고합니다. 올바른 템플릿에서 다시 발급하며, 그 메시지 어디에도 검증을 끌 이유는 없습니다.

폐기는 누군가 설정했을 때만 동작합니다

CRL이나 OCSP 응답은 자동으로 조회되지 않습니다. OpenVPN 서버에서는 --crl-verify이 목록을 가리킬 때만 클라이언트 인증서를 목록과 대조합니다. 서버 인증서의 클라이언트 측 확인은 구현에 따라 다르며 흔히 없습니다. strongSwan은 피어의 CRL을 보기 전에 자체 폐기 플러그인과 정책이 필요합니다.

폐기된 클라이언트 인증서가 여전히 접속하고 모두가 폐기가 깨졌다고 결론짓는, 결국 받게 될 티켓이 바로 이것을 설명합니다. 아무것도 확인하지 않고 있었던 것입니다. CRL을 게시하고 갱신하거나, 클라이언트 인증서를 충분히 단명하게 유지해 오래된 폐기가 잠깐만 문제되게 하고, 사고 때 필요하기 전에 실험실 인증서로 폐기 경로를 연습하십시오.

검증을 켜 둔 채 하는 수리 순서

표의 각 행이 서로 다른 객체로 보내기 때문에, 파일을 건드리기 전에 증상으로 정렬하십시오.

프로필이 읽는 파일을 확인하고, 경로를 직접 구축하고, 서버가 중간 인증서를 보내는지 확인하고, 시계를 비교하고, SAN을 읽고, EKU를 읽은 다음 다시 연결해 같은 로그 줄이 사라지는지 보십시오. 기기에 CA를 전혀 줄 수 없다면, OpenVPN 2.6 버전이 --peer-fingerprint을 받아들이고 검사를 없애는 대신 신뢰를 하나의 키로 좁히므로 피닝이 정직한 대안입니다. 이 필드들의 의미는 RFC 5280을 참조하십시오.