Gdy Let’s Encrypt dzia\u0142a za reverse proxy, certyfikaty zwykle przestaj\u0105 si\u0119 wystawia\u0107 z jednego nudnego powodu: \u017c\u0105danie walidacyjne trafia teraz na proxy, a nie na serwer \u017ar\u00f3d\u0142owy. S\u0105 trzy rozwi\u0105zania. Przekaza\u0107 \u015bcie\u017ck\u0119 wyzwania ACME do serwera \u017ar\u00f3d\u0142owego, przenie\u015b\u0107 certyfikat na proxy albo przej\u015b\u0107 na walidacj\u0119 DNS-01.<\/p>\n\n\n\n
Historia prawie zawsze wygl\u0105da tak samo. Odnawianie przez miesi\u0105ce dzia\u0142a\u0142o bez zarzutu. Potem kto\u015b skierowa\u0142 rekord A domeny na proxy i nast\u0119pna pr\u00f3ba si\u0119 wy\u0142o\u017cy\u0142a. Poni\u017cej znajdziesz, jak namierzy\u0107 przyczyn\u0119, gdzie certyfikat powinien w\u0142a\u015bciwie by\u0107, jak skonfigurowa\u0107 NGINX pod \u015bcie\u017ck\u0119 wyzwania oraz DNS-01 (spos\u00f3b, kt\u00f3ry dzia\u0142a tak samo, niezale\u017cnie od tego, czy przed stron\u0105 stoi proxy).<\/p>\n\n\n\n
Bo walidacja HTTP-01 pobiera plik z adresu IP, na kt\u00f3ry rozwi\u0105zuje si\u0119 domena. A ten adres nale\u017cy teraz do proxy. Token zapisany przez serwer \u017ar\u00f3d\u0142owy nigdy wi\u0119c nie zostaje zwr\u00f3cony. Dokumentacja typ\u00f3w wyzwa\u0144 Let’s Encrypt<\/a> opisuje mechanizm: klient ACME zapisuje plik z tokenem pod Log klienta powie ci, z kt\u00f3rym wariantem masz do czynienia. B\u0142\u0105d 404 albo \u201eunauthorized\u201d. Przekierowanie na HTTPS, kt\u00f3rego proxy nie potrafi obs\u0142u\u017cy\u0107. Albo zwyk\u0142y timeout. Jeszcze jedno: nieudana walidacja oznacza start od nowa z nowym zam\u00f3wieniem, wi\u0119c najpierw napraw \u015bcie\u017ck\u0119, a dopiero potem pon\u00f3w pr\u00f3b\u0119, nie odwrotnie.<\/p>\n\n\n\n Miejsce, w kt\u00f3rym ko\u0144czy si\u0119 TLS, decyduje o tym, gdzie jest certyfikat i kt\u00f3re wyzwanie ma sens. Zostawiasz certyfikat na serwerze \u017ar\u00f3d\u0142owym: proxy tylko przepuszcza ruch, serwer \u017ar\u00f3d\u0142owy zachowuje swojego klienta ACME, a \u015bcie\u017cka wyzwania musi do niego dociera\u0107. Przenosisz go na proxy: ten, kto obs\u0142uguje tam TLS, obs\u0142uguje te\u017c klienta ACME. Serwer \u017ar\u00f3d\u0142owy nie wystawia wtedy publicznie niczego do walidacji.<\/p>\n\n\n\n Wyb\u00f3r nale\u017cy do ciebie. Zanim si\u0119 zdecydujesz, zapytaj operatora proxy, jak obs\u0142uguje TLS i \u015bcie\u017ck\u0119 Na serwerze \u017ar\u00f3d\u0142owym udost\u0119pnij Test jest prosty. Wrzu\u0107 plik do DNS-01 potwierdza kontrol\u0119 nad domen\u0105 rekordem TXT pod Na propagacji ludzie najcz\u0119\u015bciej si\u0119 przeje\u017cd\u017caj\u0105. Klient powinien poczeka\u0107, a\u017c rekord b\u0119dzie widoczny wsz\u0119dzie, zanim uruchomi walidacj\u0119. Zgodnie z sekcj\u0105 DNS-01 w dokumentacji<\/a>, je\u015bli dostawca nie daje sposobu na sprawdzenie propagacji, czasem trzeba czeka\u0107 nawet godzin\u0119. Aha, i usuwaj stare rekordy TXT, bo Let’s Encrypt odrzuca zbyt du\u017c\u0105 odpowied\u017a.<\/p>\n\n\n\n Zr\u00f3b pr\u00f3bne odnowienie i sprawd\u017a \u015bcie\u017ck\u0119 wyzwania albo rekord TXT spoza swojej sieci, du\u017co wcze\u015bniej, ni\u017c certyfikat zbli\u017cy si\u0119 do ko\u0144ca wa\u017cno\u015bci. Ka\u017cdy wystawiony certyfikat trafia do publicznych log\u00f3w, wi\u0119c twoje nazwy host\u00f3w zostawiaj\u0105 \u015blady w logach Certificate Transparency<\/a>, kt\u00f3rym warto si\u0119 czasem przyjrze\u0107. Dopiero planujesz warstw\u0119 proxy? Por\u00f3wnaj plany reverse proxy Jalvo<\/a> i rozwa\u017c wsp\u00f3\u0142dzielone i dedykowane adresy IP<\/a> dla adres\u00f3w stoj\u0105cych przed twoim serwerem \u017ar\u00f3d\u0142owym.<\/p>\n\n\n\nhttp:\/\/<domain>\/.well-known\/acme-challenge\/<TOKEN><\/code>, a Let’s Encrypt go pobiera, czasem kilka razy i z kilku lokalizacji. Co\u015b mi\u0119dzy publiczn\u0105 nazw\u0105 hosta a tym plikiem zachowuje si\u0119 inaczej? Walidacja si\u0119 sypie.<\/p>\n\n\n\nNajpierw zdecyduj: certyfikat na serwerze \u017ar\u00f3d\u0142owym czy na proxy?<\/h2>\n\n\n\n
\n
\/.well-known<\/code> (zdziwi\u0142by\u015b si\u0119, jak cz\u0119sto nikt o to nie pyta). A je\u015bli nadal nie masz pewno\u015bci, czy proxy w og\u00f3le powinno sta\u0107 przed stron\u0105, najpierw rozwa\u017c argumenty za reverse proxy<\/a>.<\/p>\n\n\n\nKierowanie \u015bcie\u017cki wyzwania ACME w NGINX dla HTTP-01<\/h2>\n\n\n\n
\/.well-known\/acme-challenge\/<\/code> przez zwyk\u0142e HTTP i umie\u015b\u0107 t\u0119 regu\u0142\u0119 przed jakimkolwiek przekierowaniem na HTTPS. Wtedy \u017c\u0105danie przekazane przez proxy faktycznie znajdzie token. Na w\u0142asnym serwerze \u017ar\u00f3d\u0142owym:<\/p>\n\n\n\n\n
certbot certonly --webroot -w \/var\/www\/acme -d example.com<\/code>.<\/li>\nnginx -t<\/code> i prze\u0142aduj NGINX.<\/li>\n<\/ol>\n\n\n\nserver {\n listen 80;\n server_name example.com;\n\n location ^~ \/.well-known\/acme-challenge\/ {\n root \/var\/www\/acme;\n default_type text\/plain;\n }\n\n location \/ {\n return 301 https:\/\/$host$request_uri;\n }\n}<\/code><\/pre>\n\/var\/www\/acme\/.well-known\/acme-challenge\/<\/code>, pobierz go przez publiczn\u0105 nazw\u0119 hosta z innej sieci i sprawd\u017a, czy access log serwera \u017ar\u00f3d\u0142owego odnotowa\u0142 \u017c\u0105danie. Haczyk: to dzia\u0142a tylko wtedy, gdy proxy przekazuje zwyk\u0142e \u017c\u0105dania HTTP dla tej \u015bcie\u017cki bez zmian. Sprawd\u017a wi\u0119c tak\u017ce stron\u0119 proxy.<\/p>\n\n\n\nWyzwanie DNS-01: walidacja, kt\u00f3rej proxy nie przeszkadza<\/h2>\n\n\n\n
_acme-challenge.<domain><\/code>, wi\u0119c routing HTTP przez proxy przestaje mie\u0107 znaczenie. Czy konfiguracja jest trudniejsza ni\u017c przy HTTP-01? Tak. Ale obs\u0142uguje przypadki, z kt\u00f3rymi HTTP-01 sobie nie radzi, i pozwala wystawia\u0107 certyfikaty wildcard. Potrzebujesz dostawcy DNS z API albo delegujesz _acme-challenge<\/code> przez CNAME lub NS do strefy, kt\u00f3ra szybko si\u0119 aktualizuje.<\/p>\n\n\n\nCo sprawdzi\u0107 przed nast\u0119pnym odnowieniem<\/h2>\n\n\n\n
certbot renew --dry-run<\/code> przechodzi ca\u0142y proces na \u015brodowisku testowym i nie rusza dzia\u0142aj\u0105cego certyfikatu.<\/p>\n\n\n\n\n
--deploy-hook \"systemctl reload nginx\"<\/code>.<\/li>\nJak wybra\u0107 konfiguracj\u0119 Let’s Encrypt za reverse proxy, kt\u00f3ra nie przestanie si\u0119 odnawia\u0107<\/h2>\n\n\n\n