기존 엔터프라이즈 CA를 OpenVPN 피어에 사용하십시오

OpenVPN 어디에도 인증서가 Easy-RSA에서 와야 한다고 요구하는 규정은 없으며, 이미 조직 PKI를 갖춘 플리트는 보통 두 번째를 구축해서는 안 됩니다. 진짜 작업은 도구를 고르는 것이 아니라, 발급된 아이덴티티가 무엇을 뜻하는지, 터널이 어떤 피어를 받아들이는지, 갱신과 폐기가 어떻게 검증자에게 도달하는지를 결정하는 것입니다. 아래 다섯 단계를 순서대로 진행하되, 나중 단계는 첫 단계에서 내린 역할 결정을 고칠 수 없다는 점을 유념하십시오.

하나의 공유 아이덴티티 대신 두 개의 역할을 발급하십시오

각 피어에는 자체 인증서와 그에 맞는 개인 키가 필요합니다. PKI 팀에 서버 용도를 지닌 서버 아이덴티티와 클라이언트 용도를 지닌 별도의 클라이언트 아이덴티티를 요청하여, 핸드셰이크 시 터널이 둘을 구분할 수 있게 하십시오.

마감 압박 속에서 나타나는 지름길에 저항하십시오. 웹 서버 키를 노트북에 복사하면 역할 검사가 의존하는 구분이 사라지고, VPN 엔드포인트에 설치된 CA 서명 키는 침해된 호스트 하나를 침해된 계층으로 바꿉니다. PKCS12 번들은 엔드포인트 키와 그 체인을 담을 수 있지만, 그 아이덴티티를 다른 역할에서 재사용할 권한을 결코 부여하지 않습니다.

각 측에서 신뢰 입력을 연결하십시오

클라이언트와 서버는 각각 신뢰 앵커, 자체 아이덴티티, 명시적 역할 기대를 필요로 합니다. 세 가지를 모두 명시한 클라이언트 조각은 다음과 같습니다.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

서버 측은 remote-cert-tls client 와 자체 인증서로 이를 그대로 반영하며, 이것이 클라이언트 인증서가 서버로 받아들여지는 것을 막습니다. 이름 검사는 역할 검사와 별개의 결정입니다. 브라우저식 호스트 이름 일치를 가정하지 말고 어떤 필드가 비교되는지 배포된 구성을 읽어 보십시오. 플리트 전체에서 공유된 파일 경로는 공유된 정책과 같지 않기 때문에, 양측은 어느 발급자를 신뢰하는지도 분명히 밝혀야 합니다.

신뢰를 넓히지 않고 중간 인증서를 전달하십시오

양측이 하나의 발급 체인을 공유할 필요는 없습니다. 피어가 중간 인증서로 서명된 인증서를 제시하면, 검증 측은 그 중간 인증서를 사용할 수 있어야 하며, OpenVPN은 신뢰 앵커 입력과 로컬에서 제시된 체인을 완성하는 데 쓰이는 추가 인증서를 구분합니다. OpenVPN 2.6 TLS 옵션 참조서 는 둘 다를 문서화합니다.

중간 CA 자체는 문제가 아니지만, 신뢰 번들에 던져 넣은 넓은 엔터프라이즈 루트는 문제입니다. 앵커가 넓을수록 체인 테스트를 통과하는 인증서가 많아지며, 역할 검사가 그것을 승인된 직원 목록으로 바꾸지는 않습니다. 계층이 허용하는 곳에서는 VPN 아이덴티티에 실제로 서명하는 발급자로 앵커를 좁히십시오. 허용하지 않는다면, 넓은 앵커를 암묵적으로 두지 말고 의도적으로 수용한 위험으로 문서화하십시오.

갱신과 폐기가 VPN 검증자에게 어떻게 도달하는지, 어떤 발급자가 중요한지, 누가 목록을 게시하는지를 포함해 PKI 팀과 합의하십시오. 인증서에 내장된 CRL 배포 지점은 지시일 뿐, 무언가 그것을 가져왔다는 증거가 아닙니다.

폐기가 실제로 어떻게 도달하는지 결정하십시오

crl-verify 는 검증자가 파일이나 엔드포인트를 조회하게 만들며, 그 방식에는 소유자와 갱신 경로가 필요합니다. 배포 시 한 번 복사된 목록은 인증서가 처음 폐기될 때 조용히 보호를 멈춥니다.

예상 전파 시간을 적고 폐기해도 되는 인증서로 시험하십시오. VPN 호스트에서 목록을 갱신할 수 없다면, 대안은 더 짧은 유효 기간과 실제로 작동하는 갱신 프로세스이지, URL이 있으니 폐기가 작동한다는 가정이 아닙니다.

실제 클라이언트로 수용을 증명하십시오

허용되어야 하는 클라이언트를 연결하고 로그에서 협상된 인증서 세부 정보를 확인하십시오. 그런 다음 서버로 제시된 클라이언트 인증서, 신뢰 앵커 밖의 발급자가 낸 인증서, 그리고 여분이 있다면 폐기된 인증서처럼 실패해야 하는 경우를 시도하십시오.

수용된 발급자, 역할 검사, 폐기 출처를 프로필 옆에 기록하십시오. 그 기록은 지난달까지 작동하던 장치가 연결을 멈출 때 다음 엔지니어에게 필요한 것이며, 엔터프라이즈 CA가 범용 신뢰 쓰레기장이 아니라 문서화된 수용 경계 안에서 사용된다는 증거이기도 합니다.