구형 P12 파일이 OpenSSL 3에서 실패할 때: 잘못된 암호인가, 구형 암호화 방식인가?
잘못 입력한 암호와 OpenSSL 3가 풀지 못하는 구형 RC2 번들을 구분하고, 키 보호를 제거하지 않은 채 파일을 다시 봉인하세요.
가져오기 대화 상자가 암호를 받아 잠시 돌다가 번들을 읽을 수 없다고 알려 줍니다. 그 메시지 어디에도 암호를 잘못 입력한 것인지, 클라이언트가 더 이상 제공하지 않는 암호화 방식으로 파일이 봉인된 것인지는 나오지 않습니다. 둘은 서로 다른 실패이고 고치는 방법도 다르며, 잘못 고르면 클라이언트를 낮춰 결정을 미룰 뿐입니다. 클라이언트가 어느 단계에서 멈추는지 보면 약 일 분 만에 둘을 구분할 수 있습니다.
대화 상자와 인증서 목록 사이에서 벌어지는 일
.p12 파일은 인증서가 아니라 컨테이너입니다. 안에는 하나 이상의 인증서 백과 암호에서 파생한 키로 암호화된 개인 키 백, 그리고 파일 전체에 대한 MAC이라는 무결성 검사가 들어 있습니다. 여는 일은 그 MAC을 검증하고, 키 백을 복호화하고, 인증서를 꺼낸 키와 맞추는 것을 뜻합니다.
암호 문제는 MAC 단계에서 나타납니다. 암호화 방식 문제는 그 뒤, 키 백을 풀어야 할 때 풀어 내는 빌드에 파일에 적힌 알고리즘 구현이 없을 때 나타납니다.
두 번째 경우는 요즘 시스템에서 흔한데, OpenSSL 3가 오래된 알고리즘 묶음을 선택적 legacy provider로 옮겼기 때문입니다. OpenSSL 1.x에서 내보낸 번들은 보통 인증서를 40비트 RC2로, 개인 키를 세 개의 키를 쓰는 Triple DES로 봉인했습니다. 기본 OpenSSL 3 빌드는 올바른 암호로도 MAC을 검증한 뒤 백에서 실패하므로, 암호는 처음부터 틀린 적이 없고 다시 입력해도 달라지는 것이 없습니다.
키를 꺼내지 않고 컨테이너 읽기
자신의 컴퓨터에 있는 OpenSSL 빌드에 파일을 분석해 어디서 포기하는지 읽어 보라고 하세요. 출력 파일 없이 검사하면 키가 디스크에 암호화된 채로 남는데, 이 단계를 공유 호스트에서 실행해도 안전한 이유는 그것뿐입니다.
openssl pkcs12 -in vpn-identity.p12 -info -noout올바른 암호를 가진 구형 번들이라면 백 속성을 출력한 뒤 digital envelope routines::unsupported와 함께 멈춥니다. 암호가 틀리면 백을 읽기도 전에 Mac verify error: invalid password?가 나옵니다. 두 메시지는 서로 반대 방향을 가리키며, 바로 그 정보를 클라이언트가 숨겼던 것입니다.
실패가 지원되지 않는 알고리즘 쪽이라면 같은 명령에 -legacy만 더하고 다른 것은 바꾸지 말고 다시 실행하세요. 그 플래그는 해당 프로세스 하나에만 legacy provider를 불러옵니다. VPN 클라이언트가 구형 번들을 분석하게 만들지도, 시스템 전반의 암호 정책을 건드리지도 않으며, 파일은 여전히 교체해야 하므로 고침이 아니라 측정입니다.
어떤 오류가 어느 단계인지
짧은 표가 세 결과를 구분해 주며, 대화 상자가 어디에 나타났는지보다 문구가 더 중요합니다.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data나 header too long 같은 문구는 앞의 두 묶음 어디에도 속하지 않습니다. 그것은 형식 문제입니다: .pem으로 이름만 바꾼 DER 파일, 줄 끝을 다시 쓴 편집기로 망가진 사본, 또는 끝까지 받지 못한 다운로드입니다. 암호화 방식을 들여다보기 전에 발급자가 보낸 체크섬과 비교하세요.
Mac verify error는 암호에 대한 증거로만 받아들이세요. 입력한 값으로 계산한 MAC이 저장된 값과 맞지 않는다는 뜻이며, 오타, 이전 가져오기에서 캐시된 암호, 다른 암호로 다시 내보낸 파일에서 생깁니다. 안에 든 알고리즘이 오래되었는지에 대해서는 아무것도 말해 주지 않습니다.
클라이언트가 실제로 열 수 있는 번들 만들기
legacy 파서가 파일이 온전하다고 확인하면, 오래가는 해결책은 대상 클라이언트가 지원하는 알고리즘을 쓰는 교체본입니다: 키와 인증서 백에는 AES-256-CBC, 파생에는 SHA-256을 쓰는 PBKDF2, MAC에는 SHA-256입니다. PKI 관리자가 같은 키 자료에서 그것을 내보낼 수 있고, 안의 인증서는 서버가 이미 신뢰하는 그대로 남습니다.
로컬에서 변환해야 한다면 pkcs12 도구에 백을 먼저 덤프하지 말고 다시 봉인하라고 요청하세요. 두 암호 모두 파일에서 읽어 셸 기록에 남기지 마세요.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.pass변환에 성공해도 만료, 키 용도, 개인 키 일치, 서버가 발급 체인을 신뢰하는지에 대해서는 아무것도 알 수 없습니다. 다시 포장하는 것은 전달 방식의 변경이지 갱신이 아니며, 그 각각은 여전히 따로 확인해야 합니다.
클라이언트가 파일을 받아들였다는 이유만으로 보호되지 않은 중간 키를 기록하거나 출력 암호를 비우는 방법은 건너뛰세요. 보호를 벗겨 낸 읽히는 번들은 처음 겪은 가져오기 실패보다 나쁜 결과입니다.
클라이언트가 직접 만든 파일을 가져왔는지 확인
터미널에서 깨끗하게 분석된다는 것은 컨테이너가 유효하다는 증거일 뿐, 클라이언트가 그것을 선택했다는 증거는 아닙니다. 남은 프로필이 옛 파일을 계속 가리킬 수 있고, 일부 클라이언트는 가져온 신원을 사용자가 고르지 않은 이름으로 캐시하기 때문입니다.
가져오려는 신원을 출력해 클라이언트의 인증서 보기에 나오는 내용과 비교하세요.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256먼저 낡은 프로필 항목을 지운 뒤 가져오세요. 클라이언트가 불러온 주체나 지문을 기록한다면 위 줄과 맞춰 보고, 친숙한 이름만 보여 준다면 같은 발급자의 다른 인증서와 혼동하기 어려운 만료 날짜를 대신 확인하세요.
PKCS12 참조 문서에 여기서 쓴 provider, 암호, 출력 옵션이 나와 있습니다. legacy provider를 클라이언트 환경 밖에 두는 것이 핵심입니다: 그것으로 측정하고, 빼고 출시하며, 개인 키는 디스크에서 보호된 채로 두세요.