Zaszyfrujmy sprawdzanie poprawności certyfikatów przez HTTPS

16

Z dokumentacji wtyczki webroot Certbot

Wtyczka webroot działa, tworząc plik tymczasowy dla każdej żądanej domeny w ${webroot-path}/.well-known/acme-challenge. Następnie serwer sprawdzania poprawności Let's Encrypt wysyła żądania HTTP w celu sprawdzenia , czy DNS dla każdej żądanej domeny jest rozstrzygany na serwerze z uruchomionym programem certbot.

Na prywatnym serwerze domowym mam wyłączony port 80, co oznacza, że ​​w routerze nie jest włączone przekierowanie portów. Nie mam zamiaru otwierać tego portu.

Jak mogę powiedzieć certbotowi, że serwer sprawdzania poprawności nie powinien wysyłać żądania HTTP, ale żądanie HTTPS (port 443) w celu sprawdzenia własności domeny?

Serwer sprawdzania poprawności nie powinien nawet wymagać sprawdzania poprawności certyfikatu serwera macierzystego, ponieważ domyślnie korzysta już z protokołu HTTP. Mogę mieć certyfikat z podpisem własnym lub certyfikat, który jest gotowy do odnowienia, ale to nie powinno mieć znaczenia.

Obecnie jestem w sytuacji, w której muszę włączyć przekierowanie portu 80 oraz serwer na nim, aby utworzyć / odnowić certyfikaty. Nie pozwala mi to na użycie cronjob do odnowienia certyfikatu. Cóż, przy wystarczającej ilości pracy byłoby to możliwe, ale mam już serwer nasłuchujący na 443, który również mógłby wykonać tę pracę.

Daniel F.
źródło

Odpowiedzi:

8

Jak podano w https://community.letsencrypt.org/t/shouldnt-verification-via-dns-record-be-a-priority/604/47 się letsencrypt.sh updater walidacji podpór poprzez DNS. Wydaje się, że niewiele skryptów aktualizujących to zaimplementowało. Jednak metoda HTTP jest najprostsza do zaimplementowania do początkowej konfiguracji.

Skrypt, który posiadasz, może używać TNS SNI lub Dowodu posiadania klucza wcześniejszego do przedłużenia. Specyfikacja znajduje się na stronie https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.5 . W takim przypadku nie musisz mieć włączonego HTTP.

BillThor
źródło
Dzięki, zapomniałem o weryfikacji opartej na DNS. Znalezienie jakichkolwiek informacji na ten temat było stosunkowo trudne, ponieważ lekarze ledwo o tym wspominają. Namecheap nie ma żadnego haka, więc spróbuję go teraz zaimplementować i sprawdzę, jak to działa. Zaakceptuję odpowiedź, jeśli zadziała zgodnie z oczekiwaniami, ale może to trochę potrwać, ponieważ nie ma obecnie domen do odnowienia. W przeciwnym razie będę musiał upiec polecenie --webroot na serwerze, aby serwer działał jak opakowanie, które można współdzielić.
Daniel F,
Właśnie sprawdzone, interfejs API Namecheap jest całkiem zły (nadpisuje WSZYSTKIE rekordy, aby je dodać lub zmodyfikować), DNS nie jest w tym przypadku opcją. Korzystam również z innych rejestratorów, co komplikuje sprawę (zarządzanie kluczami API). Klucz API Namecheap daje ci nawet dostęp do rejestracji nowych domen lub transferu domen, co nie jest bezpieczne jak FK.
Daniel F
@DanielF Oczekuję, że do odnowienia nie będą używane sprawdzanie poprawności DNS ani HTTP. Nie jest to również konieczne, ponieważ Twoje serwery powinny przekazać TLS SNI dla istniejącego certyfikatu, a żądanie można podpisać za pomocą istniejącego certyfikatu. Oba powinny wystarczyć. DNS i HTTP to rozsądne metody rejestracji. Powinieneś mieć 30 dni na rozwiązanie problemów, gdy pierwszy certyfikat będzie gotowy do odnowienia.
BillThor,