Как побороть ненадежный ssl сертификат (comodo)?
Третий день танцую с бубном. Готовлю сервак для PCI DSS (стандарт безопасности данных индустрии платёжных карт). Все проблемы устранены, но осталась одна, которую никак не побороть. Для проверки сервака используется сканер (
https://www.hackerguardian.com/),
который постоянно выдает одну проблему:
SSL Certificate Cannot Be Trusted 443 / tcp / www
Я убрал из цепочки все сертификаты и оставил только один, специально приобретенный для этого сервака. Он подписан COMODO. Вроде бы, они считаются одними из самых надежных. Вот дамп сертификата:
openssl x509 -in /usr/local/psa/var/certificates/cert-f1nb7M -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e6:3c:e1:95:56:07:3c:f7:4c:5e:b3:bd:06:6d:37:f0
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Extended Validation Secure Server CA
Validity
Not Before: Nov 17 00:00:00 2021 GMT
Not After : Dec 3 23:59:59 2021 GMT
Subject: serialNumber=04045342/1.3.6.1.4.1.311.60.2.1.3=GB/businessCategory=Private Organization, C=GB/postalCode=BN27 2BY,
ST=East Sussex, L=Hailsham/street=Station Road/street=Unit 10 Swan Business Centre, O=Fuss 3 Solutions Ltd,
OU=COMODO EV SSL, CN=www.fuss3inkandtoner.co.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...................
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:39:DA:FF:CA:28:14:8A:A8:74:13:08:B9:E4:0E:A9:D2:FA:7E:9D:69
X509v3 Subject Key Identifier:
D1:C0:72:40:F1:A4:47:A6:FF:32:C4:56:6F:EF:F5:1E:40:6A:72:DC
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.1.5.1
CPS: https://secure.comodo.com/CPS
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/COMODORSAExtendedValidationSecureServerCA.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/COMODORSAExtendedValidationSecureServerCA.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:www.fuss3inkandtoner.co.uk, DNS:fuss3inkandtoner.co.uk
1.3.6.1.4.1.11129.2.4.2:
............
Signature Algorithm: sha256WithRSAEncryption
...............Сертификат настоящий, не просроченный, домен соответствует. Все средства диагностики (например, https://www.digicert.com/help/) говорят, что с сертификатом полный порядок. Кто сталкивался с подобным? Дело в том, что я не сисадмин, поэтому большого опыта с установкой SSL сертификатов у меня нет. Этот ставил админ из техподдержки хостинга. Прошу совета, времени очень мало, клиент нервничает.
Ключевые функции:
Venafi Cloud изначально предлагает интеграцию с инструментами DevOps, включая Hashicorp Terraform, Hashicorp Vault, SaltStack, Ansible, Docker и Jetstack Cert-Manager. Решение Venafi Cloud и GlobalSign PKI для DevOps предоставляет хорошо документированные стандартные интерфейсы, включая REST API, пакет SDK с открытым исходным кодом VCert (доступный в Go и Python) и ACME.
Основные функции Venafi Cloud перечислены в таблице.
Корневой сертификат центра сертификации globalsign
Мобильные ОС, микробраузеры, игровые и переносные консоли
Android (inclusion carrier specific)
Apple Safari for iPhone, iPod, iPad
Microsoft Windows Mobile 7
RIM Blackberry 4.3.0
NTT / DoCoMo
SoftBank Mobile
KDDI
Opera 9.26
Major Operators inc. Vodafone, EE, Sprint, AT&T
Major Handset providers SonyEricsson, Nokia, Alcatel & Palm (S40/S60/S80/OSSO) based Handsets from 2002
Sony PlayStation Vita
Sony PlayStation 3 & 4
Программные комплексы
Microsoft Authenticode & Visual Basic for Applications (VBA)
Adobe AIR
Sun Java JRE (1.4.2 Update 16 , 5.0 Update 13 , 6 Update 3 )
SeaMonkey
Google Checkout
NSS 3.11.10
Платформы обеспечения безопасности документов
The Digital TV Group (www.dtg.org.uk)
Первый ssl-сертификат с использованием кириллических символов
GMO GlobalSign Russia (
www.globalsign.com.ru-ru
), мировой удостоверяющий центр и ведущий поставщик решений идентификации и безопасности для Интернета Всего (Internet of Everything) объявил о первом выпуске
SSL-сертификата
с использованием кириллических символов. Ранее GlobalSign регистрировал SSL-сертификаты только на латинице, что позволяло добиться универсальности и автоматизации процесса для наших клиентов по всему миру. Но благодаря нашим постоянным усилиям по обеспечению безопасности в интернете, мы открыли новые возможности, которые привели к недавним улучшениям.
Наш первый SSL-сертификат с использованием кириллических символов был выпущен для организации Специальный Технологический Центр (stc-spb.ru). Компания заказала SSL-Сертификат OV Wildcard и попросила зарегистрировать своё имя в сертификате на кириллице. По желанию клиента другие детали сертификата, область и город, были указаны на латинском языке.
Сегодня у нас, российского представительства GlobalSign, появилась возможность выдавать SSL-сертификаты полностью на кириллице и пример с stc-spb.ru показывает, что это возможно. Теперь наши клиенты в России смогут регистрировать такие данные, как название компании, улица, город, район, на родном языке, что значительно упростит процесс восприятия информации в сертификате безопасности посетителями сайта.
GlobalSign также может выдавать SSL-сертификаты с использованием символов других алфавитов. GlobalSign China недавно выпустила свой первый сертификат SSL с использованием китайских иероглифов. EV SSL Certificate был выпущен для крупнейшей финансовой ассоциации PPmoney с деталям, прописанными с использованием китайских иероглифов.
В ближайшем будущем мы планируем расширить эти функции и для других алфавитов, используемых в мире.
Узнать о преимуществах работы напрямую с мировым удостоверяющим центром GlobalSign:
Проблема устаревших корневых сертификатов. на очереди let’s encrypt и умные телевизоры
Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.
Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.
Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.
Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.
Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.
Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.
Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!
С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.
Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.
Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.
Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).
Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.
К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.
Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.
Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё
в апреле 2021 года
они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого
не произошло
.
«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2021 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.
Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.
Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.
Корень ISRG выпущен 4 июня 2021 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2021 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.
Но в этом и проблема.
Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.
Экосистема Android
Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.
Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.
Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.
С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2021 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.
www.bbc.co.uk (Leaf) GlobalSign ECC OV SSL CA 2021 (Intermediate) GlobalSign Root CA - R5 (Intermediate) GlobalSign Root CA - R3 (Intermediate)
Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.
Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.
Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.
Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.
Решение проблемы только одно — обновление. Разработчики умных устройств должны заранее обеспечить механизм обновления программного обеспечения и корневых сертификатов. С другой стороны, производителям невыгодно обеспечивать работу своих устройств по окончании срока гарантии.
