AWS Client VPN: 서버 인증서와 클라이언트 인증서의 역할

Client VPN 엔드포인트에는 항상 TLS 서버 인증서가 필요합니다. 그것은 클라이언트가 접속할 때 관리형 엔드포인트가 제시하는 신원입니다. 상호 인증을 사용할 때 개별 클라이언트가 제시하는 인증서와는 다른 객체입니다. 이 둘을 뒤석으면 그 밖에는 올바른 ACM 설정이 첫 연결에서 실패하는 가장 흔한 이유가 됩니다.

여기서는 연결이 실제로 지나는 순서대로 콘솔에서 밖으로 짚어 보겠습니다.

두 가지 역할, 하나의 엔드포인트

엔드포인트는 서버 신원을 가지며, 선택적으로 클라이언트 신원을 검증하는 수단도 가집니다. 이 둘은 따로 구성합니다. 하나는 클라이언트가 서비스를 신뢰할 수 있는지를 정하고, 다른 하나는 서비스가 클라이언트를 받아들이는지를 정합니다.

표는 인증서 하나가 아니라 세 가지 독립된 요구 사항으로 읽으십시오. 서버 인증서와 그 개인 키는 서비스 쪽에 남습니다. 클라이언트 인증서와 짝을 이루는 개인 키는 기기에 있습니다. CA 자료는 검증자가 체인을 확인할 때 쓰는 것입니다. 노트북에 속하는 것은 가운데 줄뿐입니다.

ACM 서버 인증서가 하는 일

엔드포인트를 만들 때 서버 인증서는 엔드포인트와 같은 리전의 ACM에 있어야 합니다. 콘솔은 ARN을 요구하며, 그 ARN은 거기서 해석될 수 있어야 합니다. ACM에는 도메인 검증으로 발급한 인증서도, 키와 체인을 함께 가져온 인증서도 둘 수 있습니다. 둘 다 이 역할에서 동작하지만, 갱신 방식과 개인 키를 누가 보관하는지가 다릅니다.

인증서를 갱신할 수 있는 사람에 맞춰 발급 경로를 고르십시오. 우연히 유효해 보이는 파일이 나온 쪽이 아니라.

상호 인증이 더하는 것

인증서 기반 클라이언트 인증을 고르면 두 번째 질문이 더해집니다. 어느 클라이언트가 접속할 수 있는가입니다. 각 클라이언트는 자기 인증서를 제시하고 짝을 이루는 개인 키를 보유함을 증명합니다. 신원이 따로 있기에 나중에 선택적 폐기가 가능해집니다. 클라이언트 키 하나를 모든 기기에 복사하면 서버 인증서를 완벽하게 구해 두었더라도 그 성질을 조용히 버리게 됩니다.

엔드포인트의 인증 방식은 선택이지 보편적인 요구 사항이 아닙니다.

Active Directory와 연동 인증은 다른 수단으로 같은 질문에 답합니다. 상호 인증서 방식이 그러한 배포의 로그인 설계가 자동으로 되는 것은 아니며, 사용자를 어떻게 받아들이든 서버 TLS 검증은 그대로 남습니다.

같은 CA ARN이 키 공유가 아닌 이유

AWS는 서버 인증서와 클라이언트 인증서가 같은 CA에서 발급된 경우 서버 인증서의 ARN을 클라이언트 인증서 선택에도 쓸 수 있다고 문서화합니다. 그 문장은 검증할 때 엔드포인트가 어느 체인을 신뢰하는지에 관한 것입니다. 클라이언트에게 서버의 개인 키를 쓰라고 말하지 않습니다. 노트북에는 여전히 자기 클라이언트 인증서와 자기 짝 키가 필요합니다.

클라이언트 CA가 다른 발급자일 때는 그 CA를 ACM으로 가져와 클라이언트 역할에 선택하는 것이 문서화된 경로입니다.

실패를 단계까지 되짚기

무엇이든 바꾸기 전에 어느 단계가 실패하는지 판별하십시오. 클라이언트가 엔드포인트를 거부하면 서버 ARN이나 그 체인이 의심 대상입니다. 엔드포인트가 클라이언트를 거부하면 클라이언트 인증서와 발급자, 선택한 인증 방식을 보십시오. 터널이 올라오는데 트래픽이 여전히 실패한다면 인증서 문제는 이미 지난 단계입니다.

한 번에 객체 하나씩 바꾸십시오. 양쪽 끝을 동시에 바꾸면 처음의 모호함을 그대로 재현할 뿐입니다.

해당 역할에 필요한 키 알고리즘과 확장 요건도 확인하십시오. 공개 웹사이트를 만족시키는 인증서가 Client VPN의 모든 신원 요건을 충족했다는 증거는 아닙니다.

어느 필드가 어느 ARN을 담는지, 어느 CA가 클라이언트 인증서를 발급했는지, 엔드포인트가 실제로 어느 인증 방식을 쓰는지 적어 두십시오. 세 줄의 기록이 다음 갱신을 조사가 아닌 작업으로 바꿉니다.