Comments 45
Столкнулся с этой проблемой вчера. Наш сертификат как раз Sectigo Positive SSL. Посетители нашего сайта вроде как ничего не заметили, но скрипты, которые обменивались по curl между различными инстансами на наших доменах работать перестали. Точнее так: на серверах на Ubuntu 18.04 всё работало как прежде, а на серверах с Ubuntu 16.04 (с версией OpenSSL 1.0.2) выдавало SSL Certificate Problem: Certificate has expired.

Изначально я попробовал такое решение.
1. Отредактировать /etc/ca-certificates.conf и удалить/закомментировать строчку mozilla/AddTrust_External_Root.crt.
2. Выполнить apt update && apt install ca-certificates и update-ca-certificates -f -v

Какое-то время всё работало нормально, однако сегодня проблема снова вылезла, удалённый сертификат просто добавился в конец файла.

В итоге просто пересоздал цепочку онлайн на сайте whatsmychaincert.com. Пока вроде работает без побочных эффектов.

Интересный сервис. Интересно, работает ли он с дуальными цепочками RSA+ECDSA?

Забавно. Ещё один способ выстрелить себе в ногу и случайно заиметь кошерный MITM чуть позже.

LE не всем подходит, особенно когда инсталляция распределённая и чтобы отработал ACME через well-known, надо свистнуть очень хорошо и уже с помощью полусамодельного клиента. Иногда именно LE превращается в ежей и кактусы. И упаси бог использовать дефолтный certbot, который не умеет ничего, кроде как выпускать сертификат для админов локалхоста.

Не нужно well-known, есть же проверка через запись в DNS.

Получаете wildcard сертификат и размещаете его по серверам любым удобным способом.

DNS-01 challenge требует реализации API сервисом управления зонами для горы клиентов и перераспределения прав редактирования зоны. Тоже так себе решение. Wildcard тоже не всегда покрывает все потребности, это не волшебная пилюля.


У ACME есть несомненные плюсы, но есть и немало минусов. Никто не отговаривает им пользоваться, но решений может всегда быть больше чем одно.

Вот кстати чтобы отработал ACME ничего сложного делать не надо. Я просто проксировал со всех серверов .well-known на один сервер со стандартным cert-bot'ом.
А вот чтобы раскидать сертификат повсюду уже потребуется небольшой слой автоматизации.

Я вот использую, а вот некоторые внешние сервисы нет, и что-то меня LE не спас...

Можно. Но в моей ситуации (3 домена второго уровня и тысячи поддоменов) гораздо незаморочнее использовать один wildcard сертификат на все домены, чем заморачиваться с Let's Encrypt. Когда я начинал пользоваться Sectigo, wildcard-сертификаты на LE ещё не были возможны. Сейчас попроще, но всё равно можно один раз поставить и на полтора года забыть и не бояться что-то слетит.
$ trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert" > /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
$ update-ca-trust extract

© opennet
Для клиентов с centos

Спасибо за статью. Вчера очень бомбило от этой ситуации. Отвалились чеки на пингдоме, отвалились агенты датадога. Поведение Sectigo очень безответственное. Мало того что торгуют воздухом, так еще и торгуют протухшим воздухом. На последнем дебиане точно так же не работал курл к ресурсам. На убунте все ок.

Можете их бойкотировать и начать пользоваться LE. Вряд ли Вам нужен сертификат более "защищенный", чем DV.

У меня отвалились апи на ноде и несколько серверов, у нас сертификат Wildcard на два года, сейчас меняем везде, повезло что ещё вчера прочитал заметку в новостях, нет слов от этой радости

Просто жесть — половина интернета (условно) может перестать работать из-за какой-то оплошности (!)

Сегодня не мог авторизоваться на Хабре, ESET NOD32 блокировал страницу авторизации, заявляя о внезапной смене сертификата сервером. До тех пор пока на время не отключил инспекцию HTTPS — так и не пускал.

Какая-то вредная функция. Сертификат можно менять каждые 5 минут — это не криминал. Тем более, если пины HPKP продолжают совпадать.

Вопрос: а как эту проблему починить на стороне клиента — в частном случае, хром на 6-м андроиде?

Если на стороне сервера ничего не исправлено, то в теории, может помочь установка промежуточного сертификата CA в trust store телефона и обозначение его доверенным. Либо он самостоятельно наследует доверенность, если уже есть в системе сертификат Comodo и цепочка строится.

А как это (установка промежуточного сертификата CA в trust store телефона и обозначение его доверенным) сделать? Ничего умнее чем (благо рут есть на планшете) покопаться в потрохах девайса и закинуть на него файлики android.googlesource.com/platform/system/ca-certificates/+/master/files пока на ум не пришло :(

P.S. Сервер — одна госконтора. Так что шансы, что исправят на стороне сервера, почти нулевые :(
P.P.S. Кстати, началось всё отнюдь не 30-го, а где-то в середине прошлой недели.

На айфоне вполне легально можно импортировать рутовый сертификат и выставить флаг доверия к нему. На андройде (не помню каком) я в своё время импортировал рутовый сертификат для корпоративного VPN. В целом, процесс импорта промежуточного CA не выглядит чем-то сильно отличающимся, на сколько я понимаю.

О, спасибо! Установка этого варианта сертификата решила проблему как минимум на имеющемся в руках тестовом android 5, который до этого не хотел работать никакими силами, хотя все чекеры сертификатов ошибок не показывали.

Кстати, вполне себе выход на древних системах импортировать этот сертификат в trust store, чтобы получить доступ к сайтам, где ошибочкая цепочка. Только сертификата всего четыре как минимум: RSA для Comodo, RSA для Sectigo, ECC для Comodo и ECC для Sectigo. Наверное, это выход для всяких древних андроидов и линусков.

Может кто-то подсказать как обновить корневой сертификат на CentOS 6?

Пробовал сделать по гайду:
скачал файл USERTrust RSA Root xSigned using AAA CA [ Cross Signed ] (domain), далее скопировал в /etc/pki/ca-trust/source/anchors/ и выполнил update-ca-trust extract
Но ничего не поменялось. Не понимаю что делаю не так.

Кроме факта возможной некорректной установки, надо понимать, что не все приложения используют системный trust store. Если не работает curl/openssl, то можно попытаться продиагностировать цепочку в дебаг режиме. У всяких поделок на питоне или раби (и многих иных), свой собственный trust store может затягиваться в vendor директорию при сборке бандла (venv/bundler/npm и тысячи их).

Да, проблема в запросах curl. Сайт работает нормально, хотя при проверке ssl
USERTrust RSA Certification Authority
Sat, 30 May 2020 10:48:38 UTC (expired 2 days, 3 hours ago) EXPIRED

Есть ли какой-то способ убедиться что изменения сделаны после команды обновления?
Еще не уверен надо ли делать синхронизацию cert-sync /etc/ssl/certs/ca-certificates.crt

За конкретно редхат не скажу, но технически все сертификаты из бандла должны просто собраться в текстовую колбасу по предопределённому пути на фс и это де-факто и есть trust store. Вам надо найти этот файл и разыскать там требуемый сертификат. Ну и как-то понять из дебага curl, что он лезет в этот файл и не использует какой-то кэш для этого.

Как-то так и есть, но так и не смог сделать. В centos просто нет инструментов для управления сертификатами. Можно добавить новые, но не убрать старые.
Решил временным фиксом curl.
Добрый день!
На IIS висит сертификат от Sectigo на браузерах ошибок при входе на узлы нет, но вот передача данных от партнера работать 30го перестала. Sectigo прислал комплект корневых сертификатов сегодня по моему запросу — «исправленых». Я их на сервере проинсталлировал, но партнер прислал что все равно ошибки есть:

01.06.2020 15:49:49.125 105 Host:«APP-TIBCO009» Zone:«Prod» «Adp_Concierge_DMZ_root» «Processes/In/Client/SendRequest» 52fc2b89-c9e6-424b-bca8-bbdc3f7587a7 Ошибка в адаптере Conserge24!

Job-173015 Error in [Utils/CallConserge24.process/Send HTTP Request]

An IOException was thrown while trying to execute the Http method

at com.tibco.plugin.share.http.client.JakartaHttpTransportDriver$RequestExecutor.run(Unknown Source)

at com.tibco.pe.util.ThreadPool$ThreadPoolThread.run(Unknown Source)

caused by: java.io.IOException: Failed to create secure client socket: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: com.tibco.security.AXSecurityException: could not find trusted CA certificate with DN 'CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB' that signed certificate with DN 'CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US'

Что я делаю не так?

Я бы порекомендовал проверить через сервис https://www.ssllabs.com/ssltest/analyze.html ваш домен, скорее всего сразу всё будет видно, где в цепочке всё плохо, а также сэмулировать, насколько сертификат будет приниматься определённой версией клиента (у вас клиент java, можно проверить, насколько такой https-сервер будет работать из под нужной версии jvm). И да: вы можете бесплатно перегенерировать свой сертификат, после чего он будет выпущен не Comodo, а уже Sectigo с теми же параметрами и сроком действия, что и у старого сертификата. К нему подойдёт цепочка, указанная в публикации.

Как бы то ни было, ваш сервер посылает его с цепочкой. Посмотрите ниже блок с путями, там наверняка будет картинка похожая на рисунок 3 в посте.

Прошу извинить за малоопытность — правильно ли я понимаю, что в требуется оснастке mmc открыть сертификаты — вычистить все старые корневые, чтоб не путаться и установить новые? но при этом сам наш сертификат можно не трогать?

Насколько я помню в Windows да, нужно все собирать в оснастке mmc для сертификатов. Вот вроде тут как раз решали схожую проблему (рекомендую прочитать также весь тред по ссылке).

У нас есть система с Debian 7 (которая давно EOL), но проблему надо было решить срочно (так как это важная прод-система).

Так вот, сначала я скачал и поставил самый свежий пакет ca-certificates с Ubuntu 20.04:
wget -P /tmp/ https://launchpadlibrarian.net/482337778/ca-certificates_20190110ubuntu1.1_all.deb
dpkg -i /tmp/ca-certificates_20190110ubuntu1.1_all.deb

Но он не поставился, было много ошибок. Потом я подключил репозитории от Debian 10
nano /etc/apt/sources.list
комментим всё и добавляем:
deb http://ftp.by.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.by.debian.org/debian/ buster main contrib non-free


и сделал apt-get update; apt-get -f install.

И всё заработало, как ни странно. Конечно, это временное решение, скорее всего какие-то проблемы всплывут дополнительно, но сейчас мы можем мигрировать на Ubuntu 20.04 в более спокойном режиме, мы выиграли время.

Я не призываю никого так делать, но вдруг кому-то пригодится. Само собой, создайте снепшот сервера перед этими манипуляциями.

Я понял, что немного однобоко описал проблему только со стороны владельца сервера со стухшим сертификатом, но едва коснулся проблемы со стороны клиента, при случае, если владаелец сервера упорот и не собирается ничего менять (например, мы столкнулись с сервером CDN Тильды, откуда php-curl не может ничего утащить). Пожалуй, дополню публикацию.

При использовании python (и любого другого софта под Win, использующего что-то свое для SSL вместо виндового SCHANNEL, но при этом смотрящего в виндовое хранилище сертификатов) на Windows 8/Server 2012 и выше, включая последнии версии Win10 со всеми обновлениями, в определенных условиях могла так же всплыть проблема урезанного хранилища корневых сертификатов.
Подписал 31 мая приложение через конвейер, все как обычно. Какого было мое удивление, когда при установке приложения мне выдалось предупреждение о неизвестном авторе. Проверил еще раз сертификат, все нормально. Подпись есть. Оказалось, что сертификат, которым подписывалась временная метка от Sectigo стал недействительным. Поменял с Sectigo на DigiCert и подпись опять стала работать.
Only those users with full accounts are able to leave comments. Log in, please.