VPN 키 파일에서 RSA의 n, e, d, p, q는 어디에 있는가

RSA 설명에 나오는 글자는 PKI 도구가 건네는 파일이 아니라 한 객체 내부의 필드 이름입니다. 개인 키 파일은 앞쪽 필드가 공개이고 뒤쪽 필드는 터널을 끝내는 기계를 절대 떠나서는 안 되는 구조를 담습니다. 이 두 사실 사이에 어느 파일이 어느 질문에 답하는가에 관한 실무 질문의 대부분이 놓여 있습니다. 이 문서는 먼저 구조를 읽고, 다음으로 그것을 쏟지 않고 검사하는 명령을 봅니다.

소수를 찾기 전에 키가 RSA인지 확인하십시오

인증서는 어떤 키가 존재하고 서명되었다는 것을 증명하지만, 그 키가 RSA라는 것은 증명하지 않습니다. 시스템은 타원 곡선이나 Ed25519 위에 세울 수 있고, 같은 디렉터리 배치가 모두를 섬깁니다. 거기에 없었던 소인수를 찾기 시작하기 전에 알고리즘을 확인하십시오.

이 세 가지 읽기 전용 명령이 질문에 답하고 도구 버전을 기록합니다.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

버전이 중요한 이유는 옵션 이름이 주 버전 사이에서 옮겨 다녔기 때문입니다. 인증서 출력에서 공개 키 알고리즘 줄과 키 크기를 찾고, 키 출력에서 RSA 키는 모듈러스와 공개 지수를 인쇄합니다. 타원 곡선 키는 대신 이름이 붙은 곡선을 인쇄하며, 아무리 찾아도 거기서 n이나 q가 나오지 않습니다.

base64가 아니라 구조를 읽으십시오

PEM은 헤더 줄로 감싼 base64이며, 디코딩하면 DER, 즉 거대한 정수가 아니라 직렬화된 구조가 됩니다. RSA 개인 키는 PKCS#1과 PKCS#8이라는 두 가지 흔한 컨테이너로 다니고, 둘 다 같은 수 집합으로 풀립니다.

소수가 둘인 경우 개인 구조는 아홉 개 필드를 담습니다: 버전, 모듈러스 n, 공개 지수 e, 개인 지수 d, 소수 p와 q, 두 CRT 지수, 그리고 CRT 계수입니다. RFC 8017 A.1절이 이 구성 요소와 ASN.1 배치를 정의하며 소수가 둘보다 많아도 허용하므로, 일반 파서는 소수 항목을 더 인쇄할 수 있습니다. 순서에 주목하십시오, 흔한 실수는 공개 절반이 개인 파일 안에 저장되므로 공개 필드가 있다고 해서 그 파일을 공유해도 안전해지지 않는다는 점입니다. 그 뒤에 오는 모든 것이 호스트에 남아야 할 재료입니다.

인코딩은 내용과 혼동하기 쉬운 층을 더합니다. openssl asn1parse 구조를 나무처럼 그려 필드 순서가 보이게 하지만, 아무것도 복호하지 않고 키가 쓸 만한지도 말하지 않습니다.

키를 출력하지 않고 인증서와 키를 짝지으십시오

다음 질문은 보통 인증서와 키가 한 쌍인지입니다. 모듈러스를 비교하면 그 답이 나오지만, 개인에 가까운 재료를 터미널 기록으로 복사해 티켓에 남을 수도 있습니다. 공개 절반을 비교하면 화면에 민감한 것을 두지 않고 같은 질문에 답할 수 있습니다.

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

파일이 같다면 인증서가 그 키의 공개 절반을 담고 있다는 뜻이고, 다르다면 잘못된 짝을 들고 있다는 뜻입니다. 이 불일치가 협상은 잘 되는데 인증에서 거부되는 터널의 가장 흔한 원인입니다. 그다음 임시 파일 두 개를 지우십시오, 비밀은 없지만 사고 중간에는 작업 디렉터리가 깨끗한 편이 생각하기 쉽습니다.

이웃 파일이 무엇이 아닌지 아십시오

인증서는 상대가 CA 인증서로 여는 암호화된 공개 키가 아니라, 공개 키와 신원 데이터 사이의 서명된 결속입니다. CA의 개인 서명 키는 자기 인증서와 모든 클라이언트 키와 별도로 유지됩니다. 요청도 인증서가 아니며, 요청된 정보와 공개 키를 요청에 대한 서명과 함께 담으므로 등록 입력일 뿐 권리의 증거는 아닙니다.

그 항목 중 둘은 RSA 매개변수와 자주 혼동되어 두 번 이름을 붙여야 합니다. Diffie-Hellman 매개변수 파일은 키 수립을 위한 그룹 매개변수를 담고 RSA 소수는 담지 않습니다, 큰 소수로 인쇄되더라도 마찬가지입니다. 폐기 목록은 인증서 상태를 공개하는 것이지 개인 지수가 숨을 곳이 아닙니다.

그러므로 재고 한 줄은 네 가지를 기록해야 합니다: 객체 유형, 소유자, 목적, 그리고 개인 재료가 포함되었는지 여부입니다. 마지막 열이 파일을 어디로 복사해도 되는지 결정하며, 사람들이 바로 그 열을 건너뜁니다.

짝을 기록한 다음 핸드셰이크를 검증하십시오

무엇이든 바꾸기 전에 검증 출력을 날짜와 OpenSSL 버전과 함께 저장하십시오. 그러면 나중의 교체를 기억이 아니라 증거와 비교할 수 있습니다.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

공개 키 비교 뒤에는 그 짝을 소비하는 경로를 실제로 지나가십시오: 터널을 올리고, 인증서가 제시되고 수락되는지 확인하고, 게이트웨이가 어느 신원을 기록했는지 보십시오. 키와 인증서가 맞는데도 인증이 실패한다면 결함은 짝이 아니라 신뢰, 신원 매핑, 접근 정책 쪽에 있습니다.

되돌리기를 위해 이전 키와 인증서를 날짜가 붙은 디렉터리에 두고 반드시 둘을 함께 복원하십시오, 하나만 복원하는 일은 없어야 합니다. 인증서 없는 키와 키 없는 인증서는 밖에서 보면 똑같이 실패하므로, 절반만 복원한 짝은 새벽 두 시에 풀기가 비쌉니다.