VPN 인증서를 복사해도 키는 복사되지 않는다

이 해설은 클라이언트의 인증서 목록에서 시작한다. 그곳의 항목은 이름, 발급자, 만료일만 보여 주고 그 밖의 것은 없다. 이것을 내보내고 두 번째 기기에 가져오면, 클라이언트가 개인 키의 보유를 증명할 수 없기 때문에 연결이 거부된다. 파일은 온전히 복사되었다. 실수는 인증서가 자기 키를 함께 옮긴다고 기대한 것이다. 형식을 고르기 전에 내보내기 대화 상자를 읽고, 실제로 받은 파일을 확인하라.

두 번의 클릭, 전혀 다른 두 가지 산출물.

파일 확장자가 아니라 내보내기 대화 상자를 읽어라

DER 또는 PEM 인증서 내보내기에는 공개 키와 서명된 신원 주장이 들어 있다. 그것은 서버가 당신을 신뢰하는 데 필요하고, 클라이언트가 서버를 검증하는 데 필요한 것이다. PKCS#12 묶음은 인증서와 그 체인, 짝이 되는 개인 키를 담을 수 있는 컨테이너로 암호로 보호되지만, 키 없이도 만들 수 있다.

PEM은 텍스트 인코딩일 뿐 내용에 대한 약속이 아니다. 같은 확장자가 단일 인증서를 뜻할 수도 있고 라벨이 붙은 블록이 여러 개인 파일을 뜻할 수도 있으며, 어느 쪽인지는 내보내기 옵션이 정한다.

따라서 쓸모 있는 질문은 어떤 확장자를 받았느냐가 아니라 파일에 어떤 블록이 들어 있느냐이다. 키 없이 내보낸 묶음도 여전히 묶음이다. 형식의 인기가 아니라 내용을 확인하라.

실제로 무엇을 받았는지 확인하라

무엇이든 가져오기 전에 라벨을 찾아라. 그다음 인증서 필드를 읽어 어떤 신원을 쥐고 있는지 확인하라. 확인은 실제로 가져올 파일에서 수행하라. 다시 내보낼 때마다 반복하라. 옵션이 다를 수 있다.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

인증서 블록만 있는 내보내기는 공개 객체이며 인증할 수 없다. 인증서 없는 키 블록은 서버가 기대하는 체인을 남기지 않는다. PKCS#12 정보 출력은 키가 있는지도 알려 주므로 그 형식에 대해서는 의문이 풀린다. 알고리즘과 키 크기도 알려 주며, 키가 없으면 완전히 실패한다.

개인 키가 든 파일은 이미 공유하던 인증서처럼 보이더라도 지원 스레드, 이슈 트래커, 채팅에 절대 붙여 넣지 마라. 키 패널의 스크린샷도 같은 주의를 요한다.

키는 복사할 수 없는 곳에 살 수도 있다

관리되는 기기에서는 개인 키가 운영체제 키체인, 하드웨어 토큰, 보안 엔클레이브에 있을 수 있고, 정책이 그것을 내보낼 수 없음으로 표시한다. 그러면 인증서 관리자는 공개 객체를 보여 주고 비밀은 제자리에 남으며, 어떤 내보내기 명령도 휴대 가능한 사본을 만들지 않는다. 모바일 기기 관리로 등록하는 방식은 설계상 흔히 이렇게 동작한다.

이것은 통제이지 우회할 장애물이 아니다. 공개 인증서에서 개인 키를 재구성하는 것은 불가능하며, 그렇게 할 수 있다고 주장하는 도구는 다른 일을 하는 것이다.

복사하는 대신 새 신원을 등록하라

권장되는 길은 보통 새 기기에 별도의 신원을 등록하고, 기존 기기가 은퇴할 때 그것을 폐기하는 것이다. 그러면 각 기기를 독립적으로 회수할 수 있다. 키가 포함된 내보내기가 정말로 승인된 경우에는 결과 파일과 그 암호를 자격 증명으로 취급하라. 저장 시 암호화하고, 신뢰할 수 있는 경로로 전송하고, 등록이 끝나면 삭제하라.

가져오기가 성공하는 모습을 보는 것이 아니라, 가져온 신원으로 인증하여 검증하라. 공개 인증서를 저장소에 받아들인 클라이언트는 키에 관해 아무것도 증명하지 않았다.

서버가 새 신원을 받아들이고 기존 신원이 여전히 정책이 의도한 대로 동작하는지 확인하며 마무리하라. 그렇게 해설은 올바르게 보이는 파일이 아니라 증거로 끝난다.