Это действительно похоже на проблему на вашей стороне (то есть на стороне вашего сайта).
Сертификат, предоставляемый сервером, в порядке и принимается почти всеми браузерами. Проблема в том, что многие старые серверы не имеют (относительно) нового корневого сертификата в своём хранилище доверенных сертификатов, поэтому в настоящее время множество автоматизированных процессов выдают ошибки.
Я не знаю точной конфигурации вашего сайта, поэтому взял произвольный сайт hosted-by-discourse.com и проверил его с помощью Qualys SSL Server Test.
Как видно, корневой сертификат второго пути сертификации действительно истёк, но это компенсируется тем, что сертификат ISRG Root X1 присутствует в хранилище доверенных сертификатов (то есть включён в ваш браузер и/или операционную систему) для первого пути сертификации.
Серверы обычно не часто обновляют своё хранилище доверенных сертификатов, поэтому, вероятно, на вашем сервере отсутствует сертификат ISRG Root X1. (То же самое произошло и с образом Docker для почтового получателя).
Актуальный набор сертификатов можно найти, например, по адресу https://curl.se/ca/cacert.pem. В CentOS этот файл следует поместить в /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. В Ubuntu можно использовать команду update-ca-certificates, которая обновит файл /etc/ssl/certs/ca-certificates.crt.
Альтернативно, вы можете временно отключить проверку SSL-сертификатов в коде вашего сервера.
Я опубликовал вывод openssl, чтобы доказать, что это не имеет никакого отношения к нашему сайту, а также потому, что Postman запускается с локальной машины под Windows.
edit: я не так хорошо разбираюсь в различных уровнях хранилищ доверия, я изучу это подробнее, проблема возникает на каждой машине, которую мы пробуем.
Вот ответ, который я получил от нашего специалиста по DevOps.
Проблема в том, что существует две копии корневого сертификата ISRG Root X1: одна была выпущена давно через DST Root CA X3, а более новая — самозаверяемая, выпущенная самой ISRG (организацией, управляющей, среди прочего, Let’s Encrypt). Этот самозаверяемый корневой сертификат теперь принят как доверенный на большинстве систем.
Оба сертификата являются одинаковыми по содержанию подписи, поэтому вы можете проверить любой сертификат, заявляющий, что он выпущен «ISRG Root X1», используя любую из версий. Однако версия, подписанная DST, больше не действительна как часть цепочки сертификации, поскольку сертификат DST, которым она была подписана, теперь истёк.
Если бы сервер корректно предоставлял новую самозаверяемую версию ISRG Root X1, то клиент сравнил бы предоставленный сертификат со своим хранилищем доверия, убедился бы, что это тот же самый сертификат, и всё было бы в порядке. Но вместо этого он видит предоставленный сертификат, думает: «Хорошо, мне нужно проверить его по DST Root CA X3, который у меня есть… ой, он истёк» — и проверка завершается неудачей.
Предоставление сертификата в цепочке сертификатов, который должен находиться в хранилище доверенных корневых центров сертификации, совсем не означает «делать всё правильно».
Так что либо ваш специалист по DevOps ошибается, либо CDCK, и LetsEncrypt, и Qualys ошибаются.
Попросите его обновить хранилище корневых центров сертификации. Это решит проблему. Поверьте мне.
Привет @bpaterson2000 — жаль слышать, что у вас возникли проблемы с подключением к нашему хостинговому сервису. Как уже отметил @RGJ, проблема не на стороне Discourse — её необходимо исправить на вашем клиенте. (Наши серверы не «поставляют» корневой сертификат; он управляется вашим клиентом.)
Дополнительную информацию об этом изменении можно найти на сайте Let’s Encrypt:
Спасибо за информацию. Для нас это неожиданная проблема, так как ошибки, судя по всему, возвращались с хостинг-сервера.
Мы используем Heroku, который, по всей видимости, включает в себя упомянутые вами компоненты через node/packages. Похоже, что обновление node стало ключом к успешному восстановлению подключения к REST API Discourse.
