네 가지 질문을 순서대로 짚으면 CA 대화 상자는 더 이상 모호하지 않다. 운영자가 실제로 발급한 재료는 무엇인지, 프로필이 이미 무엇을 담고 있는지, 어느 필드가 묻는지, 파일을 불러온 뒤 무슨 일이 일어나는지. 운영자 자신의 지침으로 답할 수 없는 첫 질문에서 멈춰라 — 그 너머를 추측하는 것이 바로 공개 CA 인증서가 서버를 떠나서는 안 될 개인 키와 짝지어지는 경로이기 때문이다.

순서가 중요하며, 마지막 두 질문은 어떤 재료가 있어야 하는지 안 뒤에야 의미가 있다.

프로필이 이미 담고 있는 것부터 시작하라

텍스트 편집기에서 프로필을 열고 파일을 찾기 전에 ca 블록을 찾아라. 운영자의 공개 CA를 담은 인라인 ca 블록은 프로필이 자족적이라는 뜻이고, 그래도 CA 파일을 요구하는 클라이언트는 다른 프로필이나 불완전한 가져오기를 읽고 있을 수 있다. 대신 경로를 가리키는 ca 줄이 있다면 그 경로는 일부 통합에서는 클라이언트 작업 디렉터리에 상대적이고 다른 곳에서는 절대적이다. 무엇이든 바꾸기 전에 어느 형태인지 기록하라.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

프로필이 참조하는 파일에 대해 전달된 패키지를 확인하라: CA 인증서, 때로는 별도의 클라이언트 인증서와 키, 그리고 tls-auth 또는 tls-crypt 파일이 있을 수 있다. 네 파일을 참조하면서 두 개만 도착한 프로필은 불완전하고, 필드를 가리키는 것으로는 고칠 수 없다. 우연히 가진 인증서로 대체하지 말고 운영자에게 빠진 부분을 요청하라.

네 가지 재료 유형을 구분하라

CA 인증서는 서버의 신원을 검증하는 데 쓰이는 공개 재료다. 클라이언트 인증서는 사용자나 기기를 서버에 식별시킨다. 개인 키는 그 클라이언트 인증서의 비밀 절반이며, CA의 서명 키나 서버 키가 되어서는 안 된다. tls-auth 또는 tls-crypt 재료는 제어 채널을 보호하는 별도의 공유 비밀이다. 이 넷은 서로 바꿀 수 없고, CA 필드를 클라이언트 인증서로 향하게 하면 신뢰 문제처럼 보이는 검증 실패가 생긴다.

비밀번호만 쓰는 인증은 넷 중 무엇이 필요한지를 바꿀 뿐 의미를 바꾸지 않는다. auth-user-pass 와 remote-cert-tls server 가 있어도 클라이언트는 여전히 CA를 기준으로 서버를 검증하므로 클라이언트 인증서가 없어도 CA 필드가 나타난다. 클라이언트 인증서도 필요한지는 운영자의 정책이 정하며, 어떤 대화 상자도 그것을 알려주지 않는다.

클라이언트를 신뢰 파일로 향하게 하라

CA 인증서 파일 자체를 선택하라: 그것을 담은 폴더도, 클라이언트 신원을 담은 .p12 번들도 아니다. Windows에서는 경로 구문과 파일 선택기가 대부분 안내서의 Linux 예와 다르게 동작하므로 설치된 클라이언트가 받아들이는 방식을 쓰고, 실행하는 계정이 파일을 읽을 수 있는지 확인하라. 권한 문제와 없는 파일은 대화 상자에서 같아 보이지만 로그 줄은 다르다. 선택한 뒤 프로필 설정을 다시 열어 클라이언트가 선택을 유지했는지 확인하라.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

클라이언트가 인라인 블록을 지원하면 손으로 조립한 프로필보다 운영자의 인라인 프로필을 선호하라. 인라인 재료는 프로필과 함께 이동하고 다시 가져와도 살아남지만, 절대 경로는 프로필이 다른 기기로 옮겨지는 순간 깨진다.

같은 오류가 아니라 다음 오류를 읽어라

올바른 CA를 제공하는 목적은 오류를 바꾸는 것이지 없애는 것이 아니다. CA를 불러온 뒤의 서버 신원 실패는 인증서가 기대한 이름이나 remote-cert-tls 기대와 맞지 않았다는 뜻이며, 비밀번호 거부와는 다른 수리다. 비밀번호 거부는 TLS 계층이 성공했고 자격 증명이 틀렸다는 뜻이다. 첫 번째 새 메시지를 남겨라, 그것이 유용하다.

연결되지만 아무 곳에도 닿지 못하는 클라이언트는 신뢰를 완전히 지나 라우팅이나 DNS 질문에 직면한다.

그 대화 상자를 통과하려고 검증을 끄지 마라. 어떤 인증서든 받아들이는 클라이언트는 CA를 요구할 이유가 없고, 그것이 만드는 터널은 운영자가 의도한 터널이 아니다.

관련 글