Джейкоб Хоффман-Эндрюс, инженер Let's Encrypt, 29 февраля 2020 года опубликовал на корпоративной странице центра сертификации информацию о том, что специалисты Let's Encrypt обнаружили ошибку в рабочем коде для CAA (Certification Authority Authorization). Оказывается, что с 25 июля 2019 года их программное обеспечение Boulder, предназначенное для проверки сертификации, некорректно отрабатывало процедуру повторной проверки в процессе выдачи сертификатов.

Если запрос сертификата содержал N доменных имен, которые требовали повторной проверки CAA, то алгоритм Boulder выбирал из этого списка одно доменное имя и проверял его N раз. В результате существовала возможность выдачи сертификата, даже если потом (до X+30 дней) установить запись CAA, запрещающую выдачу сертификата Let's Encrypt.

Ошибка в работе алгоритма Boulder была исправлена инженерами Let's Encrypt через два часа после обнаружения. Но, фактически, эта ошибка в алгоритме была внесена в рабочий код для CAA двести девятнадцать дней назад. После анализа произошедшего инцидента в Let's Encrypt отзывают большое количество выданных за это время сертификатов TLS/SSL из-за этой ошибки в алгоритме Boulder для повторной проверки CAA, в соответствии с отраслевыми правилами. Хотя инженеры Let's Encrypt написали, что, по их данным, проблемой никто не успел злоупотребить.

Let's Encrypt отправил электронные письма всем пострадавшим из-за этой найденной ошибки подписчикам сервиса и предупредил, что их нужно обновить до 4 марта 2020 года.



Из 116 млн ныне действующих сертификатов Let's Encrypt будет отозвано чуть больше 3 млн (2.6%), из которых примерно 1 млн являются дубликатами, привязанными к одному домену (ошибка в основном затронула очень часто обновляемые сертификаты, поэтому так много дубликатов).

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

Вдобавок Let's Encrypt опубликовал серийные номера выданных ранее сертификатов, которые пострадали из-за этой проблемы, которую назвали 2020.02.29 CAA Rechecking Incident.

Также специалисты Let's Encrypt напомнили, что узнать серийный номер текущего сертификата в системах Linux/BSD можно с помощью команды: openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d : или «openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -serial», короткий вариант: «echo | openssl s_client -connect example.com:443 |& openssl x509 -noout -serial».

Для обновления сертификатов можно воспользоваться certbot: «certbot renew --force-renewal».

Ранее 27 февраля 2020 года в пресс-релизе от бесплатного центра сертификации Let's Encrypt было объявлено, что им был выдан миллиардный сертификат. Уникальная особенность Let's Encrypt является то, что процесс выдачи сертификатов полностью автоматизирован. Let's Encrypt совершил настоящую революцию на рынке, где раньше властвовали коммерческие центры сертификации. Теперь они практически вышли из бизнеса выдачи DV-сертификатов (сертификаты с подтверждением домена, Domain Validation), хотя продолжают продавать сертификаты с подтверждением организации (Organization Validation, OV) и сертификаты высокой надёжности (Extended Validation, EV), которые Let's Encrypt не выдаёт, потому что их нельзя автоматизировать. Впрочем, это нишевый товар, а на массовом рынке безраздельно властвуют бесплатные сертификаты Let's Encrypt.

23 февраля 2020 года Let's Encrypt объявил о внедрении новой схемы подтверждения полномочий на получение сертификата для домена. Обращение к серверу, на котором размещен используемый в проверке каталог "/.well-known/acme-challenge/", теперь будет осуществляться с использованием нескольких HTTP-запросов, отправляемых с четырех разных IP-адресов, размещенных в разных дата-центрах и принадлежащих к разным автономным системам. Проверка признается успешной только, если как минимум три из четырех запросов с разных IP оказались успешными.