Üdv!
A tanusítványt hogyan újítjátok meg?
A generálás: ./letsencrypt-auto --apache -d mydomain.ltd
Ezzel lehet megújítani is a tanusítványt?
- 2686 megtekintés
Hozzászólások
A certbot tudja a megújítást, cron-ból is.
- A hozzászóláshoz be kell jelentkezni
Kicsit pontosítva: a renew
subcommanddal.
- A hozzászóláshoz be kell jelentkezni
Arra gondoltam, hogy a manual elolvasása sikerülni fog önerőből is.
- A hozzászóláshoz be kell jelentkezni
Én meg arra gondoltam, hogy biztosra kell menni :)
- A hozzászóláshoz be kell jelentkezni
Ha jól látom nálam 0.22 verzió van, remélem ugyanarról beszélünk (márciusban töltöttem le). :)
Szóval nálam nincs letsencrypt script/bináris, csak a "letsencrypt-auto" - a renew opció nem használható.
(OS: CentOS 6.9)
Ez kellene?
https://certbot.eff.org/lets-encrypt/centos6-apache
update:
Igen, a link ok. Működik! Köszönöm!!
certbot-auto renew
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Gondoltam nem nyitok új topic-ot, inkább ide láncolom be. Most kaptam (RackForest-től), érdekes lehet. 2.6%-nyi tanúsítvány érintett, de ez is több mint 3millió darab.
A Let's Encrypt 2020 Március 4-én várhatóan 0:00 UTC, magyar idő szerint éjjel 1:00 órától több kiadott SSL tanusítványt vissza fog vonni egy CAA ellenőrzési hiba miatt, mely lehetséges hogy érintheti az Ön szolgáltatásait is. Amennyiben Ön nem használ Let's Encrypt SSL tanusítványokat nincsen további teendője, ellenkező esetben viszont kérjük hogy ellenőrizze hogy az Ön SSL tanusítványa érintett-e a visszavonásban, és amennyiben érintett, sürgősen újítsa meg. További információk az esetről a Let's Encrypt hivatalos oldalán találhatóak:
https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864
A domain neveket és az SSL tanusítványokat az alábbi oldalon is le lehet ellenőrizni:
- A hozzászóláshoz be kell jelentkezni
Ha jól értem, csak azok a tanúsítványok érintettek, ahol
- UCC tanúsítvány (egynél több subjectAltName van benne),
- van CAA rekord a DNS-ben,
- a domain validálás és a tanúsítvány tényleges kiadása között több óra (8?) eltelt.
Ezek alapján, én gyanúsan nagynak tartom az érintett tanúsítványok számát. Ha valaki certbotot használ, milyen tényállás miatt telik el több óra a domain validálás és a tanúsítványkiadás között?
- A hozzászóláshoz be kell jelentkezni
Elsőre nekem is sok volt benne a CAA és a dns, aztán beugrott: van egy DNS alapú módja a tanusítvány kiadásnak (certbot helyett), amikor is "valamikor" csekkolják, többször hogy él-e a DNS-ek között a CAA. Szerintem ebben a challenge módban lehet(ett) a hiba, nem a certbot-osban.
https://letsencrypt.org/docs/challenge-types/
Köszi, hogy felhívtad erre a figyelmet!
- A hozzászóláshoz be kell jelentkezni
Én úgy értelmezem, hogy a domain validálás során, és a tanúsítvány kiadása előtt közvetlenül is ellenőrzik a CAA rekordot, és csak akkor adják ki a tanúsítványt, ha a CAA rekord nem tiltja a Let's Encrypt tanúsítványkiadót. Ez független attól, hogy maga a domain tulajdonjog validáció egyébként HTTP vagy DNS alapon történik.
- A hozzászóláshoz be kell jelentkezni
Ilyenkor happy, akinek 144 domaint kell kézzel csekkolni :)
- A hozzászóláshoz be kell jelentkezni
IMHO a Letsencrypt elég korrektül jár el, pl van API. Pár perc alatt lefutott az összes ellenőrzése.
De zip-ben is letölthető az összes érintett cert serial-ja.
- A hozzászóláshoz be kell jelentkezni
De miért kell csekkolni?
"certbot --apache renew --force-renewal"
és kész.
- A hozzászóláshoz be kell jelentkezni
Nálam például manuális DNS megoldás van, mert nem ott fut a `certbot`, ahol a HTTP cluster, nyilván lehetne elosztott fájlrendszer alapokon megoldani ilyesmit, de nincs annyi cert, ami miatt ez megérje időben és karbantartásban.
- A hozzászóláshoz be kell jelentkezni
Miért nincs az apache/nginx conf mellett a certbot(.py)? Szakmailag érdekel, nem troll kérdés.
- A hozzászóláshoz be kell jelentkezni
Van 20 HTTP node, 5 kontinensen, GeoDNS, latency és health check alapú IP feloldással, hova teszed? Szakmailag érdekel.
- A hozzászóláshoz be kell jelentkezni
Ott indítod ahol éppen fut és szétküldöd mindenhová ahol futhat. Ebben mi a drága/nehéz?
- A hozzászóláshoz be kell jelentkezni
Leírnád, hogy ezt hogy gondolod? Vagy én bonyolítanám túl vagy te gondolod túl egyszerűnek.
- A hozzászóláshoz be kell jelentkezni
Nekünk pl a puppetmaster szerveren fut a certbot, oda proxyzza minden edge load balancer a HTTP challenge-t, aztán a puppet szétkürtöli az új certet "minden" szerverre.
- A hozzászóláshoz be kell jelentkezni
Nekünk pl a puppetmaster szerveren fut a certbot, oda proxyzza minden edge load balancer a HTTP challenge-t, aztán a puppet szétkürtöli az új certet "minden" szerverre.
És ez mennyire automatikus?
- A hozzászóláshoz be kell jelentkezni
Ez teljesen, semmi kézimunka nincs vele.
- A hozzászóláshoz be kell jelentkezni
Oké, tehát a certbot-nak hogy van elmagyarázva, hogy a puppet könyvtárába írjon? Hogy van elmagyarázva, hogy 5-15 perc múlva fog kiérni az összes node-ra az új tartalom? Érdekelnek a részletek, mert ezt eddig nem találtam meg egyben.
- A hozzászóláshoz be kell jelentkezni
Van egy (szerver oldalon futó) puppet function ami kb a kövekező módon hívja a certbot-ot:
cmd = "certbot certonly --non-interactive --agree-tos --email #{config['email']} \
--config-dir #{config['letsencryptconfigdir']} \
--logs-dir #{config['letsencryptconfigdir']}/logs \
--work-dir #{config['letsencryptconfigdir']}/tmp \
--standalone --http-01-port 8281 --preferred-challenges http-01 \
--cert-name #{cn} " << config['domains'].map{|domain| "-d " << domain }.join(' ')
Így a `$letsencryptconfigdir` alá kerül minden, amiból aztán tud olvasni a puppet. A node-okra nincs kiküldve semmi; amint a certbot ebből a functionből elindul, a HTTP challenge bejön a domainre, valamelyk edge load balancerre beesik, az átproxyzza ide a puppetmaster :8281 portjára (ahol még mindig fut a certbot) és a certbot már írja is ki a certet. Ez így kb 5 másodperc. Ha a cert már létezik, akkor ez a function nem futtatja a certbotot, a megújítás már simán napi cronjob-ból megy. Igazából ezt a function-t ki is lehet hagyni ha neked elég hogy az új certet egyszer kézzel kikéred, aztán a puppet csak teríti, a cronjob pedig megújítgatja.
Leegyszerűsítve ennyi. Igazából Puppet sem kell, akár ssh-val is lehetne automatikusan teríteni. Az egészben annyi a trükk, hogy a certbot mindig ugyanazon az 1db gépen fusson le és a challenge legyen oda becsatornázva. DNS-nél ez adottság, HTTP-nél pedig proxy-val megoldható.
- A hozzászóláshoz be kell jelentkezni
Aham, na ezt akartam elkerülni, hogy mindig fusson és foglalkoznom kelljen a domain-ek egy bizonyos részének a forward dolgaival.
Igazából ezt a function-t ki is lehet hagyni ha neked elég hogy az új certet egyszer kézzel kikéred, aztán a puppet csak teríti, a cronjob pedig megújítgatja.
Mintha megújításnál is lenne szopás, de megnézem nemsokára.
- A hozzászóláshoz be kell jelentkezni
szinten, de wildcard miatt dns, igy meguszom az extra proxy-t ;)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Én DNS alapú manuális validálást használok, azzal nincs gondom, de ez nem automatikus.
- A hozzászóláshoz be kell jelentkezni
de te választod a manuális részt, nem azért mert nem lehet automatikusan
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Ha a dns szervernek van api-ja akkor mi a probléma az automatizálással?
De ha a tiéd a névszerver és pl bind9 akkor:
- A hozzászóláshoz be kell jelentkezni
Ha van API a DNS szerverhez és persze nincs több szolgáltatónál a DNS, akkor lehet.
- A hozzászóláshoz be kell jelentkezni
A DNS szolgáltatók csak slave-ek legyenek. És csinálj egy hidden master DNS szervert. Azt pedig már tudod updatelni, a slave-ek átveszik axfr-el.
- A hozzászóláshoz be kell jelentkezni
És mondjuk hogyan tudok slave DNS szolgáltatóval GeoDNS IP feloldást meg automatikus failover-t?
- A hozzászóláshoz be kell jelentkezni
Hmm, akkor maradjon az eredeti felállás. Ne legyenek slave-ek a DNS szolgáltatok amiket használsz, akkor megmarad a geoip és a health check alapú LB etc.
Akkor viszont csinálni kell egy CNAME-et az ACME challenge-re és ez a CNAME mutasson az átalad üzemeltett DNS szerver egy TXT rekordjára, ami egy tök másik domainban is lehet és ezt a rekordot updatelgeted.
Magyarul felveszel statikusan a domainjeidbe minden validációra egy
_acme-challenge.www.example.com CNAME www.example.com.validationserver.example.net
rekordot.
Lásd:
https://community.letsencrypt.org/t/renew-using-dns-01-challenge/53498/8
https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-…
- A hozzászóláshoz be kell jelentkezni
Sokan pnaszkodtak, hogy annyi cert van egy gépen, hogy kidobta őket a szerver a volume miatt. Sajna nem mindenhol lehet ez megoldás. De nem is a certbot-os challengre vonatkozott az issue asszem.
- A hozzászóláshoz be kell jelentkezni
Thx ezt nem olvastam. Ez viszont értelmetlen limit (btw mi a "sok"?).
- A hozzászóláshoz be kell jelentkezni
Elég sok relációban vannak limitek: https://letsencrypt.org/docs/rate-limits/
- A hozzászóláshoz be kell jelentkezni
Nekem nem mukodott az ellenorzes. Igy maradtam a ujjitsuk meg az osszeset azert van certbot. Kesz. Foloslegesen pazaroltam idot a miert nem megy az ellenorzes reszre.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
- A hozzászóláshoz be kell jelentkezni
Nalam Traefik van elotte, az intezi maganak TLS-ALPN-01 challenge vagy DNS-01 challenge hasznalataval, ha wildcard.
- A hozzászóláshoz be kell jelentkezni
es amikor kiderul hogy nem, mert csak certificate expire-t figyel, revoke-ot nem, akkor meg meglepodik mindenki :D
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Közben kiderült hogy nem :D
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
ELhalasztották a visszavonás időpontját március 04. 20:00 UTC-ig:
- A hozzászóláshoz be kell jelentkezni