Чому openssl s_client перевіряє церт на предмет невідповідності CAfile?

Я намагаюся отримати помилку підтвердження сертифікату з 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 сертифікований CA Deutsche Telekom CA, а не TURKTRUST, тому вищезазначена команда повинна вийти з ладу, правда?

Але він повідомляє:

    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...

Зробивши перехресну перевірку, тобто використовуючи замість цього --x509cafile /etc/ssl/certs/ca-certificates.crtgnutls-cli, я отримую:

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

(що також очікується)

Відкриває s_client друкує для сертифікатів ca.crt:

    Verify return code: 0 (ok)

Той самий результат, що і для TURKTRUST ...

Спочатку я підозрював, що openssl використовує налаштування за замовчуванням для -CApath(тобто / etc / ssl / certs), але коли я оброблю straceпроцес, я просто бачу лише opensyscall для аргументу CAfile.

(всі тести, виконані на сервері Ubuntu 10.04)

Оновлення: я скопіював сертифікат TURKTRUST в систему Fedora 20 і виконав перший оператор openssl - там я отримую інший результат:

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

Виявляється, що openssl s_clientна Ubuntu 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

Каталог /usr/lib/ssl/certsє символьним посиланням /etc/ssl/certsна Ubuntu 10.04, тому openрядок із журналу страйків не вибирається під час прив’язки до '/ etc / ssl' ...

Джерело

Дивлячись на 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)

Нинішня ситуація

Це проблема Ubuntu. Наприклад, у випадку, коли Fedora 20's openssl 1.0.1e або Fedora 29's Opensl 1.1.1, це рішення не потрібне, тому що питання неможливо відтворити. Це означає, що при введенні такого параметра, як -CAfileабо -CApath, до списку пошуку каталогів у системах Fedora не додано жодного каталогу системних сертифікатів за замовчуванням.

На Ubuntu 16 з openssl 1.0.2g проблема все ще присутня.

Він також присутній на CentOS 7 з openssl-1.0.2k-16 - і, на жаль, вищезгадане рішення не допомагає там, і gnutls-3.3.29-8 виходить з ладу через невідомі / несподівані типи пакетів TLS.