OpenVPN verify-x509-name: subject, name, name-prefix의 차이

먼저 일치 유형을 읽고 그다음 본문을 읽는다: verify-x509-name 지시자는 올바르게 보이면서도 신뢰하려 하지 않았던 인증서를 받아들일 수 있다. 기대 텍스트는 같지만 유형이 다른 두 줄은 서로 다른 요구 사항이다. 유형을 먼저 읽고 그다음 본문을 읽는다. 지시자를 연결에 대한 또 하나의 조건으로 다루고, 검사 전체로 보지 않는다.

이 옵션이 실제로 주장하는 것

지시자는 상대방 인증서가 지녀야 할 신원을 지정한다. 비교가 실패하면 OpenVPN 은 핸드셰이크를 중단하고 터널은 올라오지 않는다. 프로필의 나머지 모든 것은 여전히 적용된다: 인증서는 신뢰할 수 있는 CA로 연결되어야 하고 역할 검사도 통과해야 하므로, 이것은 대체가 아니라 추가 조건이다. 이름 기대를 만족해도 역할 검사에서 실패하는 프로필은 여전히 깨진 상태이며, 로그는 대개 그렇게 말한다.

이는 브라우저가 하는 호스트 이름 검증과도 다르다. 브라우저는 자체 TLS 스택 규칙에 따라 이름을 subject의 대체 이름과 대조하는 반면, OpenVPN은 선택한 유형으로 인증서의 필드 하나를 비교한다. 그래서 브라우저식 호스트 이름을 지시자에 붙여 넣으면 인증서가 실제로 서비스를 포함하더라도 불일치가 생길 수 있다.

subject: 전체 식별 이름, 문자 단위로

유형이 적히지 않았을 때 기본값은 subject 이며, 기대 값은 인증서의 전체 subject DN을 재현해야 한다. 필드 순서, 구분자, 공백, 이스케이프가 모두 계산되는데, 비교가 인코딩된 그대로의 문자열에서 이루어지기 때문이다. 유형을 생략하면 세 비교 중 가장 엄격한 것을 고른 셈이다. 겉모양 차이를 구해 주는 정규화 단계는 없다. 첫 갱신 전에 알아 둘 일이지, 그 뒤에 알 일이 아니다.

그 엄격함은 갱신 사이에서 취약하다. 속성을 재정렬하거나, 여분의 필드를 넣거나, 값의 이스케이프 방식을 바꾸는 CA는 같은 기계에 대해 새로운 문자열을 만들고, 수년간 작동하던 지시자가 다음 발급에서 실패하기 시작한다. 받아들인 DN을 변경 기록에 남기면 다음 갱신은 차이가 된다. 운영자가 전체 DN을 공개하고 그 형태를 보증한다면 subject는 합리적인 선택이고, 그렇지 않다면 좁은 필드가 진실을 유지하기 쉽다.

name: 하나의 필드, 보통 일반 이름

유형 name 은 subject의 필드 하나를 비교한다. 프로필이 달리 말하지 않는 한 그 필드는 일반 이름이며, 기대 값은 바로 그 필드이지 그 주변의 DN이 아니다.

함정은 현대 인증서가 서비스 이름을 항상 CN에 두지는 않는다는 점이다. 많은 인증서가 그것을 subject의 대체 이름에 담고 CN은 비우거나 일반적으로 두므로, 브라우저가 받아들이는 인증서도 이 비교에서 실패할 수 있다. 기대를 쓰기 전에 실제로 발급받은 인증서를 살펴보고 프로필이 어느 필드를 선택하는지 확인한다. 빈 CN과 이름의 비교는 불일치이지 구성 사고가 아니다.

name-prefix: 설계상 넓으므로 범위를 정한다

유형 name-prefix 의 기대는 선택된 필드의 시작과 일치한다. 이는 명명 체계에는 편리하고 공유되는 무엇에도 위험하다.

기대를 vpn.example 로 두면, vpn.example.com 와 vpn.example.net 가 모두 통과한다, 체인의 나머지가 신뢰된다면. 넓이가 특징이며 동시에 글로 정당화해야 하는 부분이다. CA와 명명 체계가 자신의 것이라면 접두사는 합리적이고, 공개 CA가 같은 패턴으로 발급한다면 훨씬 약하다. 체계에 유연성이 필요하면 클라이언트 검사를 넓히는 대신 CA에서 제한한다.

식별자에서 유형을 고르고, 그다음 증명한다

운영자가 의도하는 신원에서 거꾸로 작업한다. 전체 DN을 공개하고 안정적으로 유지한다면, subject 이 그것을 표현한다. 서비스를 일반 이름으로 부른다면, 사용한다 name. 명명 체계를 소유하고 그 전체 공간을 받아들인다면, name-prefix 이 그것을 분명히 말한다.

갱신이야말로 지시자가 시험되는 자리다. 승인된 신원을 예전 파일이 아니라 새 인증서와 비교한다, 새 엔드포인트 주소가 새 인증서 신원을 뜻하지는 않으므로. 익숙한 주소가 응답한다는 이유만으로 지시자를 지우지 않는다: 도달 가능성과 의도한 상대는 서로 다른 사실이다 , 그리고 주소는 무언가가 응답했다는 것만 증명한다. 정확한 오류와 공개 이름 세부 정보를 정리된 보고서에 기록한다, 이름 불일치는 어떠한 개인 키 자료 없이도 보여 줄 수 있기 때문이다.

지원되는 수정 후에는 의도한 모든 검사를 켠 채 다시 연결하고 실제로 필요한 리소스를 검증한다. 성공은 의도한 서버가 받아들여졌다는 뜻이지, 어떤 인증서가 억지로 통과되었다는 뜻이 아니다. 공식 매뉴얼인 OpenVPN 2.6 manual 은 세 가지 유형과 그 신뢰 주석을 문서화하며, 공급업체 인터페이스가 프로필과 어긋날 때 인용할 참고 자료다.