Срок действия сертификата Openssl истек, хотя он еще не

Моя проблема заключалась в том, что срок действия сертификата действительно истек, но не этот конкретный, а один в цепочке подписи.

Например, для Google эта команда openssl s_client -showcerts -connect google.com:443 </dev/null | openssl x509 -noout -dates показывает:

notBefore=Oct  6 12:37:54 2016 GMT
notAfter=Dec 29 12:28:00 2016 GMT

Однако только openssl s_client -showcerts -connect google.com:443 </dev/null показывает не 1, а 3 сертификата (заключенных в ---BEGIN/END CERTIFICATE--- частях), первый из них принадлежит google и именно он проверен. Чтобы убедиться в этом, я скопировал (вероятно, должен быть менее ручной способ) первый в /tmp/google и последний в /tmp/geotrust, теперь запуск openssl x509 -noout -dates < /tmp/google дает мне:

notBefore=Oct  6 12:37:54 2016 GMT
notAfter=Dec 29 12:28:00 2016 GMT

Что соответствует выводу первой команды и openssl x509 -noout -dates < /tmp/geotrust:

notBefore=May 21 04:00:00 2002 GMT
notAfter=Aug 21 04:00:00 2018 GMT

Что отличается и не было показано ранее. Итак, в конце концов, моя проблема заключалась в том, что один из сертификатов высшего органа действительно устарел.

И кстати, поскольку в комментарии к вопросу предлагается обновить ОС, чтобы решить эту проблему, я полагаю, что причина та же. ОС поставляется с кучей корневых сертификатов, поэтому, если у вас сумасшедшая старая ОС, срок действия некоторых из них может истечь, вы можете либо обновить эти корневые сертификаты, либо всю ОС, чтобы решить проблему.

Также полезно знать, что запуск без showcerts дает вам хорошее представление о цепочке сертификатов - openssl s_client -connect google.com:443 </dev/null:

---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---

Все это не должно быть просрочено.

Если вы просто выполните openssl s_client -connect <server>:<port>, он должен показать вам в конце после строки Verify... что-то вроде:

---
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
read:errno=10093

По сути, в этом сообщении об ошибке упоминается сертификат в цепочке сертификатов, который не был проверен, и причина, по которой это произошло.

Сегодня у меня возникла аналогичная проблема, и я зашел сюда с намерением найти ответ. К счастью, я получил ответ сам. Вот как я это понял:

1. когда я получил код возврата подтверждения: 10 (срок действия сертификата истек) ошибка в ящике, я попробовал другой ящик и не получил ошибку на том же сайте SSL, что на самом деле является ошибкой проверки: число = 20: невозможно получить локальный эмитент сертификат (приемлемый для меня)
2. тогда я подумал, что основная причина должна быть в первом поле, увидев эту ошибку. Наиболее вероятной причиной могли быть какие-то разные сертификаты ЦС в хранилище доверенных сертификатов, хотя я все еще не знал, где он был для первого ящика.
3. чтобы получить файл, влияющий на проверку проверки сертификата, я добавил strace перед openssl s_client ... и внимательно прочитал файлы, показанные в большой области вывода, особенно те, которые находятся рядом с ошибкой Verify return code: 10 (срок действия сертификата истек). У меня есть 2 подозрительных файла
4. Я запустил openssl x509 -text -in {filename} для проверки двух файлов, и мне удалось подтвердить, что один из них был основной причиной, поскольку срок его действия истек. Это промежуточный сертификат

С учетом сказанного, пожалуйста, проверьте, есть ли какие-либо промежуточные/корневые сертификаты, срок действия которых истек в вашем локальном хранилище доверенных сертификатов (возможно, /usr/lib/ssl/certs/ для openssl), которые отравляют проверку команды клиента openssl или команды curl.