Давайте шифруємо перевірку certbot через HTTPS

З документів плагіна Webroot Certbot

Плагін Webroot працює, створюючи тимчасовий файл для кожного із запитуваних доменів у ${webroot-path}/.well-known/acme-challenge. Тоді сервер перевірки Let's Encrypt робить запити HTTP для підтвердження того, що DNS для кожного запитуваного домену вирішується на сервері, на якому працює certbot.

На приватному домашньому сервері у мене порт 80 відключений, тобто в маршрутизаторі не включено переадресацію портів. Я не маю наміру відкривати цей порт.

Як я можу сказати certbot, що сервер перевірки не повинен робити HTTP-запит, а HTTPS (порт 443) для підтвердження права власності на домен?

Сервер перевірки навіть не повинен мати необхідність перевіряти сертифікат домашнього сервера, оскільки він вже використовує HTTP за замовчуванням. У мене може бути сертифікат самопідписання або сертифікат, який готується до поновлення, але це не має значення.

В даний час я перебуваю в ситуації, коли мені потрібно включити переадресацію порту 80, а також сервер на ньому для створення / оновлення сертифікатів. Це не дозволяє мені використовувати cronjob для відновлення сертифіката. Ну, з достатньою кількістю роботи, але я вже маю прослуховування сервера на 443, який також міг би виконати цю роботу.

ssl lets-encrypt

— Даніель Ф
джерело

Як повідомили в https://community.letsencrypt.org/t/shouldnt-verification-via-dns-record-be-a-priority/604/47 в letsencrypt.sh програми оновлення перевірки опор через DNS. Мабуть, мало сценаріїв оновлення цього було реалізовано. Однак метод HTTP є найпростішим у застосуванні для початкової конфігурації.

Сценарій, який ви маєте, може використовувати TNS SNI або підтвердження наявності попереднього ключа для оновлення. Специфікацію можна знайти за посиланням https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.5 . У такому випадку вам не потрібно буде включати HTTP.

— BillThor
джерело

Дякую, я забув про перевірку на основі DNS. Бути порівняно важко знайти будь-яку інформацію про нього, оскільки документи ледве згадують її. Немає гачка для Namecheap, тому я спробую реалізувати його зараз і перевірити, як він працює. Я прийму відповідь, якщо вона працює, як очікувалося, але це може зайняти деякий час, оскільки наразі немає доменів для оновлення. Інакше мені доведеться запекти команду --webroot на сервері, щоб сервер виступав як обгортка, яку можна підключити.

— Даніель Ф

Щойно перевірено, API Namecheap досить поганий (перезаписати ВСІ записи, щоб додати або змінити його), DNS в цьому випадку не є варіантом. Я також використовую інші реєстратори, що робить це складніше (управління ключами API). API API Namecheap надає вам навіть доступ до реєстрації нових доменів або доменів передачі, це небезпечно як FK.

— Даніель Ф

@DanielF Я очікую, що ні DNS, ні HTTP перевірка не використовуватимуться для оновлення. Це також не потрібно, оскільки ваші сервери повинні передавати TLS SNI для існуючого сертифіката, і запит можна підписати наявним сертифікатом. Або повинно вистачити. DNS та HTTP - це розумні методи для реєстрації. У вас має бути 30 днів для розробки проблем, коли ваш перший сертифікат готовий до поновлення.

— BillThor