OpenVPN이 인증서와 키를 해석하는 방식: 인라인 PEM인가 경로인가

메시지는 OpenVPN이 인라인 인증서를 로드할 수 없다고 말하지만, 머릿속에 남은 파일 이름은 다른 말을 합니다. cert 지시문이 완전히 다른 두 가지 값 유형을 받아들이기 때문에, 파일 시스템에 무엇이 있는지보다 파서가 무엇을 받았는지가 더 중요합니다. 하나는 그것이 여는 경로이고, 다른 하나는 구성 안으로 들어온 PEM 텍스트입니다. 실행 중인 클라이언트가 어느 형태를 받았는지 알기 전까지 모든 수정은 추측입니다.

두 가지 저장 형태, 하나의 지시문

cert, key, ca 지시문은 각각 경로나 인라인 블록을 받아들입니다. 값이 경로이면 OpenVPN이 그 파일을 열고 디스크에서 객체를 읽습니다. 구성에 cert 태그로 구분된 블록이 있으면 같은 지시문이 대신 그 태그 사이의 내용을 소비하며, 별도의 파일은 관여하지 않습니다.

두 형태 모두 결국 같은 종류의 객체를 만들어 내므로, 동작하는 배포는 다른 변경 없이 둘 사이를 오갈 수 있습니다. 클라이언트 인증서와 개인 키를 내장한 프로필은 자족적이며, 인증서 디렉터리를 함께 복사하지 않고도 다른 머신으로 복사하는 것이 동작합니다.

반대는 사실이 아닙니다. 자신의 데이터를 내장한 프로필 옆에 client.crt를 두어도, 구성 안의 어떤 것도 그 파일을 가리키지 않으므로 아무것도 바뀌지 않습니다. 분명히 존재하는 파일이 무시되는 것처럼 보이는 가장 흔한 이유가 이것입니다.

인라인 블록이 객체가 되는 과정

인라인 내용은 구성에서 추출되어 텍스트로 PEM 파서에 전달됩니다. 그 파서는 보통의 경계, 즉 BEGIN 줄, base64 페이로드, 그리고 대응하는 END 줄을 기대합니다. 블록이 실패한 복사로 잘렸거나, 다운로드 페이지에 의해 HTML로 감싸졌거나, 대시를 정규화한 편집기에서 열렸다면, 파서는 존재하는 것처럼 보이는 내용에서 실패합니다.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

오류 문구가 오해를 부르는 것도 같은 이유입니다. 인라인이라는 단어는 로더가 어디를 보았는지를 설명하고, 그곳에서 무엇을 찾았는지는 말하지 않습니다. 구성에 이름이 적힌 파일과 그 안에 내장된 객체는 기반 바이트를 쓸 수 없을 때 같은 불만을 만들어 낼 수 있습니다.

로드된 프로필이 실제로 어느 형태를 쓰는지, 편집기가 우연히 연 파일이 아니라 확인하십시오:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

경로 참조가 해석되는 방식

경로 값은 구성을 담은 디렉터리가 아니라 클라이언트의 작업 디렉터리를 기준으로 열립니다. systemd 아래에서 그 작업 디렉터리는 유닛이 설정한 것이고, 셸에서의 대화형 실행은 전혀 다른 것을 물려받습니다. 그래서 같은 구성 파일이 직접 시험할 때는 동작하고 서비스로는 실패할 수 있습니다.

상대 경로도 같은 모호성을 물려받습니다. 맨 파일 이름을 보면 터미널과 일치한다고 가정하지 말고, 운영 환경에서 프로세스의 현재 디렉터리가 무엇인지 물으십시오.

별도로 저장된 인증서의 경우, 그 위의 무엇이든 디버그하기 전에 오프라인 파싱이 객체를 확인합니다:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

그 명령들은 파일을 읽을 수 있고 구조적으로 유효함을 증명합니다. 상대가 발급자를 신뢰하는지, 인증서가 아직 유효 기간 안에 있는지, 키가 그 인증서에 속하는지는 증명하지 않습니다.

파서 오류가 말할 수 있는 것과 없는 것

파싱 실패는 문제를 하나의 입력과 하나의 단계로 국소화합니다. 클라이언트가 두 저장 형태 중 어느 것을 썼는지는 말하지 않고, 객체가 받아들여졌을지도 말하지 않습니다. 그것들은 별도의 증거를 가진 별도의 질문입니다.

파싱이 성공한 뒤의 다음 실패는 더 뒤 단계에 속합니다. 신뢰 거부, 목적 불일치, 키 불일치는 로더가 아니라 상대나 TLS 계층이 보고합니다. 같은 파일을 반복해서 바꿔도 그 오류는 옮겨지지 않습니다.

조사하는 동안 민감한 절반은 공개 보고서 밖에 두십시오. 지시문 이름, 오류 텍스트, 블록의 구조를 공유하고 키 자료와 식별 가능한 페이로드는 제거하십시오. openvpn(8) 설명서는 파일 지시문의 두 형태와 그 뒤에 있는 작업 디렉터리 동작을 문서화합니다.