Čas vytvorenia Lets Encrypt certifikátu neodpovedá času spustenia cron-u

[kvas]

Ahoj vsimol som si, ze casy vytvorenia certifikatov Lets Encrypt na serveri neodpovedaju casu, kedy sa spusta cron job pre certbot.

certbot spustam o 2:35 v pondelok rano ako root :

Kód: [Vybrat]

35 2 * * 1 /usr/bin/certbot renew
ale subory certifikatov v (/etc/letsencrypt/live/DOMENA) a dokonca ani historicke kluce a CSRs (/etc/letsencrypt/keys a /etc/letsencrypt/csr) nie su vytvorene v case 2:35hod ale v inom case, aktualne to je 21:43.

viete mi to niekto vysvetlit? na severi som jediny user a aj jediny root, certifikaty pouziva len apache na ubuntu 20.04.

[Reklama]

[Filip Jirsák]

Ten posun z x:35 na x:43 bude daný tím, že vystavení certifikátu nějakou dobu trvá. V x:35 vznikne požadavek na vytvoření certifikátu, od LE se získají ověřovací řetězce, ty se musí publikovat (na webovém serveru nebo DNS), pak je nutné říct LE, že je může ověřit, LE je ověří, pak si klient ověří, že je vše připravené a požádá o vystavení certifikátu. Navíc ověření i vystavení certifikátu je ze strany LE asynchronní – klient o to požádá, ale LE si jen požadavek zařadí do fronty a zpracuje jej „později“ (což je obvykle během pár sekund, ale chvilku to trvá).

Rozdíl v hodinách bych přičítal různým časovým zónám. Jakou časovou zónu mají ty časy z certifikátů a jakou časovou zónu máte nastavenou na serveru (případně pro cron, ale nepředpokládám, že by se lišila od serverové)?

[kvas]

To sa mi zda krajne nepravdepodobne, pretoze:
1) ked som 1-krat nasadzoval SSL certifikat na roznych serveroch, tak to bolo v priebehu par sekund od CSR az po obdrzanie certifikatu a jeho nasadenie na server
2) rovnako aj vsetky CRS (000X_csr-certbot.pem) a tiez aj kluce (000X_key-certbot.pem) maju casy ine (rozne hodiny aj minuty - nie rovnake medzi sebou) ako je cas spustenia cron jobu a minimalne CSR (ak tomu spravne rozumiem, tak) sa vytvori u mna na serveri posle sa na lets encrypt ako ziadost na novy certifikat pri spusteni bot-a.

cas servera je centralna europa so zonami to ale urcite nesuvisi, pretoze to by museli mat vsetky CSR a aj kluce vzdy rovnaku hodinu vytvorenia, ale tu nemaju, je to vzdy ina/odlisna hodina a aj minuty (HH:MM)

[kvas]

2) rovnako aj vsetky CRS (000X_csr-certbot.pem) a tiez aj kluce (000X_key-certbot.pem) maju casy ine (rozne hodiny aj minuty - nie rovnake medzi sebou...

tie casy v minutach su aj mensie ako hodnota 35, nie su len vacsie - napr. 8:27, 12:18, 17:24, 12:53

[Filip Jirsák]

Nevím, v jakém okamžiku přesně certbot vytváří CSR – nejlogičtější by bylo vytvářet je až po ověření vlastnictví doménového jména, takže je tam potřeba čas na ověření. Nejlepší by bylo podívat se na logy certbota, případně zapnout logování, pokud zapnuté není. Jinak těch příčin může být spousta a je potřeba to nejdřív zúžit alespoň na krok, ve kterém ke zdržení dochází.

Mimochodem, ty časy, které uvádíte, jsou časy vzniku souboru, nebo „neplatné před“ z certifikátu? To by také bylo zajímavé porovnat.

[Reklama]

[Ondrej Nemecek]

Není tam nějaká random prodleva, která má předejít přetížení v celou hodinu např.?

[Death Walker]

Hmmm, cron...

Nemate nahodou povolenu automaticku obnovu certifikatov?

Co vypise

Kód: [Vybrat]

systemctl list-timers

[Death Walker]

Ubuntu ma tusim pre ten timer nastavene

Kód: [Vybrat]

OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200Co by odpovedalo vasemu problemu.
(RandomizedDelaySec sa pouziva aby sa nespustali vsetky timery naraz, koli zatazi systemu)

[Death Walker]

btw, ak sme lokalizovali suradnice kde je pes zakopny tak

Kód: [Vybrat]

systemctl edit certbot.timer Urcite neprepisujte priamo /lib/systemd/system/certbot.timer, update by vam to zase vratilo do default.

[kvas]

Hmmm, cron...

Nemate nahodou povolenu automaticku obnovu certifikatov?

Co vypise

Kód: [Vybrat]

systemctl list-timers

okrem dalsich timerov tam mam aj toto:

Kód: [Vybrat]

Tue 2022-03-08 22:26:28 CET 12h left      Tue 2022-03-08 01:35:13 CET 8h ago        certbot.timer                certbot.service

toto si zije vlastnycm zivotom, nezavisle do cron-u? Nebudem do toho zasahovat, nemam dovod, len mi prisli divne tie casy vytvorenia certifikatov, preto som otvoril tuto temu.

preco je ten certbot.service medzi timermi? predpokladam, ze sa tam pridal pri instalacii. ale koli comu? ja som zil v tom, ze certifikaty managuje len ten moj cron job. co presne robi tento certbot.service?

EDIT: tak uz som to nasiel: "Run certbot twice daily" - to je pre mna novinka. Niewklko tutorialov o nastaveni certbotu pre obnovu certifikatov som presiel, ale ani jeden nespomynal tento service. Vzdy to len koncilo nastavenim "certbot renew" v crone a hotovo.

Kazdopadne, dakujem za pomoc, detaily si uz niekde dohladam.

[Death Walker]

No, cron je uz viacmenej retro ako init.d

Systemd vam umozni priblizit predpoklad ze ste jediny spravca svojho systemu blizsie realite. Ked tak https://www.root.cz/clanky/sandboxing-se-systemd-zesileni-ochrany-sluzeb-pomoci-namespaces/ a google poskutne dalsie info.

[Filip Jirsák]

Kód: [Vybrat]

Tue 2022-03-08 22:26:28 CET 12h left      Tue 2022-03-08 01:35:13 CET 8h ago        certbot.timer                certbot.service

toto si zije vlastnycm zivotom, nezavisle do cron-u?

Ano, je to systemd timer. Timery mají podobný účel, jako cron, ale je to integrované do systemd a umí to s ním lépe spolupracovat.

preco je ten certbot.service medzi timermi?

Je to certbot.timer, který spouští certbot.service. Takhle se to dělá v systemd – máte službu (service), která se spouští jednorázově, tj. spustí se, něco zpracuje a pak se ukončí. A ta služba se sama od sebe nespustí nikdy – ale vytvoří se k ní timer, který říká, kdy se ta služba má spustit.

predpokladam, ze sa tam pridal pri instalacii. ale koli comu?

Proto, aby se certbot pravidelně spustil a obnovil certifikáty, pokud je to potřeba. Když máte certbot nainstalovaný z distribuce, je integrován do systému. A v systému, kde je systemd, je správné pravidelné spouštění plánovta pomocí timer jednotek, nebo pomocí cronu.

Niewklko tutorialov o nastaveni certbotu pre obnovu certifikatov som presiel, ale ani jeden nespomynal tento service. Vzdy to len koncilo nastavenim "certbot renew" v crone a hotovo.

Protože ty tutorialy to popisují tak, že si vše uděláte ručně. Vy jste ale použil distribuční instalaci, která to ruční nastavení nepotřebuje, protože je to přednastavené už od správce distribučního balíčku.

[Death Walker]

Trocha to upresnim:

Takhle se to dělá v systemd – máte službu (service), která se spouští jednorázově, tj. spustí se, něco zpracuje a pak se ukončí. A ta služba se sama od sebe nespustí nikdy – ale vytvoří se k ní timer, který říká, kdy se ta služba má spustit.

Za predpokladu ze je sluzba v stave enabled, tak sa pusti pri starte systemu.

Kód: [Vybrat]

systemctl enabled httpd.service # spustenie pri boote povolene
systemctl disabled httpd.service # spustenie pri boote zakazane

Za predpokladu ze je sluzba nastavena ako daemon, tak po jej ukonceni bez vyziadania sa moze spustit predefinovany pocet krat. Ak sa unonci aj po predefinovanom pocte pokusov, tak sa zaznamena chyba.

Kód: [Vybrat]

systemctl stop httpd.service # vyziadane zastavenie daemona

Ak je enabled a nie je daemon, tak ide zvycajne o nieco co treba jednorazovo vykonat pri starte systemu. Napr. mount filesystemu pre httpd. Ak ma httpd.service nastavenu zavislost na sluzbe ktora pren ten filesystem namountuje, tak sa spustia postupne a v spravnom poradi.

Ak sa ma sluzba vykonavat periodicky, tak nie je daemon a je disabled. Timer sa spusta peridicky podla nastvenia a vola prislusnu sluzbu.

Niewklko tutorialov o nastaveni certbotu pre obnovu certifikatov som presiel, ale ani jeden nespomynal tento service. Vzdy to len koncilo nastavenim "certbot renew" v crone a hotovo.

No, jak to napisat najeko citlivo. Ak je clovek schopny ovladat toto https://en.wikipedia.org/wiki/Roland_TB-303 tak je s tym schopny urobit vela muziky. Ak je zvyknuty na toto https://cs.wikipedia.org/wiki/Buben a nie je sa ochotny ucit, tak ten TB-303 v jeho rukach funguje vseliako, len nie tak ako ma a na vine je samozrejme TB-303. Systemd ma medzi adminmi mnoho odporcov a vedu sa na tuto temu dlhe flamewar...

[Death Walker]

preco je ten certbot.service medzi timermi? predpokladam, ze sa tam pridal pri instalacii.

Pridal sa tam pri instalacii. Vo vychodzom stave by mal byt disabled, pretoze v journale by bola kopa hlasok ze certbot nema ziadne domeny pre ktore by mohol certifikaty obnovit.

Moze za to --no-autorenew=false. Bud ste ju tam z niekade skopiroval alebo je na ubuntu defaut false. Standartne by malabyt default true. Preto tie odpovede na SO pridavaju rucne zaznam do crontab.

Ak pouzijete certbot v inom mode ako manual a mate --no-autorenew=false tak sa zavola

Kód: [Vybrat]

systemctl enable certbot.timer
(ak ten certbot pouzijete takto s neprivilegovanym uctom, tak zanadava ze na povolenie timeru nema opravnenia alebo rovno bude vyzaovat overenie pre privilegovaneho uzivatela, zalezi na distre)

[kvas]

nastavenia certbot som urcite nemenil, musi to byt v ubuntu takto nastavene ako default.

ja nie som zastanca ani odporca systemd, viem ze existuje, ale vsetky svoje serverove aplikacie spustam pomocou init.d - zrejme prisiel cas nastudovat systemd. Keby by som o nom vedel viac, nemusel by som tu riesit toto vlakno. Ale aspon mam motivaciu a vsetkym zucastnenym dakujem