자체 서명 클라이언트 인증서? VPN 서버는 여전히 거부합니다
클라이언트 인증서는 서버가 신뢰하는 CA에 연결되어야 하며, 자체 서명 인증서는 결코 그렇게 되지 않습니다. CSR이 할 수 있는 일과 무엇을 요청해야 하는지 설명합니다.
운영자는 주소와 사용자 이름을 보내고, 클라이언트는 CA 파일, 인증서, 키를 요청합니다. 이 세 가지를 로컬에서 생성하는 것이 당연한 다음 단계처럼 느껴집니다. 그 결과는 여러분의 컴퓨터만 믿는 인증서입니다. 서버의 신뢰는 여러분이 통제하지 않는 CA에 고정되어 있으므로 핸드셰이크는 시작하기도 전에 끝납니다.
신뢰는 서버에 있고 프로필에는 없습니다
인증서 인증은 비교입니다. 클라이언트가 인증서를 제시하면 게이트웨이가 구성에 있는 CA 중 하나가 서명했는지 확인합니다.
프로필은 클라이언트가 서버를 검증하는 데 사용할 CA 파일을 지정합니다. 서버가 여러분을 검증하는 데 사용할 CA를 지정할 수는 없습니다. 구성의 그 절반은 여러분의 것이 아닙니다.
직접 만든 인증서는 기술적으로 완벽해도 이 비교에서 실패합니다. 유효한 서명, 주체, 날짜가 있지만 발급자는 게이트웨이가 들어본 적 없는 CA입니다. 오류는 핸드셰이크 중, 서버가 이미 인증서를 요청한 뒤에 나타납니다. 클라이언트 프로필의 어떤 것도 답을 바꿀 수 없습니다.
자체 서명 인증서가 대신할 수 없는 이유
자체 서명 인증서는 자기 키로 서명됩니다. 서명은 같은 파일에 대해 검증되므로 자기 일관적이지만 다른 사람의 게이트웨이에 대한 자격 증명으로는 쓸모없습니다.
게이트웨이는 인증서가 내부적으로 일관적인지 묻지 않습니다. 신뢰할 수 있는 발급자가 서명했는지 묻습니다.
그래서 오류 메시지가 혼란스럽습니다. 클라이언트는 서버 문제처럼 들리는 검증 실패를 보고할 수 있지만 서버는 알 수 없는 발급자를 기록합니다. 둘 다 같은 불일치를 반대쪽 끝에서 설명합니다.
CSR 경로는 개인 키를 보존합니다
작업의 대부분은 여전히 로컬에서 할 수 있습니다. 키 쌍을 만들고, 공개 절반을 중심으로 인증서 서명 요청을 만들어 운영자에게 보냅니다. 컴퓨터를 떠나는 것은 요청뿐입니다. 개인 절반은 생성한 곳에 남습니다.
openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"
운영자는 자기 CA로 요청에 서명하고 인증서를 돌려줍니다. 개인 키는 이동하지 않았고, 결과는 게이트웨이가 신뢰하는 앵커에 연결됩니다.
관리형 서비스는 종종 CSR을 생략하고 전체 번들을 발급합니다. 같은 제공자가 이미 터널을 종료하고 CA를 보유한다면 합리적인 거래입니다. 키를 보관해도 관리가 나아지지 않습니다. 제공자는 언제든 새 키를 만들 수 있기 때문입니다.
번들은 설치가 아니라 가져오기입니다
안전해 보이는 이름의 공급업체 번들은 흔히 OpenVPN 프로필입니다. 구성과 때로는 인증서를 담고 있으며 아무것도 설치하지 않습니다. 프로토콜을 사용하는 클라이언트로 파일을 가져오면 연결이 구성됩니다.
처리 규칙은 내용에서 나옵니다. 프로필에 개인 키가 포함되어 있다면 그것은 자격 증명이며 비밀번호와 같은 주의가 필요합니다. 이메일도, 저장소도, 공유 다운로드 폴더도 안 됩니다. 운영자가 ca.crt, client.crt, client.key을 따로 제공하면 제한된 권한으로 함께 보관하고 프로필이 그것을 가리키게 하세요.
운영자가 건너뛰었을 수 있는 검사를 추가하세요
라우터가 생성한 프로필에는 때때로 피어 검증이 없습니다. remote-cert-tls server은 피어 인증서가 서버 인증 용도를 가져야 한다고 요구하므로 클라이언트 인증서를 서버로 재생할 수 없습니다. 그 한 줄은 명확한 근거가 있는 작은 변경입니다.
verify-x509-name은 운영자가 예상 주체나 SAN을 지정할 수 있을 때 더 나아갑니다. 둘 다 프로필에 작은 추가이며 둘 다 정당화됩니다. 가져오기 전에 받은 내용을 확인하세요.
openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt
검증 설정은 끊어진 체인의 수리가 아닙니다. 발급자가 잘못되었다면 답은 올바른 CA의 인증서이지 검사를 끄는 플래그가 아닙니다. 검증을 끄면 인증 실패가 발견되지 않는 실패로 바뀝니다.
번들 하나를 요청하세요. PEM 형식의 기관 인증서, 그 기관이 서명한 클라이언트 인증서, 직접 생성했거나 신뢰하는 경로로 받은 키, 그리고 인증서가 제시해야 할 정확한 서버 이름이 필요합니다. 만료된 인증서는 몇 달 뒤 네트워크 장애처럼 보이므로 같은 메시지에 만료 날짜도 적으세요.