dxdt.blog: занимательный интернет-журнал

Вот ещё какой интересный аспект внедрения ИИ/LLM. Бывает, приходится описывать какие-то варианты как следует что-то сделать правильно, в плане серверной/сервисной архитектуры и информационной безопасности, но реализовывать описанное – не спешат: мол, это непонятно, это сложно, нет инженерных ресурсов и т.д. До топ-менеджмента данные вопросы и описания не добираются (что, конечно, правильно, потому что вопрос достаточно специальный, достаточно “локальный” и может решаться горизонтальными связями).

А потом кто-то из топ-менеджмента берёт LLM/ИИ, как это сейчас модно, и задаёт этому ИИ/LLM те же вопросы. А результаты, сгенерированные LLM, мягко и без навязывания присылает “на посмотреть”: мол, мало ли – вдруг там что дельное. И вот выдача ИИ, конечно, содержит и вполне себе бредовые фрагменты, куда ж без этого. Однако немало что сгенерировано, примерно, по делу, слова правильные. Опять же – кто бы сомневался: база, использованная для “обучения” LLM, содержала ведь и разумные вещи тоже. И вот эта часть, которая по делу, практически повторяет то, что уже было и так много раз говорено раньше, без всякого ИИ, но не реализовывалось (“непонятно, не нужно, устарело, нет ресурсов”).

И если вы вдруг сейчас подумали, что выдача ИИ тут же придаёт дополнительный вес уже озвученным идеям, то, к сожалению, вы ошиблись: всё хуже – теперь тем, кто против, можно сослаться, что, мол, да это ж вообще “механический болван” (ИИ/LLM) написал, слово в слово, и, мол, “говорили же, что не нужно, а механического болвана использовать следует с большой осторожностью” (да; тут и не поспорить). Но вот выдача-то “ИИ-болвана” оказалась правильной – такое может быть.

“Трудно стало работать. Развелось много идиотов, говорящих правильные слова” (Штирлиц, цитата по фильму “Семнадцать мгновений весны”).

В Cloudflare сделали для резолвера 1.1.1.1 выдачу DNS-сигнала о том, что для заданного имени на резолвере отключена валидация DNSSEC. Речь идёт про использование так называемых NTA (Negative Trust Anchor) – это способ, позволяющий избирательно отключать валидацию DNSSEC-записей, который должен применяться в исключительных случаях, например, если DNSSEC поломалась в целой зоне первого уровня – как, всего за минувшие пару пару лет, происходило и с .RU, и с .DE, и вот совсем недавно с .AL (Албания). Сигнал об использовании NTA передаётся в расширенных кодах ошибок DNS. Нельзя сказать, что это прямо вот совсем не очередной “костыль” в процессах DNSSEC, потому что на “костыль” всё равно очень похоже, но всё же это сильно лучше, чем просто DNSSEC-валидацию тихо отключать, если “ой, оно опять сломалось”.

Кстати, о поломках DNSSEC и реалиях “технического совершенства” современных интернетов. Вот я только что привёл примеры недавних фатальных сбоев DNSSEC. И среди этих примеров: .RU и .DE. Оба – крупнейшие ccTLD. Домен Германии .DE – вообще на первом месте по количеству зарегистрированных имён, .RU – входит в пятёрку. Имён – миллионы. То есть, это давно уже не про то, что сломался какой-то где-то забытый страновой домен. Вовсе нет. Так что проблема с внедрением DNSSEC – вполне себе масштабная. Да и не только с DNSSEC, конечно.

Недавно я публиковал фото бермудской треугольной монеты, и не просто треугольной, а в виде треугольника Рёло. В этот раз – ещё некоторое количество монет, отчеканенных либо в форме фигуры с постоянной шириной, либо в очень близкой к такой фигуре форме. Посмотрим на монеты, следуя по возрастанию количества углов.

Постоянная ширина для монеты полезна, кроме прочего, потому, что позволяет её хорошо катиться – это необходимо при автоматической обработке и отдельных монет, и даже их потоков. Понятно, что для круглой монеты с качением проблем нет, а вот многоугольная форма – может такие проблемы создавать. Например, у современной монеты в один фунт Великобритании специально были скруглены углы, чтобы приблизить форму к постоянной ширине и облегчить качение: эта монета имеет 12 углов, чётное число, поэтому не может быть “чистой” фигурой постоянной ширины. Но вот приближаться границей к окружности – может: тут как раз относительно большое число сторон только помогает (см. ниже фото чешской монеты).

Итак, форма постоянной ширины должна иметь нечётное количество углов, но вообще – углов может быть самое разное количество (главное – нечётное). Три – первое подходящее число, и треугольные монеты постоянной ширины относительно редкие. На страницах dxdt.blog треугольник в роли бермудского доллара уже был (см. записку по ссылке выше), но скопирую сюда одну из фотографий.

(Фото: бермудский треугольник Рёло, аверс.)

Следующее количество углов – пять. К сожалению, пятиугольную монету я пока не нашёл никакую, чтобы сфотографировать. Примем, что такие монеты тоже редкие, поэтому пока что пропускаем число пять.

Следующий пункт – семь углов. Семиугольных монет, – в том числе, с постоянной шириной, – есть немало разновидностей, некоторые очень известные, например, 20 пенсов Великобритании. Какие-то семиугольные монеты есть и у меня. Начнём с половины динара Иордании. Качество фотографий будет похуже, но, думаю, достаточное для того, чтобы составить представление. (Линейка – в миллиметрах.)

(Фото: половина динара, аверс.)

Монета в половину динара Иордании, 1996 год. Семь углов. Постоянная (почти) ширина. На аверсе – король Хуссейн. Отчеканена Королевским монетным двором Великобритании. Возможно, поэтому напоминает 20- и 50-пенсовые монеты. Реверс этой монеты – на следующем фото.

(Фото: половина динара, реверс.)

Семиугольных монет много. Поэтому ещё несколько фото семиугольников. На следующем фото: опять иорданские динары – монеты в половину и четверть динара.

(Фото: половина и четверть динара Иордании, реверсы, 1996 и 1997 гг.)

На следующем фото: монета пять шиллингов Уганды (слева) и монета 50 филсов ОАЭ. Аверсы.

(Фото: 5 шиллингов Уганды и 50 филсов ОАЭ. Аверсы.)

Угандийская монета отчеканена в Канаде, а монета Объединённых Арабских Эмиратов – в Великобритании. Это, опять же, семиугольники постоянной ширины.

Реверсы этих же монет – следующее фото.

(Фото: 5 шиллингов Уганды и 50 филсов ОАЭ. Реверсы.)

Чуть более классический вариант – монета 20 пенсов Великобритании и монета 20 пенсов острова Мэн (справа).

(Фото: двадцатипенсовые монеты. Аверсы.)

Реверсы тех же монет – ниже.

На реверсе 20-пенсовика 1982 года слева – Роза Тюдоров. Это классический вариант реверса монет этого достоинства. Собственно, именно в таком варианте данная монета и появилась в 1982 году.

Реверс 20-пенсовика справа – содержит изображение сельскохозяйственной техники, – зерноуборочного комбайна, – и надпись ellan vannin над комбайном. “ellan vannin” – это название острова Мэн на мэнском языке (Manx). Точнее – самоназвание.

Обе эти монеты, понятно, отчеканены Королевским монетным двором Великобритании.

За числом семь у нас следует число девять. Но монет на девять углов тоже не нашлось. Поэтому придётся пропустить. Зато нашёлся канадский доллар, у которого 11 углов и занимательная птица. Число 11 – это следующее после 9 возможное количество сторон. Ну, в нашем нечётном случае.

(Фото: доллар Канады. Аверс.)

Королева Елизавета II на аверсе. И птица – на реверсе.

(Фото: доллар Канады. Реверс с гагарой.)

Эта птица – гагара чёрноклювая (Gavia immer). Из-за гагары эта монета известна в англоязычной среде как Loonie (не потому, что “умалишённый”, который loony, а от названия птицы: common loon). Гагара появилась на реверсе долларовой монеты как результат занятной истории с курьерами: сначала на монете планировали изобразить индейскую лодку-каноэ, но заготовленные штемпели с лодкой в 1986 году потеряли на пути из Оттавы в Виннипег, где находится монетный двор. Пришлось достаточно оперативно искать замену, и заменой стал рисунок гагары, плывущей, вместо лодки, по водной глади. Ну, как минимум, таково официальное объяснение.

Следующее нечётное число, больше одиннадцати, это тринадцать. Тринадцать углов в правильном многоугольнике, составляющем монету небольшого диаметра, это уже достаточно, чтобы монета стала почти что неотличима от круглой. Из “монетарных” 13-угольников мне, тем не менее, удалось найти чешскую монету 20 крон 2015 года – она на фото ниже.

(Фото: 20 крон Чехии. Реверс.)

На реверсе этой монеты изображён памятник святому Вацлаву (Svatý Václav).

(Фото: 20 крон Чехии. Аверс.)

Фотография аверса монеты с чешским геральдическим львом завершает данный обзор: монет с большим количеством углов не нашлось. Естественно, можно считать, что все прочие круглые монеты – они “не совсем круглые”, а просто у них “очень много углов”. Но это уже рассуждение из другой области, ближе к неформальному названию канадской долларовой монеты, потому что так можно договориться и до фракталов. Тем не менее, фотографией совсем свежего канадского доллара, без гагары, тоже поделюсь.

Это 2026 год, памятная монета, отчеканенная к какому-то важному футбольному чемпионату.

Кстати, эта странная история с t.me только очередной раз подчёркивает всю “виртуальность доменной географии”: многие думают, что, мол, домен – это строгая система, а имя – идентифицирует узел (вот и в обсуждениях про t.me такая же история: типа, “попробуйте запомнить IP”); в реальности же – это просто идентификатор в чужой базе данных, над которым нет никакого контроля у администратора: администратор лишь получает некоторую временную, иллюзорную возможность управления. Нельзя про это забывать. Особенно, если речь про некий “центральный мессенджер”, к сожалению.

Домен t.me, похоже, разделегирован. Этот домен широко используется в инфраструктуре вокруг Telegram, в качестве носителя “коротких ссылок”.

(Update, 14/07/2026: делегирование вернули, спустя, примерно, 16 часов.)

Ковёр из Байё (или гобелен – как больше нравится, потому что ковры тоже на стену вешают) – недавно доставили в Великобританию из Франции. Знаменитый ковёр будет выставляться в Лондоне, в Британском музее (первая партия билетов уже распродана).

Ковёр представляет собой летопись нормандского завоевания Англии, и эта летопись изложена в оригинальных картинках, начиная с подготовки экспедиции и заканчивая описанием битвы при Гастингсе – всего около 70 метров иллюстрированной ленты исторических событий. Техника изображения тоже редкая: аппликация с “контурной” вышивкой.

Скорее всего, ковёр изготовили в Англии, более девяти столетий назад, – то есть, это была другая Англия, не современная, – а потом достаточно быстро перевезли во Францию, где он, в основном, и находился все эти долгие годы.

А теперь ковёр вернулся на землю страны своего происхождения. Считается, что временно. Во Франции многие были против того, чтобы столь уникальный ковёр отправлять к истокам. Тем более, что ковёр прямо посвящён важнейшему для истории Англии событию 1066 года. Потому что – ну, правда, мало ли что может приключиться? Ковёр очень старый, уже ветхий, может испортиться в ходе поездки. Хуже того, ветхость ведь может послужить и основанием для задержки возвращения ковра, потому что в Лондон-то ковёр, вроде, доехал без видимых проблем, но ведь каждая поездка – это большой риск.

На фоне полной деградации веб-поиска в привычных поисковых машинах – тем же Google, к сожалению, очень сложно, если вообще возможно, нынче что-то найти содержательное в вебе, – у ведущих сервисов LLM появилось весьма существенное преимущество: например, я теперь всё чаще использую ChatGPT, если нужно что-то найти в интернетах, то есть, найти ссылки на документы в вебе.

Всё потому, что эта система, по минимально сложным запросам, даёт выдачу сильно лучше, чем Google. Да, ответ генерируется в виде “статьи” на естественном языке, да, в ответе нередко ерунда написана, но “слова-то правильные”, а поэтому ответ нужно просто использовать как аннотированный список, тем более, что все ссылки можно открыть в отдельной панели (веб-версия) – и это будет та самая содержательная поисковая выдача, со “сниппетами”, которую раньше бы ожидали от Google.

Да, конечно, Google тоже занял большую часть страницы “выдачи” AI/LLM-генератором, и там тоже можно “пооткрывать ссылки” (кликнув на невнятные мелкие кнопки), но тут вопрос качества: субъективно, качество решения в ChatGPT сейчас несравнимо выше, а решаемая задача – та же.

Есть, впрочем, и существенная трудность: в ChatGPT очень долго готовится выдача. Так что, скорее всего, этим всё и объясняется – Google тоже хочет показывать AI, но уж точно не может позволить себе заставлять пользователя ждать две-три минуты.

Что ж, этого следовало ожидать: пишут, что вот и серверные IP-адреса хостинги должны будут раздавать через ЕСИА. Ну, будет очередной повод закрыть остатки сайтов, которые я поддерживаю. Похоже, что и с электронной почтой будет трудновато. Часть сайтов, кстати, что были в .RU/.SU, я уже и так закрыл; но dxdt вот пока перенёс на dxdt.blog. Однако, скорее всего, следующим шагом будет обязательное размещение какого-нибудь JS-кода счётчика на веб-страницах и тому подобные штуки. Поэтому, видимо, не долго-то осталось, так или иначе.

Хотя, в принципе, Интернет уже закончился и так.

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

Пусть теперь появился квантовый компьютер, реализующий алгоритм Шора большой разрядности. Этот алогоритм позволяет атаковать асимметричные криптосистемы, в том числе, в TLS. И если TLS-сессия, в рамках которой передавался пароль, была записана, а для получения сессионных ключей не использовался постквантовый алгоритм, то трафик может быть раскрыт при помощи квантового криптоанализа. Пользовательский пароль, который передавался в TLS-сессии, тоже окажется раскрыт. Естественно, всё то же самое применимо и к неквантовому криптоанализу TLS: например, если сессионные ключи утекли ещё как-то или просто оказались нестойкими, то прочитать пароль можно точно так же. Но тут речь именно про квантовый компьютер, а об эффектах классического взлома – будут оговорки ниже.

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

Другое дело – аутентификация/авторизация “по ключам”, то есть, если у пользователя какой-нибудь доступ “без пароля”, на основе электронной подписи (RSA или ECDSA), но при этом на стороне сервера сохраняется открытый ключ, как он есть (не отпечаток, полученный через хеш-функцию), то квантовый компьютер позволит раскрыть пользовательский секрет уже по значению открытого ключа из БД сервера. Даже не нужно записывать TLS-трафик. Хранение на сервере непосредственно открытых ключей – является вполне себе типовым методом.

Неожиданно, но выглядит так, что, при прочих равных, пароль защищён от квантовых атак получше: для его утечки ещё нужно предварительно записать трафик. А поскольку квантовых компьютеров ещё нет, то трафик нужно где-то хранить, в надежде, что пароль расшифруется позже, и не будет заменён до момента расшифрования. Другое дело, что классический взлом того же TLS может быть осуществлён и без всякого квантового компьютера. В таком случае – пароль, передаваемый в рамках сессии, будет так же прочитан. А вот секретный ключ, при аутентификации по ключам, – таким способом не вычислить: нужно взламывать уже криптосистему цифровой подписи. С одной стороны, это существенное преимущество – получается, что система “по ключам” гораздо лучше защищена от классических атак на протоколы передачи трафика. А такие атаки, в отличие от квантовых компьютеров, уже давно являются строго практическими. С другой стороны – если успешной оказалась атака на криптосистему подписи, то тут уже никакая защита трафика не помогает: ни классическая, ни постквантовая.

Естественно, есть много других “если”. Например, можно использовать пароль, но не передавать его на сервер. Можно испльзовать пароль, но заменять его каждый раз после успешного использования (или даже по счётчику с секретом – см. про одноразовые пароли). Можно использовать пароль, но в дополнение к криптосистеме цифровой подписи. Можно использовать постквантовую криптосистему подписи в дополнение к классической. Так что тут многое зависит от выбранной модели угроз.

Добавил на страницу с избранными записками ещё пять:

• Исторический экскурс: комплексные числа и трактат Бомбелли
• Комплексные числа и квадратный корень из минус единицы
• Греческие монеты и диглоссия
• TLS-сертификаты как токены доступа
• Куда исчез шиллинг: флорины, пенсы и некоторые другие монеты Великобритании

Таким образом, раздел “Избранное” добрался до 2026 года: я туда ссылки выкладываю периодически и, обычно, с заметной задержкой – нужно же накопить записки, чтобы среди них выбирать. Сейчас на странице избранных – ссылки на 338 записок, выходивших в разные годы. Это чуть меньше 10% от записок на сайте. Первая в списке – записка про роллероны, 2006 год, двадцать лет назад: “роллерон – элементарный по устройству и поэтому сверхэффективный активный стабилизатор вращения вокруг продольной оси (по крену)”. Там довольно подробно, с картинками – почитайте, если не видели.

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

Прежде всего, несколько базовых моментов. Естественно, на каких-то веб-ресурсах, типа “личный сайт”, можно использовать банальный механизм – тот или иной готовый ACME-клиент, который исполняется хоть бы прямо и на той же виртуальной машине, где и сам веб-сервер. Но для мало-мальски серьёзного сервиса – такое, конечно, является неграмотным решением и недопустимо: нельзя держать вместе с веб-сервером некоторое непонятное внешнее ПО, которое, потенциально, имеет права суперпользователя и может работать с серверными секретными ключами и сертификатами (насчёт ограничений прав пользователя: тут, конечно, нельзя забывать, что в большинстве современных ОС, – в том числе, серверных, – от “обычного” пользователя до суперпользователя – дорога весьма коротка и часто пряма; впрочем, это другая тема).

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

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

Несколько важных тезисов.

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

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

Валидация права управления именем (DCV), в защищённом распределённом сервере, должна происходить строго через DNS. Поэтому мы спроектируем отдельный набор “микросервисов”, реализующих такую проверку. Прохождение DCV в ACME требует специального префикса (или “суффикса”, тут как посмотреть): _acme-challenge. Это сделано специально, поскольку позволяет вынести проверку на отдельные DNS-серверы, которые не поддерживают основную зону. Размещение DNS-записей для DCV не требует передачи ACME-клиенту каких-то ключей доступа к авторитативным серверам DNS-зоны (далее они обозначаются – NS). Мы будем использовать самый верный вариант настройки DNS – делегирование ACME-имени _acme-challenge на отдельные NS (можно размещать запись непосредственно на NS основной зоны, можно настроить и CNAME, но этот последний вариант – не рекомендуется использовать). Никакая разумная конфигурация DNS для ACME-DCV не требует передачи ACME-клиенту контроля над зоной или каких-то ключей управления, всегда можно сделать безопасную схему.

Итак, архитектурное решение для реализации выпуска и использования TLS-сертификатов при помощи ACME-автоматизации. Решение состоит из трёх основных элементов: подсистема DNS – для обеспечения DCV; основной сервис TLS – это основные узлы сервиса, куда подключаются пользователи, можно считать, что за ними стоят защищаемые веб-серверы; диспетчер ACME – для взаимодействия с внешним УЦ, заказа и получения сертификатов.

Сама схема – ниже (по клику – в большем разрешении).

В качестве примера тут зона example.com. ACME-имя _acme-challenge.example.com – делегируется на два специализированных DNS-сервера, которые предназначены для публикации кодов подтверждения в TXT-записях. Данные на эти выделенные серверы передаёт специальный сервис, роль которого состоит в получении свежих данных DCV от диспетчера ACME и в передаче этих данных на публикацию. Почему изолированы NS? Потому что они не должны иметь доступ к основной зоне. При этом, в общем случае, перехват управления этими NS-ами позволяет заказывать и выпускать сертификаты через другой ACME-аккаунт, но только в том случае, если УЦ не поддерживает указания ACME-аккаунта в CAA-записи. Дело в том, что наши специализированные NS для DCV просто не позволяют публиковать CAA-записи (тем более – в зоне уровнем выше). Поэтому применяется CAA из основной зоны, а там, предположим, указан идентификатор аккаунта, которому только разрешено заказывать сертификаты для этого имени.

Блок сервисов, связанный непосредственно с TLS (слева вверху на схеме). Обратите внимание, что здесь все операции, использующие серверный секретный ключ “от сертификата”, вынесены на специальный подписывающий сервер. Речь про секретный ключ, соответствующий открытому ключу в сертификате сервера. Вообще, при установлении TLS-соединения сам этот долговременный секретный серверный ключ не требуется, требуется возможность подписывания сессии (значения хеш-функции). Понятно, что для вычисления подписи секретный ключ нужен, но само его значение никакой роли в TLS-соединении не имеет. А цифровая подпись, при установлении TLS-соединения, требуется всего один раз. (Тут речь строго про современную схему TLS 1.3, где использование RSA для передачи сессионного секрета прямо запрещено, и такой секрет должен вычисляться по протоколу Диффи-Хелмана.)

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

Блок TLS на схеме содержит “микросервис” под названием “Формирователь CSR”. CSR – это файл запроса на сертификат. Этот файл, помимо других параметров, содержит открытый ключ сервера для включения в сертификат и цифровую подпись от этого же ключа. Именно по причине наличия подписи наш формирователь CSR должен иметь доступ к подписывающему серверу: подготовив блок CSR, формирователь запрашивает подпись у этого сервера и присоединяет значение подписи к блоку CSR. Получившийся файл можно использовать в ACME-клиенте для запроса сертификата (после прохождения DCV – см. ниже). Обратите ещё раз внимание: секретного ключа “от сертификата” тут нет ни у формирователя CSR, ни у TLS-узлов – что уж говорить про ACME-клиент.

ACME-клиент в этой схеме взаимодействует только с ACME-сервисом УЦ, где, по команде от программы-диспетчера, исполняемой отдельно, запрашивает DCV и сертификаты. Как описано выше – коды подтверждения передаются через диспетчер на публикацию в контур DNS. При штатной работе, после того, как TXT-записи опубликованы, ACME-клиент запросит проверку на стороне УЦ и DNS-резолвер УЦ обратится к DNS, чтобы получить по независимому каналу значение кода DCV из TXT-записи – это соответствует оранжевой стрелке внизу схемы.

Посмотрим ещё раз на шаги алгоритма выпуска TLS-сертификата, при штатной работе.

***

1.

Диспетчер (см. схему) получает CSR с актуальными данными от формирователя CSR (подпись от защищённого сервера, с актуальным ключом, в CSR – нужное DNS-имя).

2.

Диспетчер отправляет в ACME-клиент запрос на DCV (CSR на этом шаге в ACME не требуется, но будет нужен позже).

2.1. ACME-клиент инициирует взаимодействие с УЦ через ACME-аккаунт (возможно, используя отдельное хранилище ключа от ACME-аккаунта – см. схему; зачем это может быть нужно – возможно, распишу в отдельной записке; главное – не забывайте, что ACME-аккаунт существует, там есть секретный ключ и он тоже важен).
2.2. ACME-клиент запрашивает прохождение DCV (проверка права управления DNS-именем) на стороне УЦ и получает код подтверждения, который требуется разместить в DNS.
2.3. ACME-клиент передаёт этот код подтверждения (DCV-код) диспетчеру, оджидает публикации кода в TXT-записи.

3.

Диспетчер формирует файлы данных с актуальным кодом подтверждения (DCV-код) и ожидает публикации (у диспетчера нет прямого доступа к сервису подготовки TXT-записей, напротив – тот сервис периодически сам проверяет статус диспетчера, определяет, не нужно ли разместить новые записи).

4.

Сервис подготовки TXT-записей забирает текущий код DCV из обменной области диспетчера.

5.

Сервис подготовки TXT-записей направляет команду публикации TXT-записей авториативным серверам специализированной зоны _acme-challenge и получает подтверждение публикации.

6.

Если публикация TXT прошла успешно, сервис подготовки TXT-записей направлет подтверждение диспетчеру.

7.

Диспетчер отправляет команду фактического запуска DCV ACME-клиенту и ожидает получения сертификата (если проверка пройдёт успешно).

8.

ACME-клиент запрашивает фактическую проверку DCV у УЦ (через ACME-API) и начинает периодический опрос статуса заказа на стороне УЦ (ожидание выпуска сертификата – это свойство ACME).

9.

Если DCV завершилась корректно и успешно, то ACME-клиент получает от диспетчера CSR и запрашивает новый сертификат для подтверждённого имени (или для нескольких имён). Обратите внимание: обычно, у ACME УЦ есть некоторый период, в течение которого действует пройденная DCV. Это означает, что запросить новый сертификат можно без DCV, если срок валидности прошлой успешной проверки для этих же имён не закончился. В описании и на схеме этот момент не учитывается – он не имеет принципиального значения.

10.

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

11.

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

12.

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

13.

Переход на новый сертификат завершился.

***

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