OpenVPN 프로필의 서로 다른 세 부분이 서로 다른 세 질문에 답하며, 이를 뒤섞는 것이 바로 사람들이 작동하던 검사를 꺼버리는 방식입니다. 상대방 인증서가 내가 신뢰하는 기관에 의해 서명되었는가? 그 인증서가 TLS 서버 역할을 선언하는가? 내가 도달하려던 바로 그 서버인가? remote-cert-tls server는 가운데 질문에만 답하며, 인증서 내부의 확장을 읽어 그렇게 합니다.

머릿속에서 뒤섞기 쉬운 세 가지 검사

신뢰 앵커는 ca 지시문에 있습니다. 역할 검사는 remote-cert-tls에 속합니다. 신원 검사는 프로필이 그것을 사용할 때 verify-x509-name에 속하며, 아니면 배포가 추가하는 어떤 이름 검사에 속합니다.

이들은 서로 다른 실패를 다룹니다:

QuestionDirectiveFailure it catches
Who signed this?caCertificate from an unrelated authority
Is this a server?remote-cert-tlsClient certificate presented by a peer
Is this my server?verify-x509-nameAnother valid server from the same CA

프로필이 세 가지를 모두 갖추고도 CA가 너무 넓게 공유되면 여전히 약할 수 있으며, 이는 지시문이 아니라 키 관리의 문제입니다.

역할 검사가 읽는 것

이 지시문은 매크로입니다. 키 사용 요구 사항과 TLS 웹 서버 역할을 명시하는 확장 키 사용 요구 사항으로 확장되므로, 상대방 인증서는 실제로 그 목적을 선언해야 합니다. 클라이언트 인증을 위해 발급된 인증서는 같은 기관이 둘 다 서명했더라도 이를 충족하지 못합니다.

이는 작은 배포에서 공유 CA가 흔하기 때문에 중요합니다. 한 기관이 모든 클라이언트와 서버에 서명하며, 역할 검사가 없으면 그 인증서 중 어느 것이든 핸드셰이크의 서버 측을 완료할 수 있었습니다. 검사는 그 시나리오를 불가능하게 만들지는 않지만, 그 사소한 버전을 제거합니다.

이 지시문은 설계상 비대칭으로, 클라이언트는 remote-cert-tls server를 지니고, 서버는 remote-cert-tls client를 지닙니다. 둘을 바꾸면 모든 연결이 깨진 인증서처럼 보이는 역할 오류로 실패합니다.

오래된 프로필은 같은 목적으로 ns-cert-type를 사용하기도 합니다. 현재 매뉴얼 페이지는 그 옵션을 대체된 것으로 취급하므로, 여전히 그것에 의존하는 프로필은 디버깅보다 마이그레이션할 가치가 있습니다.

비활성화가 수정처럼 느껴지는 이유

역할 검사가 실패하면 연결이 검증 오류로 멈추고, 분명한 조치는 그 줄을 지우는 것입니다. 그러면 연결이 올라오며, 이는 진전처럼 느껴지지만 실제로는 이 지시문이 막으려는 실패 모드입니다. 이제 당신은 그 역할을 위해 만들어진 적 없는 인증서를 가진 상대를 받아들이게 됩니다.

대신 오류를 읽으십시오. 어떤 검사가 실패했는지 말해 주며, 반대편 인증서를 조사하면 실제로 어떤 확장을 지니는지 알 수 있습니다. 두 분의 읽기로 결함이 발급인지 구성인지 결정됩니다. 추측은 반나절을 쓰고 보통 약화된 프로필로 끝납니다. 확장 키 사용을 잃은 갱신된 서버 인증서는 갱신의 실제 결함이며, 클라이언트를 느슨하게 할 이유가 아닙니다.

이름 검사는 별도의 지시문

역할 검사를 만족한다는 것은 상대가 당신의 기관이 서명한 어떤 서버라는 뜻입니다. 어느 서버인지는 말하지 않으며, 같은 CA가 여러 게이트웨이에 인증서를 발급하고 그중 하나가 침해되거나 용도가 바뀌었을 때 중요합니다.

verify-x509-name는 인증서 주체를 당신이 구성한 값과 비교하며, 정확한 주체, 접두사 또는 단일 필드에 대한 일치 모드를 제공합니다. 게이트웨이를 실제로 식별하는 필드를 사용하고, 이름이 바뀌면 의도적으로 업데이트할 것을 예상하십시오.

어느 지시문도 좋은 키 처리를 대체하지 않습니다. 클라이언트 키 파일이 프로필과 함께 복사되어 돌아다니면, 상대의 신원은 배포 목록만큼만 강합니다.

프로필을 편집하기 전에 인증서를 검사하십시오

상대방 인증서와 클라이언트 로그를 그 순서로 읽으십시오. 인증서는 어떤 역할을 선언하는지 알려 주고, 로그는 어떤 검사가 그것을 거부했는지 알려 줍니다.

이 명령들은 상세 연결에서 사용 확장과 검증 줄을 출력합니다:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

확장이 서버 역할을 보여 주는데 로그가 여전히 역할 실패를 보고하면, 프로필은 나쁜 인증서가 아니라 잘못된 인증서 파일을 가리키는 것일 가능성이 큽니다. 확장이 클라이언트 인증만 보여 주면 클라이언트를 보는 것을 멈추고 발급을 고치십시오. 어느 경우든, 검증을 제거한 뒤의 성공적인 핸드셰이크는 그것이 대체한 오류보다 적게 증명하므로, 연결을 건강하다고 부르기 전에 검사를 복원하십시오.

관련 글