LINUX.ORG.RU
Форум — Admin  

В феврале Let's Encrypt перейдёт на 64-дневные сертификаты

 


0

1

Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, предупредил о сокращении срока действия TLS-сертификатов c 90 до 64 дней. С 10 февраля 2027 года все новые и обновляемые сертификаты будут выдаваться на 64 дня, а выданные до этой даты 90-дневные сертификаты продолжат своё действие. Помимо этого 10 февраля 2027 года с 30 до 10 дней будет сокращён период действия авторизации, т.е. времени после подтверждения своих прав на домен, в течение которого сертификат может быть выдан без прохождения повторных проверок. C 16 февраля 2028 года срок действия сертификатов намерены сократить с 64 до 45 дней, а авторизации - c 10 дней до 7 часов.

Причиной сокращения срока действия сертификатов стали новые требования ассоциации CA/Browser Forum, выработанные в ходе совместной работы производителей браузеров и удостоверяющих центров. Аналогичное сокращение срока действия будет внедрено всеми удостоверяющими центрами. CA/Browser Forum определил конечный срок завершения внедрения мартом 2029 года, а максимальное время действия сертификата - 47 днями. После марта 2029 года обработка в браузерах новых сертификатов, срок действия которых превышает 47 дней, будет приводить к выводу в ошибки «ERR_CERT_VALIDITY_TOO_LONG».

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

В феврале Let’s Encrypt перейдёт на 64-дневные сертификаты

Перемещено shell-script из security


Ответ на: комментарий от firkax

Где она находится в трёхпунктовом сценарии который имеется в нормальном случае?

Естественно, в первом и втором пунктах. Ваши «могу доказать» слишком общие. Здесь нужно заменить «доказательство вручную» на автоматическое доказательство, т.е. на использование апплета для обращения к нашему сервису.

estic
()
Ответ на: комментарий от firkax

И каким образом она может быть не автоматической?

Ну, что там Certbot предлагает сделать пользователю для валидации вручную? Разместить такой-то файл с таким-то содержимым там-то на сервере (это по памяти, я уже не помню точно).

estic
()
Ответ на: комментарий от estic

Ты серьёзно думаешь что LE подтверждают через ручное размещение каких-то файлов (видимо, через фтп)? Может быть ты и сам таким занимался? Ну, печально. Файлы размещает le-клиент, сам, безо всяких ручных действий.

на автоматическое доказательство, т.е. на использование апплета для обращения к нашему сервису.

Нет, нужно использование le-клиента для автоматического обращения к letsencrypt-у.

Certbot

Ну и certbot не нужен, это блоатварь. Есть нормальные клиенты, например acme-tiny.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от shell-script

Точнее, не знаешь. ;) Судя по треду.

Тролль? Просто я таким не занимаюсь. Но видел когда-то.

estic
()
Ответ на: комментарий от shell-script

Обычный скрипт на питоне это как раз acme-tiny - 200 строк и 12 кбайт на всё.

А certbot это мусорная куча файлов https://packages.debian.org/bullseye/all/python3-certbot/filelist и куча зависимостей https://packages.debian.org/bullseye/python3-certbot

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты серьёзно думаешь что LE…

Посмотрите мое первое сообщение, с чего все началось. Когда я пишу о чем-то одном, у меня нет привычки перескакивать на что-то другое, не предупредив об этом собеседника. По протоколу ACME сервер CA передает AMCE-клиенту проверочные данные. Как их обрабатывает ACME-клиент, это уже его дело. Certbot может и пользователю сообщить, если не указаны «хуки» (апплеты) для обработки. Я это точно знаю в отличие от «задиры» выше.

Чтобы ACME-клиент мог что-то разместить на сервере, он сам должен размещаться на этом сервере или иметь удаленный доступ к этому серверу. При использовании нашего сервиса проверочные данные размещаются не на пользовательском сервере, а в хранилище сервиса. Т.е. на сервере нет необходимости держать какой-либо софт для выпуска сертификатов. Соответственно нужно устанавливать сертификаты вручную или держать софт для приема и установки готовых сертификатов. Простой пример, чтобы было понятнее (сначала я думал, что это и так понятно):

  • дома certbot renew
  • скопировали сертификаты (и приватные ключи, если они новые) на сервер
  • на сервере service nginx reload

Ну и certbot не нужен, это блоатварь.

Certbot я для конкретики назвал. Сервису валидации все равно, какой ACME-клиент, если его можно настроить для обращения к сервису.

estic
()
Последнее исправление: estic (всего исправлений: 2)

как раз недавно перешла на angie, а то скрипты слишком часто запускать напрягает

и да.. учитывая новость про deno... раньше вестников, приносящих плохие новости, казнили

Sylvia ★★★★★
()
Ответ на: комментарий от estic

Certbot может и пользователю сообщить, если не указаны «хуки» (апплеты) для обработки.

Этот режим никто в здравом уме не использует, сравнивать с ним незачем.

Чтобы ACME-клиент мог что-то разместить на сервере, он сам должен размещаться на этом сервере или иметь удаленный доступ к этому серверу.

Во-первых, ACME-клиенту не обязательно что-то размещать на сервере. Он должен разместить файлы там, откуда они могут быть прочитаны через обращение к серверу. Через обращение к серверу могут быть прочитаны не только его локальные файлы, но и другие - либо через прокси на сервере, либо (что намного удобнее) через http-редирект на другой сервер где эти файлы лежат.

Во-вторых, размещение ACME-клиента на сервере это не то, чего имеет смысл избегать. Разумеется, речь не про certbot а про нормальные клиенты. Какие-то их них требуют питон, ну ладно питон может хотеться избежать, есть клиенты написанные в виде шелл-скриптов или на Си, без зависимостей, одним файлом.

Т.е. на сервере нет необходимости держать какой-либо софт для выпуска сертификатов. Соответственно нужно устанавливать сертификаты вручную или держать софт для приема и установки готовых сертификатов.

Очень плохо. Во-первых, повторю ещё раз, забудь про установку LE-сертификатов вручную (и ручные запуски клиента, и ручные копирования куда-то сертификатов, и ручные перезапуски nginx-а), никто в здравом уме это делать не будет. Во-вторых, ACME-клиент - это и есть «софт для приёма и установки сертификатов». Софт для выпуска сертификатов же расположен на серверах LE и тебе его запускать никто не предлагает. Так что возвращаемся к так и неотвеченному вопросу - зачем принимать сертификаты от тебя, когда их можно принимать напрямую из первоисточника.

и приватные ключи, если они новые) на сервер

А это - отдельный 🤦. Приватные ключи никуда копировать нельзя, особенно если у тебя всего один сервер. Они должны генерироваться на сервере и никогда его пределов не покидать. Для того, чтобы сообщить LE, к каким именно ключам нужен сертификат, есть файл запроса (.csr) - он делается на том же сервере из приватного ключа, и этот файл уже не секретный, его можно куда-то копировать.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Этот режим никто в здравом уме не использует, сравнивать с ним незачем.

Я писал именно про это. Как написал вначале, я использую часто. Использую не только я. Если вам нравится считать таких людей безумцами, ваше право. :) Кстати, сервис можно использовать не только при ручном выпуске.

через http-редирект

Сервис как раз и рассчитан под переадресацию. По сути он предоставляет простой Storage API.

Во-вторых, ACME-клиент - это и есть «софт для приёма и установки сертификатов».

Понятия близки, но все-таки различаются. Пассивно принимать готовый сертификат и инициировать выпуск сертификата - это немного разные вещи.

Так что возвращаемся к так и неотвеченному вопросу - зачем принимать сертификаты от тебя

Если не я в роли пользователя, то сертификаты принимаются не от меня. :) Всегда было нормально, что сертификаты проходят «через руки» инициировавшего их выпуск пользователя. В общем возможны различные сценарии. Мы добавили немного гибкости. Например, мне не нравится «ваш вариант». Я предпочитаю выносить ACME-клиента на какой-нибудь «клиент» не только по отношению к CA-серверу, но и к серверу, для которого выпускаются сертификаты. Зачем при наличии множества серверов мне нужны ACME-клиенты на каждом? Ведь я могу выпускать сертификаты централизованно. Или легко менять место выпуска.

estic
()
Последнее исправление: estic (всего исправлений: 1)
Ответ на: комментарий от estic

я использую часто.

Зачем? Нравится раз в 3 месяца мучительно вспоминать об этом? А если пропустишь (заболеешь например или без интернета останешься на какое-то время)? А скоро не раз в 3 месяца будет а раз в полтора.

Пассивно принимать готовый сертификат и инициировать выпуск сертификата - это немного разные вещи.

Отличие тут вот в чём: «инициировать выпуск сертификата» означает предоставить доказательство владения доменом для конкретной данной операции, и, соответственно, не предоставить ни для каких других. Скачивать готовые же означает что доказательства сделаны без твоего участия, без твоего контроля и ты не знаешь сколько там сертификатов навыпускали и для чего. Полагаешься исключительно на доверие к тому, кто контролирует содержимое твоего .well-known/acme_challenge.

Я предпочитаю выносить ACME-клинта на какой-нибудь «клиент» не только по отношению к CA-серверу, но и к серверу, для которого выпускаются сертификаты. Зачем при наличии множества серверов мне нужны ACME-клиенты на каждом?

Верно, если серверов много то проще общаться с LE только на одном, а с других поставить упомянутые редиректы на него. Но этот сервер (тот, кто может публиковать проверочные файлы) тоже надо охранять от внешнего вмешательства, ты же предлагаешь контроль над ним подарить кому-то постороннему.

firkax ★★★★★
()
Ответ на: комментарий от estic

Зачем при наличии множества серверов мне нужны ACME-клиенты на каждом?

Caddy, Angie

для Angie -

http {
# Angie ACME
resolver localhost valid=180s;
acme_client acmele_1  https://acme-v02.api.letsencrypt.org/directory;
acme_client_path /etc/nginx/ssl/angie;

назначаем 1 клиент, если надо несколько сертификатов - несколько клиентов, в данном случае мы будем выписывать SAN сертификат для нескольких блоков server { }


в
server {
    server_name тут_стандартное_имя_или_имена_сервера;
    acme acmele_1;
    ssl_certificate     $acme_cert_acmele_1;
    ssl_certificate_key $acme_cert_key_acmele_1;

ну как бы все, делаем angie -s reload и через 10 секунд у нас:

 # ls -l acmele_1/
итого 16
-rw------- 1 root root 1704 окт 10 21:28 account.key
-rw-r--r-- 1 root root 4864 окт 10 21:29 certificate.pem
-rw------- 1 root root  241 окт 10 21:28 private.key


если посмотреть инфу о сертификате pem, то там CN= имени первого загруженного server {}
а все остальное добавлено в
X509v3 Subject Alternative Name:
DNS:

и все, процедура перехода с обычной конфигурации nginx заняла у меня меньше 10 минут,
при этом я навсегда могу забыть на этом сервере про мышиную возню с 64 дня... 45 дней...

Sylvia ★★★★★
()
Последнее исправление: Sylvia (всего исправлений: 1)
Ответ на: комментарий от firkax

Зачем? Нравится раз в 3 месяца мучительно вспоминать об этом?

:D Если ответственный админ вдруг впадет в кому, есть кому подхватить его работу. Про уведомления от Календаря и т.п. уже писал в теме. Кроме того, у нас по регламенту и при автоматическом выпуске/установке все равно требуется ручная проверка, не автоматическая. Так что нет большой разницы, устанавливать с проверкой или просто проверять.

ты же предлагаешь контроль над ним подарить кому-то постороннему

Еще раз обрати внимание на то, что сервис отвечает только за валидацию. Я не предлагаю кому-то выпускать сертификаты на нашем сервере.

estic
()
Ответ на: комментарий от Sylvia

при этом я навсегда могу забыть на этом сервере про мышиную возню с 64 дня... 45 дней...

Обращают внимание на неё только те, кто не смог нормально настроить обновление по проверке срока действия, или те кто вообще не осилил автоматизацию.

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

А вот засовывать это в веб-сервер считаю плохой идеей.

firkax ★★★★★
()
Ответ на: комментарий от estic

Еще раз обрати внимание на то, что сервис отвечает только за валидацию. Я не предлагаю кому-то выпускать сертификаты на нашем сервере.

Если у третьего лица есть контроль над содержимым .well-known/acme_challenge то он может выпускать сертификаты к этому домену сам без участия кого бы то ни было ещё. А вся суть этой проверки как раз в том, чтобы третьих лиц отсеять.

firkax ★★★★★
()
Ответ на: комментарий от firkax

«Каждому - свое», как было написано на чугунных воротах в одно место...
у меня тоже была настроена автоматизация скриптами, но с ручным запуском скрипта центрально ( выписать сертификаты, выложить их на сервера по scp) и на серверах (взять сертификаты, положить куда надо, сделать nginx -s reload)

все равно.. напоминалки, всякая ерунда.. а тут - раз настроишь и дальше можно просто забыть.

Sylvia ★★★★★
()
Ответ на: комментарий от firkax

Если у третьего лица есть контроль над содержимым .well-known/acme_challenge

вот это как раз очень больное место, в свете наличия дыр в многочисленных CMS...

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

но с ручным запуском скрипта центрально

Недонастроена. Осталось этот скрипт в ежедневный крон включить.

и дальше можно просто забыть

да

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ну, перевыпустим мы (хотя мы даже домены не отслеживаем) или кто-то другой, взломавший учетку отдельного пользователя, сертификат. И что? Непосредственно на криптографию это не влияет. Любой компетентный админ может использовать свое хранилище для переадресации на него. А боязливый некомпетентный может прикрывать переадресацию, когда не выпускает сертификат. :)

В общем все уже годами проверено. Риски минимальные.

estic
()
Последнее исправление: estic (всего исправлений: 1)

кстати вот сначала они убрали OCSP... А теперь решили просто форсировать сокращенный срок жизни сертификатов...

Sylvia ★★★★★
()
Ответ на: комментарий от estic

Ну, перевыпустим мы или кто-то другой, взломавший учетку отдельного пользователя, сертификат. И что?

Ты притворяешься или как? Единственный смысл имеющейся системы сертификатов и CA в том, чтобы подтвердить, что выпустивший его - действительно владелец. Если нужна просто криптография (без подтверждения) то достаточно самоподписанного, но браузеры закономерно предупреждают, что сертификат этот неизвестно чей.

Любой компетентный админ может использовать свое хранилище для переадресации на него.

Разумеется, учитывая что это «хранилище» - это всего лишь запущеный nginx. И никакой повышенной компетентности для его запуска не требуется.

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

Это не поможет, можно выпустить поддельный сертификат как раз в это время.

Риски минимальные.

Риск тут очевидный, а минимальная - польза.

firkax ★★★★★
()
Ответ на: комментарий от estic

Стороннее это ты сначала создал проблемы, а потом ещё её долго решал. В то время как запустить nginx на том же сервере где acme-клиент и редиректить на него со своих сайтов - делается элементарно и без рисков.

firkax ★★★★★
()
Ответ на: комментарий от shell-script

DNS - да, не умеет, в большинстве случаев оно не нужно и мне в частности тоже не нужно (это надо городить безопасное апи к перенастройке днс-зоны, чтобы он мог изменить только свою запись и ничего другого, нецелесообразная возня). Что за расширенное управление?

firkax ★★★★★
()
Ответ на: комментарий от firkax

это надо городить безопасное апи к перенастройке днс-зоны

Зачем? В bind9 можно собирать зону из нескольких файлов. Соответсвенно я выношу для каждой зоны TXT-запись, связанную с LE в отдельный файл. Если нужно поменять токен, точно так же, как ты меняешь его в .well-know/, я меняю его у bind. Единственное, нужно дополнительно перезагрузить зону. Но я всё это делаю через ansible, там это дело одной строчки.

Что за расширенное управление?

Удобное управление, просмотр, выпуск, отзыв, конфиги опять же из коробки, работа с ключами и пр. В общем, всё, что требуется для обычной комфортной работы. Не нужно городить свои велосипеды-обёртки над минимальными acme-клиентами. Зачастую такие обёртки потом притянут столько же зависимостей, что и у certbot'а.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Зачем? В bind9 можно собирать зону из нескольких файлов. Соответсвенно я выношу для каждой зоны TXT-запись, связанную с LE в отдельный файл

Ты про инклюд файла в котором внутри список ресурсных записей? Или там можно как-то ограничить списиок того, что в этом файле можно задавать? Если туда вместо TXT вписать A-запись named будет ругаться? А то что это TXT именно letsecnrypt-овое, а не например SPF или проверка сайта для привязки его к яндекс-вебмастеру какому-нить - там есть возможность проверять?

Ну и надо serial менять каждый раз.

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

Это какие-то общие слова. Просмотр чего и зачем? Выпуск делается в кроне или можно эту же одну строку запустить внепланово если добавился новый домен. Отзыв тебе хоть раз понадобился? Конфиги - что? Если ты про то что certbot лазит к конфиги nginx-а и что-то там пытается исправлять - то это наоборот ужасно и ни в коем случае не надо. Задача клиента - скачать сертификат. Работа с ключами - задача настройки веб-сервера а не le-клиента. le-клиент никакие ключи видеть не должен, его доступ должен быть ограничен csr-файлами и местом куда класть сертификаты.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты про инклюд файла в котором внутри список ресурсных записей?

Да.

там есть возможность проверять?

Нет. Зачем? Я не знаю, что такое яндекс-вебмастер, у меня всё self-hosted.

Просмотр чего и зачем?

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

Выпуск делается в кроне

Я не про перевыпуск, а про выпуск новых.

Отзыв тебе хоть раз понадобился?

Да, неоднократно за последние лет 15.

Конфиги - что?

Конфиги, где указываются параметры генерации сертификатов и их форматы. Мне они не только для web'а нужны. Параметры того же DNS, куда смотреть, ключ для проверки токена и т.п.

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

Тут полностью согласен, это у меня отключено.

Работа с ключами - задача настройки веб-сервера а не le-клиента.

И как ты собираешь генерировать сертификат без csr и приватного ключа?

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Нет. Зачем? Я не знаю, что такое яндекс-вебмастер, у меня всё self-hosted.

Но что такое spf то ты знаешь?

Яндекс-вебмастер это админка для управления индексацией твоего сайта, с её помощью в том числе можно поисковую аудиторию украсть.

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

У меня это обновлятор каждый день в лог записывает - какие сертификаты он проверил, какие у них сроки действия, какие обновил или какие не вышло обновить. Так что достаточно просто последний лог посмотреть.

А зачем тебе отзыв был нужен то? Ключи постоянно крадут?

И как ты собираешь генерировать сертификат без csr и приватного ключа?

csr делается в ходе настройки веб-сервера, отправляется обновлятору и тот уже его использует. Доступа к ключу у обновлятора быть не должно, это потенциальная уязвимость.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Но что такое spf то ты знаешь?

Ну и, для почты прописан в DNS, разумеется.

Яндекс-вебмастер это админка для управления индексацией твоего сайта

У меня нет таких сайтов, я web'ом не занимаюсь. Всё, что у меня хостится, это почтовая вебморда, gitea, grafana и т.д. Т.е. мои личные служебные сервисы. Ну и парочка сайтиков для друзей(но там тоже можно пересылать данные).

Так что достаточно просто последний лог посмотреть.

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

А зачем тебе отзыв был нужен то? Ключи постоянно крадут?

Последний раз - менял длину ключа. Старые отозвал, новые залил.

csr делается в ходе настройки веб-сервера, отправляется обновлятору и тот уже его использует.

Настройка web-сервера вообще никакого отношения к генерации сертификатов не имеет. Это разные не связанные между собой вещи.

Доступа к ключу у обновлятора быть не должно, это потенциальная уязвимость.

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

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Последний раз - менял длину ключа. Старые отозвал, новые залил.

Так они сами бы просрочились через не больше 3 месяцев. Какой толк от отзывания? Отзыв это если ключ уже скомпрометирован.

Настройка web-сервера вообще никакого отношения к генерации сертификатов не имеет. Это разные не связанные между собой вещи.

Имеет такое, что именно по веб-серверу определяется какие сертификаты тебе нужны, и эта информация записывается в csr.

Потому что мне нужен не обновлятор, а полноценный способ управления сертификатами.

Он смены ярлыка суть не меняется. Приватный ключ должен генерироваться на том же хосте где nginx, с доступом на чтение только nginx-у, и ни в каких других местах никогда не фигурировать. Потому что сертификаты это способ встроиться в публичную систему CA, а ключ - способ защитить протокол вне зависимости от CA. Тебе же не приходило в голову управление серверными ssh ключами (/etc/ssh/ssh_host_*_key) отдавать куда-то наружу? Тут то же самое.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Так они сами бы просрочились через не больше 3 месяцев. Какой толк от отзывания?

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

Имеет такое, что именно по веб-серверу определяется какие сертификаты тебе нужны, и эта информация записывается в csr.
Приватный ключ должен генерироваться на том же хосте где nginx

Сертификаты используются не только в web'е. И у меня web как раз - это не больше половины мест, гдя я их использую.

ssh ключами (/etc/ssh/ssh_host_*_key) отдавать куда-то наружу? Тут то же самое.

Это вообще здесь ни к месту. Я ключи никому не отдаю.

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от shell-script

Сертификаты используются не только в web'е.

Хорошо, вместо nginx подставь другой сервер. Всё равно - ключ генерируется на том же хосте где будет эксплуатироваться, из ключа делается csr который можно хоть опубликовать, а сам ключ даже в просмотрщике не смотрится (потому что после этого его копия появится на твоём локальном компе в виде хотя бы возможного скриншота, а если сидишь у окна - то записи какой-нить видеокамеры снаружи).

firkax ★★★★★
()

После марта 2029 года обработка в браузерах новых сертификатов, срок действия которых превышает 47 дней, будет приводить к выводу в ошибки «ERR_CERT_VALIDITY_TOO_LONG».

Интересно, а какое их дело, какой срок у сертификата? Ладно выпускающие, а этим-то что надо?

AS ★★★★★
()
Ответ на: комментарий от firkax

Я и не знал что там есть какое-то «время авторизации». Проверили домен, выдали сертификат, забыли.

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

anc ★★★★★
()
Ответ на: комментарий от unDEFER

Это они так скоро и до однодневных сертификатов дойдут…

Вспомнился анекдот «эдак мы до мышей дотрахаемся» :)

anc ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария