kell nekem LetsEncrypt

 ( tselmeci | 2018. augusztus 23., csütörtök - 8:36 )

Szevasztok!

(előrebocsátom, hogy nem vagyok jártas a titkosítások terén)

Van egy kis szerverem, amin a következő fontosabb szolgáltatások futnak: SMTP, IMAP4, HTTP, FTP, mindez saját domain alatt.

Amikor SMTP-vel levelet küldök, akkor a levél minden esetben a szolgáltatóm smarthostja felé van továbbítva TLS kapcsolaton keresztül. Minden más esetben az összes szolgáltatás (SMTP auth levelezőprogramból, IMAP4 auth, HTTP, FTP) titkosítás nélkül megy. Tudom, nem jó.

Titkosítást akarok bevezetni, elsősorban az SMTP-re és IMAP4-re. FTP-re, HTTP-re csak bónuszként.

Van némi (segéd)fogalmam arról, hogyan kell csinálni, de azért inkább kérdeznék:
-1) ha self-signed cert-et használok, akkor vajon egyes SMTP MTA-k (pl. Google) vissza fogják utasítani a titkosítás használatát az én SMTP-m felé való küldés során?
-1.1) self-signed cert esetén a levelezőprogram panaszkodhat az SMTP-mhez csatlakozáskor, hogy self-signed a cert, de ez mondjuk engem nem érdekel... vagy kellene?;
-1.2) SMTP-hez hasonló lehet a helyzet IMAP4 kliensnél is, hogy panaszkodhat, igaz?
-2) ha van már a gépen az ssh-hoz amúgy is DSS és RSA kulcs (dropbear), akkor azokat fel lehet használni a self-signed cert elkészítéséhez?

Szívem szerint self-signed certet használnék, de ha van rá kis esély is, hogy emiatt egyes MTA-k nem lesznek hajlandóak TLS-t használni az SMTP-m felé, akkor elmozdulnék pl. LetsEncrypt irányba.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

(sub)

Állj át NethServerre, vagy legalább pár szolgáltatást passzolj át rá.
Kapásból tud LetsEncryptet és frissíti is. Én más eszközökre is azonos WAN oldali IP/URL alatt a NethServerről másolom át cron scripttel a certet és működik. Stunnel és Mikrotik is megeszi, amit a NethServer használ (crt és key állomány).

Eszembe sem jutna self-signed certet használni, ha egyszer használhatok publikusan elfogadottat. Ha azon túllépünk, hogy biztonságosabb-e egy domain-validált tanúsítvány egy self-signed tanúsítványnál (nagyon sokkal nem) akkor még mindig ott van, hogy a self-signed cert használata a klienseknek (konfigurálási és használati szempontból) totális szopás, és akkor még nem zártad ki azt, hogy túloldal nem fogja elfogadni.

Ha a környezeted valamiért nem teszi lehetővé / nagyon megnehezíti a Let's Encrypt implementálását, akkor vegyél egy másik CA-tól egy éves domain-validált tanúsítványt kb. 10 dollárért. (COMODO, stb.) - évente egyszer kézzel/scripttel kicseréled a tanúsítványfájlt, és kész.

Kicsit fura nekem ez az egész Letsencrypt. Az acme-client-tel próbáltam szerezni cert-et, de nem sikerült. Valószínűleg elbénáztam valamit, de még nincs feladva. Ami a furcsa, hogy a Letsencrypttől cert kéréshez nem kért be tőlem az acme-client semmi olyat, hogy nevem, domain név stb. A Letsencrypt oldalon nem találtam olyat, hogy regisztráció stb. de akkor hogyan generálnak pont az én domainemhez certet?!

A letsencrypt-nek az kell, hogy az adott domain alatt, amihez kéred a cert-et, a 80-as és 443-as portról csekkolva el tudjon érni egy általa küldött módosítási kérést.

Kösz, megpróbálok utánanézni, h az én webszerverem jó-e ehhez.

Nem muszáj hozzá webszerver. Én pl. dnsapival authentikálok és utána kérem le a kulcsokat egy gépen (azon nincs is webszerver), és onnét terítem szét vagy tíz másik helyre. Szóval kb. bárhol lehet futtatni.

Ki tudnál segíteni egy kiindulási URL-lel? :)

https://www.google.com/search?q=acme.sh+dnsapi&ie=utf-8&oe=utf-8&client=firefox-b-ab
Nekem az első találat: https://github.com/Neilpang/acme.sh/tree/master/dnsapi
Itt szépen fel vannak sorolva a különböző szolgáltatókhoz tartozó megoldások. Mind úgy működik, hogy felvesz egy TXT rekordot a zónába, és ezzel hitelesíti magát (téged, a scriptet, ésatöbbi).
Tulajdonképpen csak az a kérdés, hogy a dyndns szolgáltatód benne van-e a listában, vagy ha nincs, akkor milyen protokollt támogat.

DotRollnál van a domain, és egyelőre nem látom, hogy adnának API-t, amivel szkriptből tetszőleges TXT rekordot tudok felvenni. Utánakérdezek. Amúgy meg a manuális DNS mód maradna, de ahhoz 30 naponként kézzel új TXT-t kéne felvenni, ami meg nyilván nem játszik.

A DNS API-s megoldás az én esetemben nem túl jó. Az acme-client tud http-s authentikációt, ráteszem az acme-clientet a szerverre, megadom neki a webszerver könyvtárát és elvileg működnie kell.

Mi az az acme-client? Van egy rakat, acme protokollt beszélő kliens, én most épp az acme.sh-t szeretem.

Alapvetően úgy működik mind, hogy megmondod a kliensnek, hogy mely domain-re kell a cert, és a kliens valamilyen módszerrel - webroot, dnsapi, valami - beazonosítja magát, és szerencsés esetben hipp-hopp felkonfigurálja a szervert is.

Az acme-client egy kliens, amit a Letsencrypt támogat:

https://letsencrypt.org/docs/client-options/

A default a Certbot, de az nem fut az én szerveremen, mert az egy egyedi beágyazott linuxot futtat és arra nincsen dnf, rpm, yum, apt stb. Az acme-client meg egy C program, ami azt állítja magáról, tudja, amit tudnia kell, ráadásul könnyen fordítható a rendszeremre. Ezért próbálkozom vele. Illetve még a C++-os kliens is érdekes lehet.

Áh, addig sose tekertem el, szóval ez az: https://kristaps.bsd.lv/acme-client/

1) többi smtp elfogadja általában a self-signed cert-et
1.1/1.2) levelező programok panaszkodni fognak (SMTP, IMAP), ha csak te használod akkor nem kell vele foglalkozni
2) ssh public key és SSL tanusítvány teljesen másra valók, csak az elméleti háttér azonos

Ajánlom a LetsEncryptet, mert percek alatt beállítható és utána cron job-ból automatikusan frissíti magát!

--
Professional IT Services - Informatikai tanácsadás és outsourcing
www.professional-it-services.hu

1.1/1.2) mivel jelenleg csak én használom, engem a legkevésbé sem zavar, ha panaszkodik a self-signed certre levelező. A lényeg, hogy titkosítva szaladálnak a csomagok;
2) igen, belátom ;)

Egyelőre a LetsEncrypt mellett vagyok.