Комментарии 45
Изначально я попробовал такое решение.
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?
Тогда вопрос, а *.habramail.net кто исправлять будет? www.hardenize.com/report/habr.com/1591127655#email_certs
COMODO RSA Certification Authority | 4f32d5d и
AddTrust External CA Root | 687fa45 все еще в списке.
Спасибо, не углядели.
Использовать Let's Encrypt, не?
LE не всем подходит, особенно когда инсталляция распределённая и чтобы отработал ACME через well-known, надо свистнуть очень хорошо и уже с помощью полусамодельного клиента. Иногда именно LE превращается в ежей и кактусы. И упаси бог использовать дефолтный certbot, который не умеет ничего, кроде как выпускать сертификат для админов локалхоста.
Получаете wildcard сертификат и размещаете его по серверам любым удобным способом.
DNS-01 challenge требует реализации API сервисом управления зонами для горы клиентов и перераспределения прав редактирования зоны. Тоже так себе решение. Wildcard тоже не всегда покрывает все потребности, это не волшебная пилюля.
У ACME есть несомненные плюсы, но есть и немало минусов. Никто не отговаривает им пользоваться, но решений может всегда быть больше чем одно.
Вот кстати чтобы отработал ACME ничего сложного делать не надо. Я просто проксировал со всех серверов .well-known на один сервер со стандартным cert-bot'ом.
А вот чтобы раскидать сертификат повсюду уже потребуется небольшой слой автоматизации.
Я вот использую, а вот некоторые внешние сервисы нет, и что-то меня 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 очень безответственное. Мало того что торгуют воздухом, так еще и торгуют протухшим воздухом. На последнем дебиане точно так же не работал курл к ресурсам. На убунте все ок.
Просто жесть — половина интернета (условно) может перестать работать из-за какой-то оплошности (!)
Если на стороне сервера ничего не исправлено, то в теории, может помочь установка промежуточного сертификата CA в trust store телефона и обозначение его доверенным. Либо он самостоятельно наследует доверенность, если уже есть в системе сертификат Comodo и цепочка строится.
P.S. Сервер — одна госконтора. Так что шансы, что исправят на стороне сервера, почти нулевые :(
P.P.S. Кстати, началось всё отнюдь не 30-го, а где-то в середине прошлой недели.
На айфоне вполне легально можно импортировать рутовый сертификат и выставить флаг доверия к нему. На андройде (не помню каком) я в своё время импортировал рутовый сертификат для корпоративного VPN. В целом, процесс импорта промежуточного CA не выглядит чем-то сильно отличающимся, на сколько я понимаю.
Дело не в клиенте, вернее не только в клиенте. Чтобы всё работало на старых девайсах, на стороне сервера нужно поставить AAA cross signed cert. Скачать можно прямо у Сектиго тут https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rfBO
Кстати, вполне себе выход на древних системах импортировать этот сертификат в trust store, чтобы получить доступ к сайтам, где ошибочкая цепочка. Только сертификата всего четыре как минимум: RSA для Comodo, RSA для Sectigo, ECC для Comodo и ECC для Sectigo. Наверное, это выход для всяких древних андроидов и линусков.
Пробовал сделать по гайду:
скачал файл 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 и тысячи их).
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, что он лезет в этот файл и не использует какой-то кэш для этого.
На 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 в посте.
Насколько я помню в Windows да, нужно все собирать в оснастке mmc для сертификатов. Вот вроде тут как раз решали схожую проблему (рекомендую прочитать также весь тред по ссылке).
Так вот, сначала я скачал и поставил самый свежий пакет 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 не может ничего утащить). Пожалуй, дополню публикацию.
Проблема с сертификатами Sectigo после 30 мая 2020 года и метод решения