Давайте зашифруем: почему DNS-вызов статичен?
Насколько я понимаю, проверка LetsEncrypt DNS работает путем установки статической записи TXT в DNS (в основном просто одноразового номера), которая затем проверяется серверами LetsEncrypt.
Когда я впервые услышал об этом, я был очень взволнован и ожидал чего-то более сложного: открытый ключ хранится в DNS моих доменов. Затем для проверки я создаю подписанное сообщение, и сервер LetsEncrypt проверяет правильность подписи. Поскольку открытый ключ в DNS и закрытый ключ у меня есть, это доказывает, что я контролирую домен.
Обнаружение, что это не работает таким образом, было немного разочаровывающим: это требует ручного взаимодействия и даже для обновления новой записи TXT.
Есть ли техническая причина, по которой не используется сигнатурный подход? Если нет, то по какой причине LetsEncrypt не реализует это?
1 ответ
Я считаю, что то, что вы думаете, происходит не то, что на самом деле происходит. Let's Encrypt следует текущей версии проекта протокола ACME рабочей группы IETF ACME. В этом черновике в разделе 8.5 в качестве первого шага при создании значения записи TXT предлагается использовать как случайную строку (предоставленную в задании), так и ключ учетной записи.
Клиент отвечает на этот вызов, создавая ключ авторизации из значения "токен", указанного в запросе, и ключа учетной записи клиента. Затем клиент вычисляет дайджест SHA-256 [FIPS180-4] ключа авторизации.
Владение ключом учетной записи и контроль над DNS должны быть достаточными для подтверждения как контроля над доменом, так и подключения к учетной записи, запрашивающей сертификат. Открытый ключ, связанный с учетной записью, не предоставляется в DNS и хранится в LE, в то время как закрытый ключ должен храниться на самом сервере надежно, как и любой другой закрытый ключ.
Итак, ваши последние вопросы. Есть ли техническая причина, по которой не используется сигнатурный подход? Если нет, то по какой причине LetsEncrypt не реализует это? кажется, упустил суть. Подпись используется.