지원되지 않는 인증서 용도: 중간 CA가 실패하는 이유

서버 인증서의 용도는 올바르게 보이고, 키도 일치하며, 날짜도 문제없는데 연결은 여전히 unsupported certificate purpose 오류로 실패합니다. 이를 해결하는 세부 정보는 보통 오류와 같은 줄에 있습니다. 체인에서 더 위에 있는 인증서를 가리키는 깊이 값과 subject입니다. 서로 다른 두 가지 테스트가 실행되며, 리프에 관한 것은 그중 하나뿐입니다. 두 테스트를 비교하면 서버 인증서를 교체해도 아무것도 달라지지 않는 이유가 설명됩니다.

검증기가 실제로 거부한 인증서

체인은 같은 객체를 세 번 반복한 것이 아닙니다. 리프는 서버의 이름과 키를 지니고, 중간 인증서가 그것을 루트에 연결하며, 각각 고유한 유효 기간과 제약과 용도를 가집니다. 오류가 깊이를 언급할 때 그 숫자는 검증기가 구성한 체인 내의 위치를 가리키며, 서버가 예상치 못한 체인을 보낸다면 기대한 위치가 아닐 수 있습니다.

문제라고 가정한 인증서가 아니라 그 깊이에 있는 인증서의 필드를 읽으십시오. 모든 필드를 쏟아내는 대신 발급을 제약하는 두 확장을 요청하십시오. 답은 거의 항상 그중 하나에 있습니다. 확장 출력은 공유해도 안전하지만 개인 키는 절대 안 됩니다.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

지목된 인증서가 중간 인증서이고 그 확장 키 용도가 TLS 서버 인증과 무관한 것을 언급한다면, 나머지 실패는 기계적으로 따라옵니다. 체인은 OpenVPN 이 요청한 용도로 사용할 수 없습니다.

리프의 용도와 체인의 정책은 두 가지 테스트

리프 테스트는 좁은 질문을 합니다. 이 최종 엔터티 인증서가 이 이름에 대한 서버 인증을 허용합니까? 체인 테스트는 더 넓은 질문을 합니다. 경로의 모든 인증서가 그 용도를 수행할 수 있습니까? 클라이언트 인증서만 발급할 수 있는 인증 기관은 자체 서명 검사를 통과하고도 두 번째 테스트에서 실패합니다. 승인하는 경로에 애플리케이션이 필요로 하는 용도가 포함되지 않기 때문입니다. 두 테스트는 같은 단어로 실패하며 수정 방법은 전혀 다릅니다.

그래서 모든 가시적 필드가 올바른 새 리프 인증서도 즉시 실패할 수 있습니다. 그래서 수정이 보통 VPN 구성이 아니라 발급 기관의 프로필에 속합니다.

EKU가 없는 것은 제한적 EKU가 아니다

RFC 5280은 확장 키 용도 확장을 선택 사항으로 만들고, 존재할 때는 제약적입니다. 따라서 확장이 없는 CA 인증서는 서버 인증에 '아니요'라고 말하지 않았고, 무관한 용도만 나열한 인증서는 매우 구체적인 것을 말한 것입니다. 이 두 상태를 동등하게 다루면 잘못된 진단과, 더 나쁘게, 잘못된 수정이 나옵니다. 이 구분은 콘솔에서 비슷해 보이는 두 기관이 체인에서 전혀 다르게 행동하는 이유도 설명합니다.

라이브러리의 동작도 여기서는 일률적이지 않습니다. OpenSSL의 검증 옵션 문서 은 CA 인증서에 대한 용도 검사의 자체 처리를 설명하며, 그 처리는 구현 정책이지 모든 TLS 스택이 동일하게 따르는 규칙이 아닙니다. 검증기가 무엇을 하는지 설명하고, 실제로 실행하는 버전으로 확인하십시오.

다시 발급하기 전에 오프라인에서 실패를 재현하십시오

오프라인 검증은 애플리케이션을 방정식에서 제거합니다. 같은 용도에서 체인이 같은 방식으로 실패한다면 문제는 인증서이며 어떤 서버 구성도 그것을 숨기지 못합니다. 체인이 오프라인에서 통과하는데 서비스가 계속 거부한다면, 애플리케이션이 다른 용도를 요청하거나 테스트한 것과 다른 체인을 사용하는 것입니다.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain 이 중요한 이유는 도구가 구성한 경로를 출력하기 때문이며, 그것은 대개 지정한 파일 순서와 다릅니다. 그 출력은 두 번째 중간 인증서가 트러스트 저장소에서 끌어와지고 있는지, 서버가 의도하지 않은 교차 서명 변형을 보내는지, 또는 자습서에서 복사한 용도 플래그가 서비스 중인 역할과 다른 역할에 속하는지 가장 빠르게 확인하는 방법입니다.

검증 호출이 아니라 발급 정책을 고치십시오

지속적인 수정은 수행해야 할 용도를 허용하는 정책 아래 발급된 중간 인증서이며, 제약이 기록되고 검토됩니다. 모든 기관에 모든 용도를 추가하는 것은 정책이 아닙니다. 확장에 의미를 부여했던 제약을 제거하며, 보통 그것을 촉발한 사건보다 오래 남습니다. 기관이 어떤 역할을 인증할 수 있는지 적은 짧은 메모를 프로필에 두면 다음 재발급이 같은 논쟁을 반복하지 않습니다.

검증을 끄는 것은 또 다른 유혹적인 지름길이며, 인증서 문제를 신뢰 문제로 바꿉니다. 용도 검사를 그대로 두고, 체인을 고치고, 같은 오프라인 검증을 다시 실행하여 경로가 이제 의도한 역할을 수행하는지 확인한 뒤 서비스를 다시 건드리십시오.