같은 ca.crt 파일 이름, 다른 인증서: 무엇을 비교할까

두 프로필 모두 ca.crt라는 파일을 제공하지만 한 터널은 올라오고 다른 하나는 체인 오류로 실패합니다. 두 파일을 나란히 열어 보는 것으로는 거의 해결되지 않고, 검증을 끄면 잘못된 방향으로 해결됩니다. 오류가 실제로 묻는 질문은 더 좁습니다: 각 프로세스가 어떤 인증서를 신뢰 앵커로 불러오는지, 그리고 둘이 같은 객체인지입니다. 먼저 이것에 답하면 나머지 진단에 방향이 생깁니다. 파일 이름은 포장 라벨일 뿐이고 프로필에 적힌 경로도 권위가 없으므로, 모든 것은 프로세스가 실제로 무엇을 읽는지에 달려 있습니다.

클라이언트가 실제로 불러오는 인증서를 찾으세요

OpenVPN은 인증 기관을 두 가지 형태로 받아들이며, 형태가 어떤 바이트가 중요한지를 결정합니다. 프로필은 ca로 외부 파일을 가리키거나, 인증서를 프로필 자체의 <ca> 블록에 내장할 수 있습니다. 둘 다 있으면 내장된 블록이 이기고 프로필 옆의 파일은 절대 열리지 않습니다.

실패하는 프로필을 읽고 무엇이든 비교하기 전에 어느 형태를 쓰는지 알아내세요. 이웃 디렉터리나 다른 프로필이 들어 있던 패키지에서 가져온 사본은 이 프로세스가 무엇을 신뢰하는지에 대해 아무것도 알려 주지 않습니다. 구성의 경로도 마찬가지로, 클라이언트가 시작된 위치를 기준으로 해석되며, 그 위치가 항상 지금 보고 있는 디렉터리는 아닙니다. 폴더가 아니라 프로필을 읽으세요.

인증서는 공개 키, 주체와 발급자, 유효 기간, 그리고 그 모두에 대한 서명이라는 내용으로 식별됩니다. 바이트가 같은 두 파일은 이름이 무엇이든 같은 인증서이고, 이름이 같은 두 파일은 서로 무관한 기관일 수 있습니다. 이름은 포장 라벨이지 신원이 아닙니다.

openssl로 두 사본의 지문을 확인하세요

지문은 인증서의 DER 인코딩에 대한 해시이며 서명이 덮는 형태이므로, 줄 끝과 헤더 텍스트가 영향을 줄 수 없습니다. 파일마다 계산하면 콜론으로 구분된 두 개의 십육진수 문자열이 나오고, 일치하거나 일치하지 않습니다. 비교 질문에 답하려면 인증서의 다른 부분을 읽을 필요가 없습니다.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

openssl를 프로필 자체로 향하게 하는 것은 솔깃하지만, 그것은 파일에서 처음 나타나는 인증서 블록을 읽으며, 프로필은 보통 <ca>보다 <cert>를 먼저 담고 있습니다. 인증 기관 블록을 추출한 다음, 클라이언트가 실제로 사용할 그 사본의 지문을 확인하세요.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

지문이 같으면 신뢰 자료가 같고 체인 오류에는 다른 원인이 있다는 뜻이며, 그것은 다른 조사입니다. 지문이 다르면 인증서가 다르다는 뜻이고, 다음 절은 거기서 시작합니다.

공격을 가정하기 전에 불일치를 읽으세요

지문이 다르면 인증서가 다를 뿐 그 이상은 아닙니다. 재발급, 교체, 이름이 바뀐 기관, 오래된 묶음은 모두 완전히 정당한 이력을 가진 다른 파일을 만듭니다. 어느 것이 배포에 속하는지는 운영자나 배포 기록에 대한 질문이고, 파일 수정 시각에 대한 질문이 아닙니다. 아카이브는 타임스탬프를 복사하므로 더 새 파일이 자동으로 올바른 앵커는 아닙니다.

스스로 서명하는 루트는 정상이므로 하나를 찾는 것이 문제의 증거는 아닙니다. 검증자의 일은 서버 인증서에서 건네받은 앵커까지 경로를 만드는 것이며, 체인 오류는 보통 그 경로를 완성할 수 없었다는 뜻입니다.

실패하는 프로필의 앵커가 배포가 여전히 발급하는 기관인지 확인하세요. 지문이 배포 기록의 어느 것과도 맞지 않으면 프로필이 단순히 오래된 것이며, 클라이언트 쪽 조정으로는 고칠 수 없습니다.

검증을 끄지 않고 신뢰를 복구하세요

단기 해결책은 검증을 끄거나 체인의 모든 인증서를 앵커로 추가하는 것입니다. 둘 다 메시지를 사라지게 하고, 둘 다 이후로 클라이언트가 어떤 서버를 받아들일지를 바꿉니다. 검증을 다시 켜고 의도한 앵커를 설치한 뒤 다시 테스트하세요.

체인이 이제 만들어지지만 다른 오류가 나타난다면 그것은 진전입니다: 이름 검증, 유효 날짜, 폐기는 각각 다른 메시지를 가진 별개의 검사입니다. 지문 쌍과 원래 오류 텍스트를 티켓에 함께 남겨 다음 사람이 어떤 앵커가 로드되었고 어떤 것이 기대되었는지 볼 수 있게 하세요. 지문 쌍은 인계 메모에 붙여 넣을 수 있을 만큼 작고, 다음 발생은 그때 반나절 대신 오 분이면 됩니다.

올바른 기관은 프로필을 전달한 것과 같은 인증된 채널로 받으세요. 주체가 익숙해 보인다는 이유로 서버에서 인증서를 끌어오는 것은 다른 행위이며, 클라이언트가 신뢰할 범위를 조용히 넓힙니다.