☰

openssl s_client가 일치하지 않는 CA 파일에 대해 인증서의 유효성을 검사하는 이유는 무엇입니까?

tag-icon • tag-icon openssl certificates gnutls
openssl s_client가 일치하지 않는 CA 파일에 대해 인증서의 유효성을 검사하는 이유는 무엇입니까?

다음과 같은 인증서 확인 오류를 생성하려고 합니다 openssl s_client.

$ openssl s_client -crlf -verify 9 \
  -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
  -starttls smtp -host mx-ha03.web.de -port 25

web.de 서버의 인증서는 TURKTRUST가 아닌 Deutsche Telekom CA에서 인증한 것이므로 위의 명령은 실패해야겠죠?

그러나 다음과 같이 보고됩니다.

    Verify return code: 0 (ok)

왜?

내 말은 시뮬레이션된 gnutls-cli 명령이 예상대로 실패한다는 것입니다.

$ { echo -e 'ehlo example.org\nstarttls' ; sleep 1 } | \
   gnutls-cli --starttls --crlf \
   --x509cafile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
   --port 25 mx-ha03.web.de
[..]
*** Verifying server certificate failed...

대신 gnutls-cli를 사용해도 교차 확인을 하면 다음과 같은 결과를 --x509cafile /etc/ssl/certs/ca-certificates.crt얻습니다.

[..]
- The hostname in the certificate matches 'mx-ha03.web.de'.
- Peer's certificate is trusted

(이것도 예상됨)

Openssl s_client는 ca-certificates.crt를 인쇄합니다.

    Verify return code: 0 (ok)

TURKTRUST와 동일한 결과...

첫째, openssl이 기본 설정 -CApath(예: /etc/ssl/certs)을 사용하는 것으로 의심되었습니다. 하지만 프로세스를 진행 strace하면 .openCAfile

(모든 테스트는 Ubuntu 10.04 서버에서 수행되었습니다)

고쳐 쓰다:TURKTRUST 인증서를 Fedora 20 시스템에 복사하고 첫 번째 openssl 문을 실행했습니다. 거기에서 다른 결과를 얻었습니다.

Verify return code: 19 (self signed certificate in certificate chain)

답변1

openssl s_clientUbuntu 10.04에서는 시스템에 설치된 인증서의 기본 위치를 여전히 쿼리하는 것으로 나타났습니다 .-CApath 그리고 -CAfile지정:

8466  open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(추적 출력)

어디:

$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 ->
    Deutsche_Telekom_Root_CA_2.pem

디렉토리는 Ubuntu 10.04의 심볼릭 링크이므로 /usr/lib/ssl/certsgrep '/etc/ssl'.../etc/ssl/certsopen

원천

openssl-0.9.8k를 살펴보면 이 문제의 근본 원인은 다음 과 같습니다 crypto/x509/by_dir.c.dir_ctrl()

dir=(char *)Getenv(X509_get_default_cert_dir_env());
if (dir)
    ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
else
    ret=add_cert_dir(ld,X509_get_default_cert_dir(),
                     X509_FILETYPE_PEM);

X509_get_default_cert_dir반환할 곳 /usr/lib/ssl/certs.X509_get_default_cert_dir_env​SSL_CERT_DIR

해결책

따라서 다음 해결 방법을 사용하여 Ubuntu 10.04/openssl 0.9.8k에서 예상되는 동작을 얻을 수 있습니다.

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \
    -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \
    -starttls smtp -host mx-ha03.web.de -port 25

그리고 확인이 실패합니다.

Verify return code: 19 (self signed certificate in certificate chain)

현재 상황

이것은 우분투 문제입니다. 예를 들어 Fedora 20의 openssl 1.0.1e 또는 Fedora 29의 openssl 1.1.1의 경우 문제를 재현할 수 없으므로 이 해결 방법이 필요하지 않습니다. -CAfile이는 또는 같은 옵션이 지정되면 -CApath기본 인증서 시스템 디렉토리가 Fedora 시스템의 디렉토리 검색 목록에 추가되지 않음을 의미합니다 .

openssl 1.0.2g가 설치된 Ubuntu 16에서는 문제가 여전히 존재합니다.

openssl-1.0.2k-16이 포함된 CentOS 7에도 존재합니다. 불행히도 위의 해결 방법은 이 문제에 도움이 되지 않으며 알 수 없거나 예상치 못한 TLS 패킷 유형으로 인해 gnutls-3.3.29-8이 실패합니다.

관련 정보