변환하기 전에: SSH 키와 OpenVPN 인증서

인증서 오류로 가져오기가 실패하면, 당연해 보이는 조치는 변환처럼 보입니다. 그 본능은 파일 확장자만 바뀌고 거부는 정확히 그대로인 길로 사람들을 이끕니다. authorized_keys의 ssh-ed25519 줄과 OpenVPN 클라이언트 인증서는 별개의 자격 증명 객체이며, 발급자도 인코딩도 철회 경로도 다릅니다. 이 점검들을 순서대로 해 보면 변환이 애초에 도움이 되는지 일 분 안에 알 수 있습니다.

실제로 어떤 객체를 가지고 있습니까?

사람들이 키라고 부르는 것은 다섯 가지이고, 그중 TLS 프로필이 원하는 것은 하나뿐입니다. SSH 공개 키는 유형 접두사와 base64 페이로드가 있는 한 줄의 텍스트입니다. OpenSSH 인증서는 그 키에 서명, principals, 옵션을 더한 것으로, ssh-keygen이 작은 CA 역할을 하며 만듭니다. X.509 인증서는 전혀 다른 구조로, 주체, 유효 기간, 확장, 인증 기관의 서명을 담습니다. 개인 키는 비밀스러운 절반이고, 발급된 번들은 보통 하나의 파일에 인증서와 그 체인과 개인 키를 담습니다.

첫 번째 시험은 명령 하나면 됩니다. openssl을 파일로 지정하고 인증서 구조를 분석하게 하십시오:

openssl x509 -in client.crt -noout -subject -issuer

이것이 로드 불가 또는 PEM 오류로 실패하면, 어떤 이름을 붙였든 그 파일은 X.509 인증서가 아닙니다. 이름을 바꾼다고 안쪽의 ASN.1이 다시 쓰이지 않으며, 공개 키 줄을 PEM 헤더 텍스트로 감싸도 마찬가지입니다.

프로필이 인증서를 요구하기는 합니까?

클라이언트 인증서는 여러 인증 방식 중 하나이며, 잘 동작하는 많은 TLS 프로필은 결코 그것을 요구하지 않습니다. 서버는 플러그인, 사용자 이름과 비밀번호, 또는 토큰 백엔드로 사용자를 인증하면서도 클라이언트에게 서버의 신원 확인을 요구할 수 있습니다. 프로필에 클라이언트 인증서 지시문이 없으면 인증서는 결코 요구되지 않으며, 어떤 변환도 게이트웨이가 그것을 요구하게 만들지 못합니다.

오래된 정적 키 구성은 또 다른 경우입니다. 그것은 TLS 핸드셰이크보다 앞선 것으로 미리 공유된 비밀 파일을 기대하며, 그래서 그 필드에 공개 키를 붙여 넣는 것도 동작하지 않습니다. 자격 증명이 틀렸다고 판단하기 전에 프로필이 실제로 무엇을 요구하는지 읽으십시오.

재인코딩이 할 수 있는 것과 없는 것

개인 키에는 정당한 대체 컨테이너가 있습니다. 같은 RSA 또는 EC 키를 전통적인 PEM, PKCS#8, 또는 PKCS#12 번들 안으로 쓸 수 있고, 도구들은 그것들 사이를 기꺼이 변환합니다. 공개 키도 사정이 비슷한데, ssh-keygen은 SSH 키의 RFC 4716 형식을 낼 수 있고 OpenSSH는 자체 인증서 형식도 이해합니다. 그 모두는 표현이며, 표현은 신뢰가 아닙니다.

변환이 할 수 없는 것은 당신의 키를 본 적 없는 인증 기관의 서명을 만들어내는 것입니다. 인증서는 특정 공개 키가 특정 목적을 위해 특정 주체에 속한다는 발급자의 단언입니다. 재인코딩은 키의 바이트를 보존하고 그 단언을 없는 채로 두므로, 게이트웨이가 자체 신뢰 저장소와 대조할 것이 없습니다.

대부분의 시도가 조용히 실패하는 지점이 여기입니다: 파일이 이제 .crt로 끝나고, 클라이언트는 불평 없이 읽고, 그래도 핸드셰이크는 중단됩니다——상대편이 신뢰할 수 있는 발급자까지 체인을 만들 수 없기 때문입니다.

인증 기관이 개입하는 지점

실제 등록은 당신이 통제하는 키 쌍과 운영자가 기대하는 주체를 담은 인증서 서명 요청에서 시작합니다. 운영자는 자격을 확인하고, CA 키로 요청에 서명하며, 발급된 인증서를 클라이언트가 제시해야 하는 중간 체인과 함께 돌려줍니다. 그다음 클라이언트에는 그것에 서명한 CA 인증서가 필요합니다——대화 상대인 서버가 같은 배포에 속한다고 확인할 수 있게 하는 것이 바로 그것이기 때문입니다.

그 마지막 파일은 잊기 쉽고 대체할 수 없습니다. CA의 서명 키 자체는 결코 클라이언트 구성에 속하지 않으며, 아무리 로컬에서 변환해도 받아야 했던 체인은 만들어지지 않습니다.

SSH 키를 재사용할 때 치르는 비용

어떤 변환이 정말 받아들일 만한 것을 만들어 냈다고 칩시다. 하나의 키 쌍을 SSH 접근과 VPN 인증에 재사용하는 것은 여전히 두 개의 독립적인 보안 결정을 묶습니다. authorized_keys의 항목을 지우면 SSH 로그인이 멈추지만, 같은 공개 키에 대해 VPN CA가 이미 발급한 인증서에는 아무 효과가 없습니다. VPN 쪽은 자체 메커니즘, 즉 인증서 폐기 목록이나 운영자의 등록 기록을 통해 철회됩니다.

그래서 점검 목록은 요령이 아니라 정지 조건으로 끝납니다. openssl이 파일을 인증서로 분석하지 않으면 변환을 멈추고 무엇을 가지고 있는지 설명하십시오: SSH 키, SSH 인증서, X.509 인증서, 개인 키 또는 번들입니다. 프로필이 클라이언트 인증서를 요구하지 않으면 멈추고 서버가 어떤 인증 방식을 기대하는지 물으십시오. 두 답이 모두 X.509를 가리킬 때만 등록이 다음 단계가 되며, 첫 문장에 정확한 명사가 있으면 그 대화는 훨씬 빠르게 진행됩니다.