Срок действия сертификата для IdenTrust DST Root CA X3 истек

Срок действия сертификата для IdenTrust DST Root CA X3 истек Техника

В этом обзоре мы расскажем об особенностях установки и привязки бесплатного TLS/SSL сертификата от Let’s Encrypt для сайта на веб сервере IIS, запущенного на Windows Server 2019/2016/2012 R2.

Содержание:

  • Let’s Encrypt и ACME клиенты для Windows
  • Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server
  • Перенаправление трафика IIS сайта с HTTP на HTTPS адрес
  • Использование сертификата Let’s Encrypt для Remote Desktop Services

Как известно, Let’s Encrypt — не единственный удостоверяющий центр, который автоматически выдаёт бесплатные сертификаты TLS по протоколу ACME. Кроме него, это делают норвежский Buypass (услуга BuyPass Go SSL) и австрийский ZeroSSL. До сих пор они оставались единственными резервными вариантами. Но теперь в команде бесплатных УЦ появился четвёртый игрок: SSL.com.

Вообще, сейчас всё больше УЦ начинают выдавать краткосрочные сертификаты и автоматизировать работу по протоколу ACME. В любом случае, полезно иметь запасной вариант на случай сбоя Let’s Encrypt. Вдруг их новые серверы не выдержат нагрузки.

30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let’s Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а «устаревшие системы» — это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?

30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let’s Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а «устаревшие системы» — это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?

Обновлено Обновлено: 10.10.2021
Опубликовано Опубликовано: 03.09.2020

Актуальные системы семейства Windows, подключенные к Интернету, могут автоматически обновлять корневые сертификаты. В противном случае, обновление необходимо выполнять вручную. Если это не делать, мы можем столкнуться с рядом проблем:

  • Не открываются или выдают предупреждение безопасности некоторые (или все) сайты, работающие по https.
  • Некорректная работа отдельных приложений (например, антивирусных систем).
  • Ошибки при подключении по удаленному рабочему столу.

Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания компанией Microsoft (Windows XP, 7, а также Server 2003, 2008).

КонференцияГлавная страница Последние сообщения Чат
Общие форумыТех. поддержкаРынокРынок трудаВакансииЦифр. ДомMacLifeКоммерция
Тематические форумы компаний и производителейHuawei
Форумы поддержки портала iXBT.comРейтингiXBT.comО Конфе
Специализированные форумыПроцессорыРазгонСист. платыПамятьВидеосистемаКриптаТВ-тюнерыВидеозахватМониторыФотоЦифр.звукPro AudioСтереоДК плеерыДК аудиоДК TVНакопителиОптич. носителиНАСПериферияКорпуса, БПСетиАдминистрированиеСерверыНоутбукиПланшетыМоб. телефоныМоб. гаджетыМоб. операторыТелефонияБытовая техника
ПрограммыOС и сист. ПОПрикладное ПОUnixФинПОДрайверыИнтернетПрограммированиеOpenSource
ИгрыИгрыКонсоли
Авторские форумыЭл. устройства
Прочие форумыОбщийПолитикаИсторияНаукаБанкиКриптаКультураКиноАвтоРемонтСпортКулинарияОтдыхСемьяФлеймФлуд
КонференцияГлавная страница Последние сообщения Чат
Общие форумыТех. поддержкаРынокРынок трудаВакансииЦифр. ДомMacLifeКоммерция
Тематические форумы компаний и производителейHuawei
Форумы поддержки портала iXBT.comРейтингiXBT.comО Конфе
Специализированные форумыПроцессорыРазгонСист. платыПамятьВидеосистемаКриптаТВ-тюнерыВидеозахватМониторыФотоЦифр.звукPro AudioСтереоДК плеерыДК аудиоДК TVНакопителиОптич. носителиНАСПериферияКорпуса, БПСетиАдминистрированиеСерверыНоутбукиПланшетыМоб. телефоныМоб. гаджетыМоб. операторыТелефонияБытовая техника
ПрограммыOС и сист. ПОПрикладное ПОUnixФинПОДрайверыИнтернетПрограммированиеOpenSource
ИгрыИгрыКонсоли
Авторские форумыЭл. устройства
Прочие форумыОбщийПолитикаИсторияНаукаБанкиКриптаКультураКиноАвтоРемонтСпортКулинарияОтдыхСемьяФлеймФлуд

Помогаю со студенческими работами здесь

Не загружается моноблок HP — ошибка DST
Доброго времени суток!
Перестал загружаться моноблок от HP. No boot disk has been detected or the…

Ошибка жесткого диска короткого DST
Доброго времени суток! У меня такая проблема случилась. При включении ноутбука и появлении рабочего…

Игнорирование перехода времени на летнее (DST)
Собственно это возможно сделать без составления громадного массива?

Добавлено через 1 час 11…

Как лечить shown root:root -R /
У меня есть маленький CentOS7 http сервер. При очередном редактирования крона на бэкап данных…

О memcopy, а именно об ее первом параметре void *dst
Доброго времени суток. Не подскажете, как можно модернезировать код, что бы обойтись без лишнего…

Срок действия сертификата для IdenTrust DST Root CA X3 истек Где хранятся правила перехода STANDARD/DST time?
Вроде бы начиная с 1970 года эти locale-dependent правила хранятся имеено в файле локали, но в…

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:

  • Инструкция по установке корневого сертификата urfu.ru в Windows

1. Загрузите необходимый вам сертификат

2. Нажмите на файл сертификата правой кнопкой мыши, и выберите пункт «Открыть»

3. В появившемся окне, проверьте информацию о сертификате и нажмите кнопку «Установить сертификат»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

4а. (Для Windows 8 и выше) В мастере импорта сертификатов выберите «Локальный компьютер» и нажмите «Далее»

Шаг 4 в Windows 8 и выше

4б. (Для Windows 7 и предыдущих версий) В мастере импорта сертификатов нажмите «Далее»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

5. Выберите пункт «Поместить все сертификаты в следующее хранилище» и нажмите кнопку «Обзор»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

6. Выберите раздел «Доверенные корневые центры сертификации»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

7. В мастере импорта сертификатов нажмите кнопку «Далее»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

8. В мастере импорта сертификатов нажмите кнопку «Готово»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

9. Окне предупреждения подтвердите установку сертификата, для этого нажмите кнопку «Да»

Срок действия сертификата для IdenTrust DST Root CA X3 истек

10. В случае успешного импорта сертификата появиться окно подтверждения

Срок действия сертификата для IdenTrust DST Root CA X3 истек

Создано / Изменено: 7 октября 2015 / 8 октября 2015

WebHOST 1

Назад

29.09.2021 (23:01)

30 сентября 2021 14:01:15 GMT (17:01 MSK) оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Сертификаты Let’s Encrypt перестанут восприниматься в уже не поддерживаемых прошивках и операционных системах, а так же клиентах, в которых для обеспечения доверия к сертификатам Let’s Encrypt потребуется ручное добавление сертификата ISRG Root X1 в хранилище корневых сертификатов. Проблемы будут проявляться в:
OpenSSL до ветки 1.0.2 включительно (сопровождение ветки 1.0.2 было прекращено в декабре 2019 года);
NSS < 3.26 (curl);
Java 8 < 8u141, Java 7 < 7u151;
Windows < XP SP3;
macOS < 10.12.1;
iOS < 10 (iPhone < 5);
Android < 2.3.6;
Mozilla Firefox < 50;
Ubuntu < 16.04;
Debian < 8.

С подробностями можно ознакомиться на авторитетных тематических веб-ресурсах по ссылкам:
https://www.opennet.ru/opennews/art.shtml?num=55875 — описание.

https://habr.com/ru/post/580092/ — описание + информация что со всем этим делать.

https://letsencrypt.org/certificates/ — официальный сайт, схема цепочек SSL.

Содержание
  1. Вас может заинтересовать
  2. Как установить сертификаты
  3. Как установить сертификаты
  4. Что такое корневой сертификат
  5. Какие устройства столкнутся с ошибками SSL-соединения
  6. Что делать владельцам сайтов
  7. Обновление сертификатов
  8. Получение актуальных сертификатов
  9. Установка/обновление корневых сертификатов
  10. Корневые сертификаты
  11. Промежуточные сертификаты
  12. Промежуточные сертификаты
  13. Корневые сертификаты
  14. Сертификат подписания ответов OCSP
  15. Прозрачность сертификата
  16. Root Certificates
  17. Cross Signing
  18. Roots
  19. OCSP Signing Certificate
  20. Certificate Transparency
  21. IOS (iPhone и iPad с ОС до 10 версии)
  22. Android
  23. Немного теории и истории
  24. Что произойдет 30 сентября?
  25. Что со всем этим делать?
  26. На стороне клиента
  27. Linux
  28. Windows
  29. На стороне сервера
  30. Протокол ACME
  31. SSL. com
  32. Let’s Encrypt и ACME клиенты для Windows
  33. Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server
  34. Перенаправление трафика IIS сайта с HTTP на HTTPS адрес
  35. Использование сертификата Let’s Encrypt для Remote Desktop Services
  36. Немного теории и истории
  37. Что произойдет 30 сентября?
  38. Что со всем этим делать?
  39. На стороне клиента
  40. Linux
  41. Windows
  42. На стороне сервера
  43. Итоги
  44. Итоги
  45. Где скачать сертификат DST Root CA x3?
  46. Чем заменить Letsencrypt?
  47. Как выпустить сертификат Let’s Encrypt Windows?
  48. Как обновить сертификат безопасности на компьютере?
  49. Как обновить корневые Сертификаты в Windows 7?
  50. Где скачать сертификат DST Root CA x3?
  51. Как импортировать сертификат в Windows 7?

Вас может заинтересовать

Чтобы решить проблему, нужно обновить Windows 7 до Windows 10 или вручную установить «доверенные» сертификаты в систему.

site_little

Как установить сертификаты

1-1

2. Установить скачанный сертификат в систему. Для этого нажмите сочетание кнопок Win+R и введите команду certmgr.msc — OK. В открывшемся центре сертификатов в Windows откройте вкладку «Доверенные корневые центры сертификации/сертификаты» — клик правой кнопкой мыши — выберите «Все задачи — импорт».

Импорт сертификата

3. Далее запустится мастер импорта сертификатов — кликните «Далее». При импорте некоторые шаги могут быть пропущены, вот последний шаг:

Мастер импорта сертификатов

4. Кликните кнопку «Обзор» и укажите ранее загруженный сертификат. Нажмите «Далее» (пример показан ниже).

Указываем сертификат, который загрузили

5. На следующем шаге укажите, что сертификаты нужно поместить в доверенные центры сертификации, и нажмите «Далее».

Поместить сертификаты в доверенные. Далее

6. На следующем этапе вы должны увидеть, что импорт успешно завершен. Перезагрузите операционную систему — и все готово. Можно идти проверять, как отображаются сайты в браузере!


Чтобы решить проблему, нужно обновить Windows 7 до Windows 10 или вручную установить «доверенные» сертификаты в систему.

site_little

Как установить сертификаты

1-1

2. Установить скачанный сертификат в систему. Для этого нажмите сочетание кнопок Win+R и введите команду certmgr.msc — OK. В открывшемся центре сертификатов в Windows откройте вкладку «Доверенные корневые центры сертификации/сертификаты» — клик правой кнопкой мыши — выберите «Все задачи — импорт».

Импорт сертификата

3. Далее запустится мастер импорта сертификатов — кликните «Далее». При импорте некоторые шаги могут быть пропущены, вот последний шаг:

Мастер импорта сертификатов

4. Кликните кнопку «Обзор» и укажите ранее загруженный сертификат. Нажмите «Далее» (пример показан ниже).

Указываем сертификат, который загрузили

5. На следующем шаге укажите, что сертификаты нужно поместить в доверенные центры сертификации, и нажмите «Далее».

Поместить сертификаты в доверенные. Далее

6. На следующем этапе вы должны увидеть, что импорт успешно завершен. Перезагрузите операционную систему — и все готово. Можно идти проверять, как отображаются сайты в браузере!


Главная
/

Архив новостей / Ошибка установки SSL-соединения с сертификатом Let’s Encrypt

Ошибка установки SSL-соединения с сертификатом Let’s Encrypt

30-09-2021

Начиная с сегодняшнего дня, 30 сентября 2021 года при попытке соединения с сервером по шифрованным протоколам SSL/TLS могут возникать ошибки:

SSL error 0x80090325 Цепочка сертификатов выпущена центром сертификации, не имеющим доверия.

NET::ERR_CERT_DATE_INVALID

или другая аналогичная, сообщающая о невозможности установки защищённого соединения. Причина заключается в истечение сегодня срока действия корневого цифрового сертификата IdenTrust DST Root CA X3, которым подписаны сертификаты от популярного удостоверяющего центра (УЦ) Let’s Encrypt. Этим УЦ выпущено множество SSL сертификатов (более чем для 250 миллионов доменных имён), используемых в сети на веб-сайтах, почтовых серверах и других сервисах. Так как срок действия сертификата действителен не позднее 30 сентября 2021 14:01:15 GMT, после этой даты устройства и программы более не могут доверять ему и соединения не будут устанавливаться.

Для решения проблемы Let’s Encrypt уже более 5 лет использует подпись корневым сертификатом ISRG Root X1, действующим до 2035 года. Однако, устройства и операционные системы, не получающие обновления цепочки сертификатов, могут не иметь его в списке доверенных и столкнутся с ошибками SSL соединения. Список такого ПО и операционных систем:

  • Android до версии 7.1.1;
  • Mozilla Firefox до 50.0;
  • MacOS 10.12.0 и старше;
  • Windows до XP Service Pack 3;
  • iOS-устройств до версии iOS 10;
  • OpenSSL 1.0.2 и ниже;
  • Ubuntu до версий 16.04;
  • Debian 8 и старше.

Для восстановления возможности работы устаревшего устройства или программного обеспечения следует обновить операционную систему или добавить SSL-сертификат ISRG Root X1 в список доверенных.

Срок действия корневого сертификата IdenTrust DST Root CA X3 от центра Let’s Encrypt истек 30 сентября 2021 года. Из-за этого миллионы старых версий iPhone, Android и компьютеров не могут попасть на сайты с Let’s Encrypt. Разберемся, что случилось и как исправить.

из-за обновления корневого сертификата от Let’s Encrypt, миллионы пользователей не могут открыть сайты

Что такое корневой сертификат

Все SSL-сертификаты в интернете выдаются центрами сертификации, которым доверяют устройства. Каждое устройство знает, какому сертификату доверять, потому что хранит список корневых сертификатов. Хранилища корневых сертификатоввстроены в ОС и обычно обновление корневых сертификатов включено в процесс обновления ОС. Корневой сертификат, который вызвал проблему для миллиона пользователей ― IdentTrust DST Root CA X3 и его срок действия закончился. С этого момента у всех браузеров, которые доверяли сертификатам на основе DST Root CA X3, проблема с проверкой сертификата Let’s Encrypt.

Хотя SSL-сертификаты Let’s Encrypt подтверждались за счет корневого сертификата IdenTrust DST Root CA X3, он был не единственным. У Let’s Encrypt есть новый промежуточный сертификат ISRG Root X1, но про него не знают старые версии прошивок. Таким образом, на новых устройствах сайты с Let’s Encrypt нормально открываются, а на старых появляется ошибка «Подключение не защищено».

Старым устройствам придется удалить корневой сертификат IdenTrust DST Root CA X3
Цепочки доверия сертификатов Let’s Encrypt: по новой цепочке доверия сертификаты работают только на тех устройствах, которые знают про ISRG Root X1. Источник

Какие устройства столкнутся с ошибками SSL-соединения

  • Windows старше, чем версия XP SP3;
  • macOS старше, чем версия 10.12.1;
  • iOS старше, чем версия 10;
  • Android старше, чем версия 7.1.1;
  • Mozilla Firefox старше, чем версия 50;
  • Ubuntu старше, чем версия 16.04;
  • Debian старше, чем версия 8;
  • Nintendo старше, чем версия 3DS;
  • PlayStation старше, чем версия 5.0.

Что делать владельцам сайтов

Так как старый корневой сертификат SSL не восстановят, у пользователей продолжатся проблемы с доступом к сайтам. Есть два способа решить проблему:

  • Предложить посетителям сайта обновиться до новой версии ПО, чтобы их устройства узнали про новыйкорневой сертификат ISRG Root X1
  • Купить SSL-сертификат для сайта, совместимый со старыми версиями устройств.
Дополнительно:  (Решено) Как исправить зависание Path of Exile? | Советы 2020 - Driver Easy - Проблемы Программы

Купить SSL по скидке

Обновление сертификатов

Обновление доверенных корневых сертификатов выполняется во время обновления операционной системы. Если последнее включено, то нашего участия не требуется, иначе, можно установить обновление вручную. Пример такого пакета — KB931125.

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

Получение актуальных сертификатов

Для начала, выгрузим сертификаты на компьютере с актуальной версией Windows (10) и подключением к сети Интернет.

Создадим каталог, в который будет выгружен файл с корневыми сертификатами, например, C:\CA (папка CA на диске C).

Открываем командную строку от администратора и вводим команду:

certutil.exe -generateSSTFromWU C:\CA\roots.sst

* где C:\CA — каталог, который мы создали; roots.sst — файл, в который будут выгружены сертификаты.
* если мы получили ошибку Не удается найти указанный файл. 0x80070002, то необходимо убедиться, что каталог CA создан (в нашем примере в корне диска С).

В папке C:\CA мы должны увидеть файл roots.sst.

Установка/обновление корневых сертификатов

Полученный на предыдущем этапе файл переносим на компьютер, где необходимо обновить доверенные корневые сертификаты, например, также в папку C:\CA. Скачиваем утилиту rootsupd и распаковываем ее в этот же каталог.

Открываем командную строку от администратора и вводим команду:

C:\CA\rootsupd.exe /c /t:C:\CA

* где C:\CA — папка, в которую мы перенесли корневые сертификаты.

В появившемся окне Roots Update:

Запрос на перетирание файла roots.sst

… выбираем No, чтобы не переписывать наш файл roots.sst.

В папке C:\CA должны появится новые файлы, в том числе, утилита updroots. Вводим теперь команду:

C:\CA\updroots.exe C:\CA\roots.sst

Готово.

Дмитрий Моск — частный мастер

Была ли полезна вам эта инструкция?

Да Нет

Корневые сертификаты

Наши корневые сертификаты хранятся в надёжном месте и недоступны онлайн. Мы выпускаем сертификаты для пользователей на основе промежуточных сертификатов из следующего раздела. Для дополнительной совместимости с новым Root X2 с различными корневыми хранилищами, мы также подписали его с Root X1.

  • Активные
    • ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
      • Самоподписанный: der, pem, txt
      • Кросс подписанный DST Root CA X3: der, pem, txt
  • Действующий, с ограничениями
    • ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
      • Самоподписанный: der, pem, txt
      • Кросс-подписанный ISRG Root X1: der, pem, txt

Мы создали сайты для проверки цепочки сертификатов вплоть до активных корневых.

  • ISRG Root X1
    • Действительный
    • Отозванный
    • Срок действия истёк
  • ISRG Root X2
    • Действительный
    • Отозванный
    • Срок действия истёк

Промежуточные сертификаты

Как правило, сертификаты, выпущенные Let’s Encrypt, создаются на основе “R3”, промежуточного RSA. В настоящее время выпуск сертификатов из “E1”, промежуточного ECDSA-сертификата, возможен только для ключей ECDSA из разрешенных аккаунтов. В будущем выпуск сертификатов из “Е1” будет доступен для всех.

Дополнительные промежуточные сертификаты (“R4” и “E2”) зарезервированы для восстановления после стихийных бедствий, и будут использованы только в том случае, если мы потеряем доступ к нашими основным межуточным сертификатам. Мы больше не используем промежуточные сертификаты X1, X2, X3 и X4.

IdenTrust кросс-подписал наши промежуточные сертификаты RSA для дополнительной совместимости.

  • Активные
  • Действующий, с ограничениями
  • Резервное копирование
  • Неиспользуемые

Промежуточные сертификаты

Каждый из наших промежуточных сертификатов представляет собой одну публичную/частную ключевую пару. Это позволяет всем основным браузерам принимать наши сертификаты с нашим же корневым сертификатом.

Наши промежуточные RSA-сертификаты подписаны ISRG Root X1. На данный момент ISRG Root X1 пользуется широким доверием, но у наших промежуточных RSA по-прежнему кросс-подпись “DST Root CA X3” IdenTrust (теперь он называется “TrustID X3 Root”) для дополнительной клиент-совместимости. Корневой сертификат IdenTrust существует дольше и поэтому лучше совместим со старыми устройствами и операционными системами (например, Windows XP, Android 7). Вы можете загрузить “TrustID X3 Root” из IdenTrust (или, как вариант, вы можете скачать копию у нас).

Кросс-подпись означает, что каждый из наших промежуточных сертификатов имеет два сертификата, представляющих один и тот же ключ подписи. Один подписан DST Root CA X3, другой подписан ISRG Root X1. Самый простой способ отличить их — посмотреть на поле “Issuer” (издатель).

При настройке web-сервера, администратор указывает не только листовые сертификаты, но и список промежуточных сертификатов. Это помогает браузеру проверить, входит ли листовой сертификат в цепочку доверия, ведущую к корневому сертификату. Почти все операторы серверов будут выбирать для обслуживания цепочку, включающую промежуточный сертификат с субъектом “R3” и издателем “ISRG Root X1”. Рекомендуемое клиентское программное обеспечение Let’s Encrypt, Certbot, выполнит эту задачу без затруднений.

Корневые сертификаты

Как и промежуточные сертификаты, корневые сертификаты могут быть кросс-подписаны, часто для увеличения клиентской совместимости. Наш корневой ECDSA-сертификат, ISRG Root X2 был создан осенью 2020 года и является корневым сертификатом для иерархии ECDSA. Он представлен двумя сертификатами: самоподписанным и подписанным ISRG Root X1.

Все сертификаты, подписанные промежуточным ECDSA-сертификатом “E1”, будут иметь цепочку с промежуточным сертификатом, у которого субъект “ISRG Root X2”, а издатель “ISRG Root X1”. Почти все сервера выберут для обслуживания эту цепочку, поскольку она обеспечивает наибольшую совместимость до тех пор, пока ISRG Root X2 не получит широкого доверия.

Сертификат подписания ответов OCSP

Этот сертификат используется для подписания ответов OCSP для промежуточных Центров Сертификации Let’s Encrypt. Таким образом нам не нужно иметь онлайне-доступ к корневому сертификату, чтобы подписать эти ответы. Копия сертификата подписания включена в ответ OCSP для информирования, дополнительно пользователям ничего делать не нужно.

  • ISRG Root OCSP X1 ([Подписанный ISRG Root X1](https://crt. sh/? id=2929281974)): [der](/certs/isrg-root-ocsp-x1. der), [pem](/certs/isrg-root-ocsp-x1. pem), [txt](/certs/isrg-root-ocsp-x1. txt)

У наших новых промежуточных сертификатов нет OCSP URL-адресов (их информация об отзыве вместо этого используется CRL), поэтому мы не выпустили сертификат подписи OCSP от ISRG Root X2.

Прозрачность сертификата

В Let’s Encrypt мы в нацелены на прозрачность в наших процессах и в сертификатах, которые выпускаем. Мы записываем сертификаты в журнал Certificate Transparency сразу, как только выпускаем их. Все наши сертификаты доступны по ссылкам:

  • Выпущены Let’s Encrypt Authority X1
  • Выпущены Let’s Encrypt Authority X3
  • Выпущены Е1
  • Выпущены R3

Root Certificates

Our roots are kept safely offline. We issue end-entity certificates to subscribers from the intermediates in the next section.
For additional compatibility as we submit our new Root X2 to various root programs, we have also cross-signed it from Root X1.

  • Active
    • ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
      • Self-signed: der, pem, txt
      • Cross-signed by DST Root CA X3: der, pem, txt
  • Active, limited availability
    • ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
      • Self-signed: der, pem, txt
      • Cross-signed by ISRG Root X1: der, pem, txt

We’ve set up websites to test certificates chaining to our active roots.

  • ISRG Root X1
    • Valid
    • Revoked
    • Expired
  • ISRG Root X2
    • Valid
    • Revoked
    • Expired

Under normal circumstances, certificates issued by Let’s Encrypt will come from “R3”, an RSA intermediate.
Currently, issuance from “E1”, an ECDSA intermediate, is possible only for ECDSA subscriber keys for allowlisted accounts. In the future, issuance from “E1” will be available for everyone.

Our other intermediates (“R4” and “E2”) are reserved for disaster recovery and will only be used should we lose the ability to issue with our primary intermediates.
We do not use the X1, X2, X3, and X4 intermediates anymore.

IdenTrust has cross-signed our RSA intermediates for additional compatibility.

  • Active
  • Active, limited availability
  • Backup
  • Retired

Cross Signing

Each of our intermediates represents a single public/private
key pair. The private key of that pair generates the signature for all end-entity
certificates (also known as leaf certificates), i.e. the certificates we issue
for use on your server.

Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 is widely trusted at this
point, but our RSA intermediates are still cross-signed by IdenTrust’s “DST Root CA X3”
(now called “TrustID X3 Root”) for additional client compatibility. The IdenTrust
root has been around longer and thus has better compatibility with older devices
and operating systems (e.g. Windows XP, Android 7). You can download “TrustID X3 Root” from
IdenTrust (or, alternatively,
you can download a copy from us).

Having cross-signatures means that each of our RSA intermediates has two
certificates representing the same signing key. One is signed by DST Root
CA X3 and the other is signed by ISRG Root X1. The easiest way to distinguish
the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the
end-entity certificate, but also a list of intermediates to help browsers verify
that the end-entity certificate has a trust chain leading to a trusted root
certificate. Almost all server operators will choose to serve a chain including
the intermediate certificate with Subject “R3” and
Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software,
Certbot, will make this configuration seamlessly.

Roots

Similar to intermediates, root certificates can be cross-signed, often to increase client
compatibility. Our ECDSA root, ISRG Root X2 was generated in fall 2020 and is the root
certificate for the ECDSA hierarchy. It is represented by two certificates: one that is
self-signed and one that is signed by ISRG Root X1.

All certificates signed by the ECDSA intermediate “E1” will come with a chain including an intermediate
certificate whose Subject is “ISRG Root X2” and whose Issuer is “ISRG Root X1”. Almost all server operators
will choose to serve this chain as it offers the most compatibility until ISRG Root X2
is widely trusted.

OCSP Signing Certificate

This certificate is used to sign OCSP responses for the Let’s Encrypt Authority
intermediates, so that we don’t need to bring the root key online in order to
sign those responses. A copy of this certificate is included automatically in
those OCSP responses, so Subscribers don’t need to do anything with it. It is
included here for informational purposes only.

  • ISRG Root OCSP X1 (Signed by ISRG Root X1): der, pem, txt

Our newer intermediates do not have OCSP URLs (their revocation information is
instead served via CRL), so we have not issued an OCSP Signing Cert from ISRG Root X2.

Certificate Transparency

We are dedicated to transparency in our operations and in the certificates we
issue. We submit all certificates to Certificate Transparency
logs as we issue them. You can view all
issued Let’s Encrypt certificates via these links:

  • Issued by Let’s Encrypt Authority X1
  • Issued by Let’s Encrypt Authority X3
  • Issued by E1
  • Issued by R3

IOS (iPhone и iPad с ОС до 10 версии)

  1. Скачайте файл сертификата ISRG Root X1 на устройство.
  2. В Настройки» -> «Основные» -> «Доверие сертификатов» включите «Доверять корневым сертификатам полностью».

Android

Устройства с версиями ОС Android до 7.1.1 также не поддерживают корневой сертификат ISRG Root X1. Однако, Let’s Encrypt удалось договориться с IdenTrust о выпуске на 3 года кросс-подписи истекшего DST Root CA X3. Таким образом, устройства даже с устаревшими версиями Android не будут сообщать об ошибке как минимум до 2024 года. Действий с ними не требуется.

При перепубликации статьи установка активной индексируемой
гиперссылки на источник — сайт обязательна!

Немного теории и истории

Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let’s Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов. Система при проверке будет доверять сертификатам, которые подписаны с использованием закрытого ключа одного из этих корневых сертификатов. Сами корневые сертификаты как правило имеют длительные сроки действия, меняются редко и не используются при формировании сертификатов конечного субъекта (в данном случае, сертификатов для доменных имен), вместо этого инфраструктура открытых ключей, предполагает использование цепочек доверия — корневые сертификаты применяются для подписания промежуточных сертификатов, а уже с использованием них подписываются сертификаты конечного субъекта (сертификаты для доменов). При этом, для того, чтобы система доверяла конечному сертификату, она должна быть способна проследить всю цепочку от этого сертификата до одного из корневых сертификатов, которым она доверяет.

После появления проекта Let’s Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем «из коробки» (без дополнительных действий со стороны пользователей этих систем). В связи с этим, для сертификатов Let’s Encrypt стала использоваться цепочка доверия, ведущая к корневому сертификату DST Root CA X3, который признается большинством систем:

  • Windows >= XP SP3

  • macOS (большинство версий)

  • iOS (большинство версий)

  • Android >= v2.3.6

  • Mozilla Firefox >= v2.0

  • Ubuntu >= precise / 12.04

  • Debian >= squeeze / 6

  • Java 8 >= 8u101

  • Java 7 >= 7u111

  • NSS >= v3.11.9

  • Amazon FireOS (Silk Browser)

  • Cyanogen > v10

  • Jolla Sailfish OS > v1.1.2.16

  • Kindle > v3.4.1

  • Blackberry >= 10.3.3

  • PS4 game console with firmware >= 5.00

К настоящему моменту корневой сертификат ISRG Root X1 существует уже более 5 лет и за это время попал в доверенные в большинстве современных систем, ему доверяют:

  • Windows >= XP SP3 (при условии, что производилось автоматическое обновление корневых сертификатов)

  • macOS >= 10.12.1

  • iOS >= 10

  • Android >= 7.1.1

  • Mozilla Firefox >= 50.0

  • Ubuntu >= xenial / 16.04 (с установленными обновлениями)

  • Debian >= jessie / 8 (с установленными обновлениями)

  • Java 8 >= 8u141

  • Java 7 >= 7u151

  • NSS >= 3.26

Дополнительно:  Не могу прослушать голосовое сообщение в ВК: что делать

Для сертификатов Let’s Encrypt по умолчанию в данный момент предлагается такая цепочка доверия:

IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые не доверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android >= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов.

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Что со всем этим делать?

На стороне клиента

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

faketime -f '@2021-10-01 00:00:00' curl https://letsencrypt.org/

Если всё в порядке, curl вернёт содержимое страницы, если же нет — выдаст сообщение об ошибке:

curl: (60) server certificate verification failed.

В этом случае нужно убедиться, что:

  1. Ваша система доверяет ISRG Root X1

  2. Вы не пользуетесь устаревшей версией OpenSSL

Проверка доверия к ISRG Root X1

Например, Ubuntu 16.04 xenial и Debian 8 jessie доверяют ISRG Root X1, но при этом поставляются с OpenSSL 1.0.x, поэтому проблема их может коснуться.

Чтобы проверить наличие сертификата ISRG Root X1 в числе доверенных:

в Debian/Ubuntu:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "ISRG Root X1"

в CentOS:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "ISRG Root X1"

В выводе команды в обоих случаях должно присутствовать:

subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Если такой строчки нет, то нужно добавить ISRG Root X1 в доверенные. В Debian/Ubuntu:

curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt | sudo tee /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

добавить в файл /etc/ca-certificates.conf строчку:

mozilla/ISRG_Root_X1.crt

и выполнить комнаду

sudo update-ca-certificates

Проверка версии OpenSSL

Если система доверяет ISRG Root X1, нужно проверить версию OpenSSL

openssl version

В выводе должна быть версия 1.1.0 или новее.

Если используется OpenSSL 1.0.x, то достаточным решением проблемы будет удалить из доверенных сертификат DST Root CA X3 (это решение может не сработать для openssl версий &lt;1.0.1p и &lt;1.0.2d). Это можно сделать, не дожидаясь 30 сентября.

В Debian/Ubuntu:

В файле /etc/ca-certificates.conf нужно найти строчку:

mozilla/DST_Root_CA_X3.crt

и поставить в начало сроки символ «!»:

!mozilla/DST_Root_CA_X3.crt

Далее, необходимо выполнить команду:

sudo update-ca-certificates

В CentOS

Выполнить команды:

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem

sudo update-ca-trust

Локальное продление срока действия сертификата DST Root CA X3

Для тех случаев, когда используется совсем старый openssl (версии меньше 1.0.1p и 1.0.2d, но новее 0.9.8m), или по иной причине не срабатывает метод с изъятием из доверенных сертификата DST Root CA X3, можно воспользоваться еще одним методом, предложенным в статье Scott’а Helme. Метод основан на том, что OpenSSL, начиная с версии 0.9.8m, не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный. Для того, чтобы продлить для OpenSSL на системе срок действия сертификата DST Root CA X3 еще на три года можно выполнить следующие команды:

Debian/Ubuntu:

sudo sed -i «s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g» /etc/ssl/certs/DST_Root_CA_X3.pem

sudo update-ca-certificates

CentOS:

sudo sed -i «s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g» /etc/ssl/certs/ca-bundle.crt

sudo update-ca-trust

Не забудьте проверить так же все ваши контейнеры!!! У них свои хранилища корневых сертификатов и могут использоваться другие версии openssl

Windows

Для пользователей, у которых не подключены автоматические обновления корневых сертификатов, можно добавить сертификат ISRG Root X1 вручную. Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt.org/certs/isrgrootx1.der.

Открыть скачанный файл, в открывшемся окне выбрать «Установить сертификат…»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

В мастере импорта сертификатов выбрать «Локальный компьютер»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

Выбрать «Поместить все сертификаты в следующее хранилище», в диалоге выбора хранилища, открывающемся по кнопке «Обзор…», выбрать «Доверенные корневые центры сертификации»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

На последнем шаге мастера нажать кнопку «Готово».

После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «Win+R», откроется диалог «Выполнить», в котором нужно ввести certmgr.msc

Срок действия сертификата для IdenTrust DST Root CA X3 истек

В открывшемся окне в подразделе «Сертификаты» раздела «Доверенные корневые центры сертификации» в списке должен появиться сертификат ISRG Root X1:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

На стороне сервера

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android &gt;= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL &gt;= 1.1.0.

При этом, у вас есть выбор — ценой отказа от поддержки старых Android (оставив поддержку Android &gt;= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так:

ISRG Root X1 -&gt; Let’s Encrypt R3 -&gt; Конечный сертификат пользователя

Для переключения на альтернативную цепочку нужно воспользоваться документацией вашего ACME-клиента. В частности, в certbot за возможность выбора альтернативной цепочки отвечает параметр —preferred-chain.

Протокол ACME

Для начала нужно пояснить, что основой для работы Let’s Encrypt является протокол ACME (Automated Certificate Management Environment). Это открытый протокол для автоматизации взаимодействия с УЦ. В нём нет ничего специфичного для Let’s Encrypt, его поддерживает несколько других УЦ.

Это означает, что практически все наши инструменты, скрипты и процессы для получения сертификатов из Let’s Encrypt будут отлично работать и с другими центрами, которые поддерживают ACME.

Кроме стандартного клиента Certbot, есть и множество других клиентов ACME.

Чтобы перестроиться на другой УЦ, достаточно просто изменить адрес API в настроенных скриптах с https://acme-v02.api.letsencrypt.org/directory (Let’s Encrypt) на https://api.buypass.com/acme/directory (BuyPass) или какой-нибудь другой.

SSL. com

После регистрации аккаунта нужно зайти на эту страницу и скопировать учётные данные для доступа к API: Account/ACME Key, Secret Key, HMAC Key.

Срок действия сертификата для IdenTrust DST Root CA X3 истек

Затем настроить клиент ACME на работу с API от SSL.com: зарегистрировать аккаунт RSA, аккаунт ECC — и сгенерировать сертификат.

Subject: CN=...
Issuer: CN=SSL.com SSL Intermediate CA ECC R2,O=SSL Corp,L=Houston,ST=Texas,C=US
-----BEGIN CERTIFICATE-----
...
Ly93d3cuc3NsLmNvbS9yZXBvc2l0b3J5MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDATBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Jscy5zc2wuY29tL1NT
TGNvbS1TdWJDQS1TU0wtRUNDLTM4NC1SMi5jcmwwHQYDVR0OBBYEFIt0k8bwGO+1
n034I0dkoRWqsSZpMA4GA1UdDwEB/wQEAwIHgDCCAXwGCisGAQQB1nkCBAIEggFs
BIIBaAFmAHYA9lyUL9F3MCIUVBgIMJRWjuNNExkzv98MLyALzE7xZOMAAAF7Xbea
SwAABAMARzBFAiEAiyE1SNTQwTmRvVykP/UwEhWEQaB+OK8YgAvdB35D0noCIA2E
+b8=
...
-----END CERTIFICATE-----

Процесс занимает считанные минуты.

На своём сервере можно настроить выдачу сертификатов по очереди или в случайном порядке от четырёх бесплатных УЦ.

Let’s Encrypt и ACME клиенты для Windows

Наличие TLS/SSL сертификата у сайта позволяет защитить данные пользователей, передаваемые по сети от атак человек-посередине (man-in-the-middle) и гарантировать целостность переданных данных. Некоммерческий центр сертификации Let’s Encrypt позволяет в автоматическом режиме через API выпускать бесплатные криптографические TLS сертификаты X.509 для шифрования (HTTPS) . Выдаются только сертификаты для валидации доменов (domain validation), со сроком действия 90 дней (есть ограничение – 50 сертификатов для одного домена в неделю). Но вы можете автоматически перевыпускать SSL сертификат для своего сайта по расписанию.

API интерфейс, позволяющий автоматически выпускать сертификаты называется Automated Certificate Management Environment (ACME) API. Для Windows систем на данный момент имеется 3 самых популярных реализации клиента ACME API:

  • Утилита Windows ACME Simple (WACS) – утилита командной строки для интерактивного выпуска сертификата и привязки его к определенному сайту на вашем веб сервере IIS;
  • Модуль Powershell ACMESharp – библиотека Powershell с множеством команд для взаимодействия через ACME API с серверами Let’s Encrypt;
  • Certify – графический менеджер SSL сертификатов для Windows, позволяет интерактивно управления сертификатами через ACME API.

Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server

Самый простой способ получить SSL сертификат от Let’s Encrypt — воспользоваться консольной утилитой Windows ACME Simple (WACS) (ранее проект назывался LetsEncrypt-Win-Simple). Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS, и автоматически выпустить и привязать к нему SSL сертификат.

Итак, предположим у нас имеется веб сайт на IIS, развёрнутый под управлением Windows Server 2016. Наша задача, переключить его в HTTPS режим, установив SSL сертификат от Let’s Encrypt.

Скачайте последний релиз клиента WACS со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases (в моем случае это версия v2.0.10 – файл win-acme.v2.0.10.444.zip).

Windows ACME Simple скачать с github

Распакуйте архив в каталог на сервере с IIS: c:\inetpub\letsencrypt

letsencrypt - клиент wacs.exe

Откройте командную строку с правами администратора, перейдите в каталог c:\inetpub\ letsencrypt и запустите wacs.exe.

Запустится интерактивный мастер генерации сертификата Let’s Encrypt и привязки его к сайту IIS. Чтобы быстро создать новый сертификат выберите N: — Create new certificates (simple for IIS).

wacs создать новый ssl сертфикат для сайта iis

Затем нужно выбрать тип сертификата. В нашем примере нет необходимости использовать сертификат с псевдонимами (несколькими SAN — Subject Alternative Name), поэтому достаточно выбрать пункт 1. Single binding of an IIS site. Если вам нужен Wildcard-сертификат, выберите опцию 3.

Далее утилита выведет список сайтов, запущенных на сервере IIS и предложит выбрать сайт, для которого нужно создать и привязать новый SSL сертификат.

wac выбрать сайт iis для создания сертфиката ssl

Укажите ваш email, на который будут отправляться уведомления о проблемах с обновлением сертификата сайта и другие о повешения (можно указать несколько email через запятую). Осталось согласится с условиями использования и Windows ACME Simple подключится к серверам Let’s Encrypt и попытается автоматически сгенерировать новый SSL сертификат для вашего сайта.

сгенерировать сертификат letsencrypt

Процесс генерации и установки SSL сертификата Let’s Encrypt для IIS полностью автоматизирован.

По умолчанию выполняется валидация домена в режиме http-01 validation (SelfHosting). Для этого нужно, чтобы в DNS домена имелась запись, указывающая на ваш веб сервера. При запуске WACS в ручном режиме можно выбрать валидацию типа — 4 [http-01] Create temporary application in IIS (recommended). В этом случае на веб-сервере IIS будет создано небольшое приложение, через которое сервера Let’s Encrypt смогут провести валидацию.

Примечание. При выполнении TLS/HTTP проверки ваш сайт должен быть доступен снаружи по полному DNS имени по протоколам HTTP (80/TCP) и HTTPS (443/TCP).

Утилита WACS сохраняет закрытый ключ сертификата (*.pem), сам сертфикат и ряд других файлов в каталог C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple. Затем она в фоновом режиме установит сгенерированный SSL сертификат Let’s Encrypt и привяжет его к вашему сайту IIS. Если на сайте уже установлен SSL сертификат (например, самоподписанный), он будет заменен новым.

В IIS Manager откройте меню Site Binding для вашего сайта и убедитесь, что для него используется сертификат, выданный Let’s Encrypt Authority X3.

сертфикат сайта IIS подписан Let’s Encrypt Authority X3

В хранилище сертификатов компьютера сертификат Let’s Encrypt для IIS вы можете найти в разделе Web Hosting -&gt; Certificates.

Web Hosting Certificates

Windows ACME Simple создает новое правило в планировщике заданий Windows (win-acme-renew (acme-v02.api.letsencrypt.org)) для автоматического продления сертификата. Задание запускается каждый день, продление сертификата выполняется через 60 дней. Планировщик запускает команду:

C:\inetpub\letsencrypt\wacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org"

Эту же команду вы можете использовать для ручного обновления сертфиката.

задание планировщика Windows для обновления tls сертфиката letsencrypt через win acme renew

Перенаправление трафика IIS сайта с HTTP на HTTPS адрес

Чтобы перенаправить весь входящий HTTP трафик на HTTPS сайт, нужно установить модуль Microsoft URL Rewrite Module (https://www.iis.net/downloads/microsoft/url-rewrite), и убедиться, что в настройках сайта не включена опция обязательного использования SSL (Require SSL). Осталось настроить редирект в файле web.config:

<system.webServer>
<rewrite>
<rules>
<rule name="HTTP to HTTPS Redirect" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>

Также вы можете настроить перенаправление трафика через URL Rewrite через графический интерфейс IIS Manager. Выберите Sites -&gt; yoursitename -&gt; URL Rewrite.

iis модуль URL Rewrite

Создайте новое правило Add Rule -&gt; Blank rule.

Укажите имя правила и измените значения параметров:

  • Using -> Regular Expressions

URL-Rewrite edit inbound rule

В блоке Conditions измените Logical Grouping -&gt; Match All и нажмите Add. Укажите

  • Check if input string -> Matches the Pattern

url rewrite добавить условия

Теперь в блоке Action выберите:

  • Redirect URL -> https://{HTTP_HOST}/{R:1}

Откройте браузер и попробуйте открыть ваш сайт по HTTP адресу, вас должно автоматически перенаправить на HTTPS URL.

Использование сертификата Let’s Encrypt для Remote Desktop Services

Если вы используете для подключения внешних пользователей в корпоративную сеть шлюз Remote Desktop Gateway/ RD Web Access, вы можете использовать нормальный SSL сертификат Let’s Encrypt вместо обычного самоподписанного сертификата. Рассмотрим, как корректно установить сертификат Let’s Encrypt для зажиты служб Remote Desktop Services в Windows Server.

Если на Remote Desktop Gateway сервере поднята также роль RDSH, нужно запретить пользователям Read доступ к каталогу, в котором у вас хранится WACS (в моем примере это c:\inetpub\letsencrypt ) и к каталогу с сертификатами сертификат Let’s Encrypt (C:\ProgramData\win-acme).

Затем на сервере RDP GW, запускаете wacs.exe, как описано выше, и вы выбираете нужный сайт IIS (обычно, Default Web Site). Let’s Encrypt выдает вам новый сертификат, который устанавливается для веб-сайта и в планировщике появляется задание на автоматические обновление сертификата.

Вы можете вручную экспортировать данный сертификат и привязать его к нужным службам RDS через SSL binding. Но вам придется выполнять эти действия вручную каждые 60 дней при перевыпуске сертификата Let’s Encrypt.

Дополнительно:  Синий экран при включении компьютера (ноутбука) без надписей

Нам нужен скрипт, который бы сразу после получения (продления) сертификата Let’s Encrypt применял бы его для RD Gateway.

В проекте win-acme есть готовый PowerShell скрипт ImportRDGateway.ps1 (https://github.com/PKISharp/win-acme/tree/master/dist/Scripts), который позволяет установить выбранный SSL сертификат для служб Remote Desktop. Главный недостаток скрипта – приходится вручную указывать отпечаток нового сертификата:
ImportRDGateway.ps1 <certThumbprint>

Для автоматического получения отпечатка сертификата с указанного сайта IIS используйте доработанный скрипт ImportRDGateway_Cert_From_IIS.ps1 (основан на стандартном ImportRDGateway.ps1).

Инструкция и модифицированный PowerShell скрипт присланы нашим читателем Антоном, за что посылаем ему лучи благодарности!

Вы можете запустить это скрипт вручную:

powershell -File ImportRDGateway_Cert_From_IIS.ps1

Если у вас RDS Gateway живет на стандартном IIS сайте «Default Web Site» с индексом 0, можете использовать скрипт без изменений.

Чтобы получить ID сайта в IIS, откройте консоль PowerShell и выполните:

Import-Module WebAdministration
Get-ChildItem IIS:Sites

Получите список вида:

Get ChildItem IIS Sites - получить индексы сайтов в IIS

В колонке ID указан индекс вашего сайта, отнимите от него единицу. Полученный индекс вашего сайта нужно указать вместо 0 в 27 строке скрипта PowerShell:

$NewCertThumbprint = (Get-ChildItem IIS:SSLBindings)[0].Thumbprint

ImportRDGateway_Cert_From_IIS - powershell скрипт для привязки ssl сертфиката из iis к rds

Теперь откройте задание планировщика win-acme-renew (acme-v02.api.letsencrypt.org) и на вкладке Action добавьте новое задание, которое запускает скрипт ImportRDGateway_Cert_From_IIS.ps1 после обновления сертификата.

Чтобы не менять разрешения на выполнение скриптов PowerShell, вы можете вызывать скрипт командой:

PowerShell.exe -ExecutionPolicy Bypass -File c:\inetpub\letsencrypt\ImportRDGateway_Cert_From_IIS.ps1

Срок действия сертификата для IdenTrust DST Root CA X3 истек

Теперь скрипт привязки SSL сертификата к службам RDS будет выполнятся сразу после продления сертификата Let’s Encrypt. При этом автоматически перезапускается служба RD Gateway командой:

Restart-Service TSGateway

При перезапуске службы TSGateway все текущие сессии пользователей разрываются, поэтому желательно изменить периодичность запуска задания обновления сертфиката на 1 раз в 60 дней.

Также вы можете использовать бесплатные сертификаты Let’s Encrypt в Linux для веб сайтов на Nginx или apache.

Отметим, что сертификаты Let’s Encrypt в настоящий момент широко используются на сайтах многих крупных компаний и им доверяют все браузеры. Надеюсь, что судьба бесплатного центра сертификации Let’s Encrypt не постигнет участь WoSign и StartCom.

Немного теории и истории

Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let’s Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов. Система при проверке будет доверять сертификатам, которые подписаны с использованием закрытого ключа одного из этих корневых сертификатов. Сами корневые сертификаты как правило имеют длительные сроки действия, меняются редко и не используются при формировании сертификатов конечного субъекта (в данном случае, сертификатов для доменных имен), вместо этого инфраструктура открытых ключей, предполагает использование цепочек доверия — корневые сертификаты применяются для подписания промежуточных сертификатов, а уже с использованием них подписываются сертификаты конечного субъекта (сертификаты для доменов). При этом, для того, чтобы система доверяла конечному сертификату, она должна быть способна проследить всю цепочку от этого сертификата до одного из корневых сертификатов, которым она доверяет.

После появления проекта Let’s Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем «из коробки» (без дополнительных действий со стороны пользователей этих систем). В связи с этим, для сертификатов Let’s Encrypt стала использоваться цепочка доверия, ведущая к корневому сертификату DST Root CA X3, который признается большинством систем:

  • Windows &gt;= XP SP3

  • macOS (большинство версий)

  • iOS (большинство версий)

  • Android &gt;= v2.3.6

  • Mozilla Firefox &gt;= v2.0

  • Ubuntu &gt;= precise / 12.04

  • Debian &gt;= squeeze / 6

  • Java 8 &gt;= 8u101

  • Java 7 &gt;= 7u111

  • NSS &gt;= v3.11.9

  • Amazon FireOS (Silk Browser)

  • Cyanogen &gt; v10

  • Jolla Sailfish OS &gt; v1.1.2.16

  • Kindle &gt; v3.4.1

  • Blackberry &gt;= 10.3.3

  • PS4 game console with firmware &gt;= 5.00

К настоящему моменту корневой сертификат ISRG Root X1 существует уже более 5 лет и за это время попал в доверенные в большинстве современных систем, ему доверяют:

  • Windows &gt;= XP SP3 (при условии, что производилось автоматическое обновление корневых сертификатов)

  • macOS &gt;= 10.12.1

  • iOS &gt;= 10

  • Android &gt;= 7.1.1

  • Mozilla Firefox &gt;= 50.0

  • Ubuntu &gt;= xenial / 16.04 (с установленными обновлениями)

  • Debian &gt;= jessie / 8 (с установленными обновлениями)

  • Java 8 &gt;= 8u141

  • Java 7 &gt;= 7u151

  • NSS &gt;= 3.26

Для сертификатов Let’s Encrypt по умолчанию в данный момент предлагается такая цепочка доверия:

IdenTrust’s DST Root CA X3 -&gt; ISRG Root X1 -&gt; Let’s Encrypt R3 -&gt; Конечный сертификат пользователя

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые не доверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android &gt;= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов.

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Что со всем этим делать?

На стороне клиента

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

faketime -f '@2021-10-01 00:00:00' curl https://letsencrypt.org/

Если всё в порядке, curl вернёт содержимое страницы, если же нет — выдаст сообщение об ошибке:

curl: (60) server certificate verification failed.

В этом случае нужно убедиться, что:

  1. Ваша система доверяет ISRG Root X1

  2. Вы не пользуетесь устаревшей версией OpenSSL

Проверка доверия к ISRG Root X1

Например, Ubuntu 16.04 xenial и Debian 8 jessie доверяют ISRG Root X1, но при этом поставляются с OpenSSL 1.0.x, поэтому проблема их может коснуться.

Чтобы проверить наличие сертификата ISRG Root X1 в числе доверенных:

в Debian/Ubuntu:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "ISRG Root X1"

в CentOS:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "ISRG Root X1"

В выводе команды в обоих случаях должно присутствовать:

subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Если такой строчки нет, то нужно добавить ISRG Root X1 в доверенные. В Debian/Ubuntu:

curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt | sudo tee /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

добавить в файл /etc/ca-certificates.conf строчку:

mozilla/ISRG_Root_X1.crt

и выполнить комнаду

sudo update-ca-certificates

Проверка версии OpenSSL

Если система доверяет ISRG Root X1, нужно проверить версию OpenSSL

openssl version

В выводе должна быть версия 1.1.0 или новее.

Если используется OpenSSL 1.0.x, то достаточным решением проблемы будет удалить из доверенных сертификат DST Root CA X3 (это решение может не сработать для openssl версий &lt;1.0.1p и &lt;1.0.2d). Это можно сделать, не дожидаясь 30 сентября.

В Debian/Ubuntu:

В файле /etc/ca-certificates.conf нужно найти строчку:

mozilla/DST_Root_CA_X3.crt

и поставить в начало сроки символ «!»:

!mozilla/DST_Root_CA_X3.crt

Далее, необходимо выполнить команду:

sudo update-ca-certificates

В CentOS

Выполнить команды:

trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem

sudo update-ca-trust

Локальное продление срока действия сертификата DST Root CA X3

Для тех случаев, когда используется совсем старый openssl (версии меньше 1.0.1p и 1.0.2d, но новее 0.9.8m), или по иной причине не срабатывает метод с изъятием из доверенных сертификата DST Root CA X3, можно воспользоваться еще одним методом, предложенным в статье Scott’а Helme. Метод основан на том, что OpenSSL, начиная с версии 0.9.8m, не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный. Для того, чтобы продлить для OpenSSL на системе срок действия сертификата DST Root CA X3 еще на три года можно выполнить следующие команды:

Debian/Ubuntu:

sudo sed -i «s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g» /etc/ssl/certs/DST_Root_CA_X3.pem

sudo update-ca-certificates

CentOS:

sudo sed -i «s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g» /etc/ssl/certs/ca-bundle.crt

sudo update-ca-trust

Не забудьте проверить так же все ваши контейнеры!!! У них свои хранилища корневых сертификатов и могут использоваться другие версии openssl

Windows

Для пользователей, у которых не подключены автоматические обновления корневых сертификатов, можно добавить сертификат ISRG Root X1 вручную. Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt.org/certs/isrgrootx1.der.

Открыть скачанный файл, в открывшемся окне выбрать «Установить сертификат…»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

В мастере импорта сертификатов выбрать «Локальный компьютер»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

Выбрать «Поместить все сертификаты в следующее хранилище», в диалоге выбора хранилища, открывающемся по кнопке «Обзор…», выбрать «Доверенные корневые центры сертификации»:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

На последнем шаге мастера нажать кнопку «Готово».

После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «Win+R», откроется диалог «Выполнить», в котором нужно ввести certmgr.msc

Срок действия сертификата для IdenTrust DST Root CA X3 истек

В открывшемся окне в подразделе «Сертификаты» раздела «Доверенные корневые центры сертификации» в списке должен появиться сертификат ISRG Root X1:

Срок действия сертификата для IdenTrust DST Root CA X3 истек

На стороне сервера

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android &gt;= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL &gt;= 1.1.0.

При этом, у вас есть выбор — ценой отказа от поддержки старых Android (оставив поддержку Android &gt;= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так:

ISRG Root X1 -&gt; Let’s Encrypt R3 -&gt; Конечный сертификат пользователя

Для переключения на альтернативную цепочку нужно воспользоваться документацией вашего ACME-клиента. В частности, в certbot за возможность выбора альтернативной цепочки отвечает параметр —preferred-chain.

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10. Кроме того, под раздачу могут попасть различные устройства IoT, старые телевизоры и подобные им устройства, для которых не существует обновлений с новыми корневыми сертификатами.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10. Кроме того, под раздачу могут попасть различные устройства IoT, старые телевизоры и подобные им устройства, для которых не существует обновлений с новыми корневыми сертификатами.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался

Где скачать сертификат DST Root CA x3?

Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt

Чем заменить Letsencrypt?

Четвёртый бесплатный УЦ как альтернатива Let’s Encrypt Кроме него, это делают норвежский Buypass (услуга BuyPass Go SSL) и австрийский ZeroSSL

Как выпустить сертификат Let’s Encrypt Windows?

Откройте командную строку с правами администратора, перейдите в каталог c:\inetpub\ letsencrypt и запустите wacs. Запустится интерактивный мастер генерации сертификата Let’s Encrypt и привязки его к сайту IIS. Чтобы быстро создать новый сертификат выберите N: — Create new certificates (simple for IIS)

Как обновить сертификат безопасности на компьютере?

Установить скачанный сертификат в систему. Для этого нажмите сочетание кнопок Win+R и введите команду certmgr. msc — OK. В открывшемся центре сертификатов в Windows откройте вкладку «Доверенные корневые центры сертификации / сертификаты » — клик правой кнопкой мыши — выберите «Все задачи — импорт»

Как обновить корневые Сертификаты в Windows 7?

Для этого нажмите сочетание кнопок Win +R и введите команду certmgr. msc — OK. В открывшемся центре сертификатов в Windows откройте вкладку «Доверенные корневые центры сертификации/ сертификаты » — клик правой кнопкой мыши — выберите «Все задачи — импорт»

Где скачать сертификат DST Root CA x3?

Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt

Как импортировать сертификат в Windows 7?

Импорт сертификата и закрытого ключа Откройте Диспетчер сертификатов . Выберите папку, в которую следует импортировать сертификат . В меню Действие выберите пункт Все задачи и выберите команду Импорт . Нажмите кнопку Далее и следуйте инструкциям. 12 мая 2021 г

Оцените статью
Master Hi-technology
Добавить комментарий