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