Hogyan biztosíthatjuk az ingyenes Let's Encrypt SSL-el az ISPConfig3 kezelőpanelünket és a főbb szolgáltatásainkat

botond küldte be 2018. 12. 15., szo - 23:02 időpontban

Tartalom

 

Bevezető

Ebben a leírásban felhasználjuk a Let's Encrypt által kiállított SSL tanúsítványunkat, hogy biztosítsuk a szerveren lévő ISPConfig kezelőpanelünket, valamint a Postfix, Dovecot és PureFTPd szolgáltatásokat. Továbbá elkészítjük ezekre is az automatikus megújítást elvégző szkriptünket.

 

A leírás végrehajtásához szükség van néhány korábbi telepítés elvégzésére is, mert ezekre épülnek, én is ezeken hajtottam végre:

 

 

Szerver weboldal létrehozása

Ha még eddig nem került volna rá sor, létre kell hozni a szerver elsődleges weboldalát, tehát azt a weboldalt, aminek a domain neve megegyezik a telepítéskor megadott FQDN névvel. Ennek a weboldalnak elérhetőnek kell lennie az internetről, és megfelelően beállított DNS zónával kell rendelkeznie, ugyanis erre kell kikérni a Let's Encrypt SSL tanúsítványt az itt leírtaknak megfelelően. Ebben a leírásban ezt a tanúsítványt fogjuk felhasználni a szerver többi részének a levédésére.

Ha mindez megvan, kikértük a tanúsítványt és a weboldal is elérhető HTTPS-en keresztül, akkor léphetünk is tovább a következő fejezetre.

 

SSL engedélyezése az ISPConfig számára

Akik az ISPConfig telepítése során engedélyezték az SSL használatát a kezelőpanel számára, azok ezt a fejezetet át is ugorhatják.

Ha viszont az ISPConfig telepítése során nem engedélyeztük volna az SSL-t a kezelőpanel számára (pl. az alapértelmezett 8080-as porton), akkor ezt utólag is megtehetjük, ha a terminálban rootként futtatjuk az ISPConfig3 frissítő parancsát:

ispconfig_update.sh

Ekkor elindul az ISPConfig frissítő scriptje, amit már ismerhetünk a korábbi frissítések során. Itt haladjunk végig a megszokott módon, majd az SSL résznél, a "Create a new ISPConfig SSL certificate (yes/no)"  kérdésnél válaszoljuk yes-el, és akkor felteszi a (self-signed) tanúsítvány készítéséhez a szükséges kérdéseket, ahol nyomjunk enter-eket, mivel nincs szükségünk pontos tanúsítványra.

Minderre azért van szükség, hogy az ISPConfig generáljon magának egy tanúsítványt, és SSL módban működjön, amit majd felül írunk a Let's Encrypttől kapott hiteles tanúsítvánnyal.

Ezután ellenőrizzük, hogy bejön-e az ISPConfig https-el is a 8080-as porton (amennyiben nem állítottunk be egyedi portot). Itt kapunk néhány figyelmeztetést a böngészőtől (mivel nem hiteles a tanúsítványunk, mert magunk állítottuk elő), a Chrome például nem is nagyon enged tovább, de a másik böngészőkkel figyelmen kívül hagyva ezeket, el kell hogy induljon a kezelőpanel.

 

ISPConfig SSL tanúsítványának felülírása

Idáig tehát meg kell lennie az alábbiaknak:

  • működő szerver weboldal (bármilyen tartalommal, csak elérhető legyen)
  • erre a weboldalra be kellett kapcsolnunk a Let's Encrypt tanúsítványt
  • és az ISPConfignak működnie kell a HTTPS protokollon az (alapértelmezett 8080-as, vagy az általunk beállított)  porton (a szerver weboldalon keresztül elérve).

Ha minden rendben van, akkor most felülírjuk az ISPConfig saját tanúsítványát a szerver weboldalhoz kiállítottal.

 

Az ISPConfig is ugyanazon a domainen fut, mint a weboldal, amin keresztül elérjük, és amire kikértük a Let's Encrypt tanúsítványt is. Így felmerülhet a kérdés, hogy akkor miért van erre szükség. Nos, a válasz egyszerű: az ISPConfig egy külön Virtualhoston működik, ahol külön van beállítva minden konfiguráció, köztük a tanúsítvány fájljainak elérési útvonalai is. Ezért ezeket felül kell írni a megfelelő fájlokkal.

 

Ehhez a művelethez hajtsuk végre az alábbi parancssorokat (magyarázat a kódsorok alatt):

cd /usr/local/ispconfig/interface/ssl/
mv ispserver.crt ispserver.crt-$(date +"%y%m%d%H%M%S").bak
mv ispserver.key ispserver.key-$(date +"%y%m%d%H%M%S").bak
mv ispserver.pem ispserver.pem-$(date +"%y%m%d%H%M%S").bak
ln -s /etc/letsencrypt/live/$(hostname -f)/fullchain.pem ispserver.crt
ln -s /etc/letsencrypt/live/$(hostname -f)/privkey.pem ispserver.key
cat ispserver.{key,crt} > ispserver.pem
chmod 600 ispserver.pem

Itt annyi történik, hogy a 2-4 sorban átnevezzük az ISPConfig tanúsítványának fájljait, időbélyeggel elnevezett backupot készítünk belőlük.

A .pem fájl átnevezését csak akkor végezzük, ha korábban már készítettünk ispserver.pem fájlt. Ellenkező esetben hagyjuk ki.

Ezután a Let's Encrypt live könyvtárából átlinkeljük a weboldalon már működő hitelesített tanúsítványunk fájljait az ISPConfig fájljai helyére. Majd elkészítjük a .pem fájlt is, amit az előző két fájl (crt és key) összefűzésével kapunk. Ennek később lesz jelentősége a többi szolgáltatásnál.

Az utolsó sorban pedig leszedjük a pem fájlról a csoport és a többiek jogosultságait.

 

 

SSL kiterjesztése a többi webszolgáltatásra

Ebben a fejezetben az ISPConfig-ra kiterjesztett SSL tanúsítvány fájljait fogjuk tovább linkelni az adott webszolgáltatáshoz. Bölcsebb megoldás, mintha a különböző szolgáltatások konfigurációiban állítgatnánk át az útvonalakat direktben a fenti fájlokra.

Postfix

A postfix SSL "beláncolásához" adjuk ki az alábbi parancsokat (továbbra is root-ként):

cd /etc/postfix/
mv smtpd.cert smtpd.cert-$(date +"%y%m%d%H%M%S").bak
mv smtpd.key smtpd.key-$(date +"%y%m%d%H%M%S").bak
ln -s /usr/local/ispconfig/interface/ssl/ispserver.crt smtpd.cert
ln -s /usr/local/ispconfig/interface/ssl/ispserver.key smtpd.key
service postfix restart

Itt is hasonló történik, mint feljebb: A második és harmadik sorban biztonsági másolatot készítünk a szerver feltelepítésekor létrehozott (szintén self signed) tanúsítványokról, majd a következő két sorban pedig a backup-olt fájlok helyére symlinkeket helyezünk el, amik az ISPConfig3 kezelőpanelünk fentebb elkészített linkjeire mutatnak.

Végül újraindítjuk a postfix daemonját.

Dovecot

A Dovecot esetében, ha mindent úgy telepítettünk fel az elején, ahogyan a korábbi szerver leírásban, akkor a Dovecot már eleve a postfix SSL fájljait használja. De azért ellenőrizzük:

nano /etc/dovecot/dovecot.conf

Amiben így kell kinéznie a két SSL-es sornak:

[...]
ssl_cert = </etc/postfix/smtpd.cert
ssl_key = </etc/postfix/smtpd.key
[...]

Ha mégsem így nézne ki ez a két sor, akkor írjuk át erre, hogy bekerüljön a Dovecot is az SSL láncolásba.

Ezután indítsuk újra a dovecot-ot is:

service dovecot restart

Courier

Ha valaki netán a Dovecot helyett a Courier-t telepítette fel a szerverre, akkor ebben az esetben az alábbi parancsokat kell végrehajtania:

cd /etc/courier/
mv imapd.pem imapd.pem-$(date +"%y%m%d%H%M%S").bak
mv pop3d.pem pop3d.pem-$(date +"%y%m%d%H%M%S").bak
ln -s /usr/local/ispconfig/interface/ssl/ispserver.pem imapd.pem
ln -s /usr/local/ispconfig/interface/ssl/ispserver.pem pop3d.pem
service courier-imap-ssl stop
service courier-imap-ssl start
service courier-pop-ssl stop
service courier-pop-ssl start

PureFTPd

A PureFTPd-hez pedig az alábbi parancsok kellenek:

cd /etc/ssl/private/
mv pure-ftpd.pem pure-ftpd.pem-$(date +"%y%m%d%H%M%S").bak
ln -s /usr/local/ispconfig/interface/ssl/ispserver.pem pure-ftpd.pem
chmod 600 pure-ftpd.pem
service pure-ftpd-mysql restart

Monit

Ha pedig a Monit szerver statisztika is telepítésre került az elején, akkor ehhez pedig nyissuk meg a konfig fájlját:

nano /etc/monit/monitrc

És adjuk hozzá a pem fájlt, amit korábban átlinkeltünk (mondjuk a PureFTPd-hez készített megteszi):

[...]
set httpd port 2812 and
SSL ENABLE
PEMFILE /etc/ssl/private/pure-ftpd.pem
allow admin:'secretpassword'
[...]

Majd indítsuk újra:

service monit restart

 

 

Auto megújítást elvégző script elkészítése az ISPConfig pem fájlja számára

Az ISPConfig3 nem újítja meg automatikusan a saját tanúsítványát, amivel magát a kezelőfelületet védjük le, és így az erre láncolt szolgáltatások tanúsítványai sem frissülnek. Ezért erről nekünk kell gondoskodnunk, hacsak nem szeretnénk rendszeresen figyelgetni a weboldalunkhoz kiállított Let's Encrypt SSL automatikusan megújított fájljait.

Ehhez a művelethez az incron eseményfigyelő daemon-t fogjuk használni, ami lefuttatja helyettünk a scriptünket, amikor változás áll be a fájlrendszer megfigyelt részeiben. Ez esetben amikor a Let's Encrypt ACME kliense, a Certbot megújítja nekünk a szerver elsődleges weboldalához használt SSL tanúsítványt. Ezzel levéve a terhet a vállunkról, mert nem kell többé figyelgetni hogy mikor frissülnek a .key és a .crt fájlok.

Ehhez először telepítsük az incron-t az apt-get paranccsal:

apt-get install -y incron

Ezután hozzunk létre egy indítófájlt a /etc/init.d könyvtárban:

nano /etc/init.d/le_ispc_pem.sh

És tegyük bele az alábbi tartalmat:

#!/bin/sh
### BEGIN INIT INFO
# Provides: LE ISPSERVER.PEM AUTO UPDATER
# Required-Start: $local_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: LE ISPSERVER.PEM AUTO UPDATER
# Description: Update ispserver.pem automatically after ISPC LE SSL certs are renewed.
### END INIT INFO
cd /usr/local/ispconfig/interface/ssl/
mv ispserver.pem ispserver.pem-$(date +"%y%m%d%H%M%S").bak
cat ispserver.{key,crt} > ispserver.pem
chmod 600 ispserver.pem
chmod 600 /etc/ssl/private/pure-ftpd.pem
service pure-ftpd-mysql restart
service monit restart
service postfix restart
service dovecot restart
service apache2 restart

Ha nincs feltelepítve a Monit, akkor a végén hagyjuk ki annak az újraindítását tartalmazó sort.

Valamint ha Apache helyett Nginx a webkiszolgálónk, akkor értelemszerűen cseréljük az apache újraindításos sort nginx újraindításra.

Mentsük le az indítófájlt, majd tegyük futtathatóvá:

chmod +x /etc/init.d/le_ispc_pem.sh

Ezután adjuk hozzá a root felhasználót az incron jogosult felhasználói közé (mert enélkül a root sem használhatja):

echo "root" >> /etc/incron.allow

Majd az incrontab paranccsal szerkesszük az incrontab-ot:

incrontab -e

 

Ekkor megnyílik az alapértelmezett szerkesztőnk (például a nano), és benne egy átmeneti fájl, amit az incrontab parancs fog majd a helyére tenni mentéskor, tehát direktben nem szerkeszthetjük.

 

Tegyük bele az alábbi sort:

/etc/letsencrypt/archive/$(hostname -f)/ IN_MODIFY ./etc/init.d/le_ispc_pem.sh

 

Fontos!

Mielőtt lementjük, győződjünk meg róla, hogy a /etc/letsencrypt/archive/$(hostname -f)/ alkönyvtár létezik-e!

Ugyanis például nálam a hostname parancs csak a hosztnevet adja, a hostname -f pedig a teljes szervernevet a domain névvel együtt, tehát egy ehhez hasonlót: szerver1.pelda.hu. Ezzel szemben a Let's Encrypt archive könyvárában pedig csak a domain nevekkel szerepelnek az SSL-t használó weboldalak könyvtárnevei, így az elsődleges weboldal alkönyvtára is. Tehát nálam a hostname parancs-os megoldás nem működne, és gondolom másoknál is lehet hasonló szituáció.

Mindez függhet attól, hogy a legelején a minimális szerver telepítése során a hálózat résznél a gépnevet és a tartománynevet hogyan adtuk meg.

Az eredeti leírást pontosan követve az abban szereplő incrontab sort tüntettem fel az imént, mindazonáltal azt javaslom, hogy keressük meg a /etc/letsencrypt/archive könyvtár alatt található szerver domain névvel szereplő alkönyvtárat és azt használjuk a $(hostname -f) rész helyett, amennyiben a fenti módszerrel nem érhető el az alkönyvtár.

Ha itt nem a megfelelő alkönyvtárat állítjuk be, akkor a scriptünk lehet hogy sosem fog lefutni, ha a hibásan megadott könyvtár tartalma nem változik.

 

Ha mindezzel megvagyunk, mentsük le, majd indítsuk újra az Apache-t:

service apache2 restart

Nginx esetén természetesen azt.

 

Igazából itt most csak a .pem fájl miatt kellett ezt a "macerát letudnunk", mert a .pem fájlt a .key és a .crt fájlok összefűzéséből nyerjük, így tehát amelyik fenti szolgáltatásnál nem volt szükség a .pem fájlra, azoknál az átlinkelés következtében hozzájutnának a friss .key és .crt fájlokhoz. (pl postfix és Dovecot) Viszont a többinél mindegyiknél szükség van a .pem fájlra is, amit pedig csak scripttel tudunk létrehozni, amikor megkapjuk a friss fájlokat.

 

Konklúzió

Ezzel az átláncolási módszerrel tehát elértük, hogy az ISPConfig3 kezelőpanelünk és a különböző szerver szolgáltatásaink is folyamatosan részesülnek az automatikusan megújuló Let's Encrypt SSL-jéből.

Arra kell még figyelni, hogy ha kívülről használjuk ezeket a szolgáltatásokat (FTP, IMAP, stb), akkor mindig a szerver fő domain nevét adjuk meg hosztnévnek ezekben a szolgáltatásokban, mivel erre a domain névre lett kiállítva az SSL tanúsítvány. Így például ha a szerveren működő weboldalak FTP, IMAP, stb hozzáféréseinél nem a szerver fő domain nevét adjuk meg, hanem az adott weboldalét, akkor a csatlakozó kliensprogram SSL hibát fog jelezni, mivel nem azzal a domain névvel történt a csatlakozás, mint amire a tanúsítvány ki lett állítva.

Mindezt csak azért írom le, mert ha például ügyfeleknek adunk ki tárhelyeket, akkor jelezni kell ezt nekik is, hogy melyik domain névvel tudnak hiba nélkül SSL-en keresztül csatlakozni ezekhez a protokollokhoz.

 

 

Hozzászólások

1.

A linkek nem működtek, mivel a letsencrypt mappában nem FQDN formában vannak a nevek, hanem simán csak a domainok alapján (a hostname jó, tehát FQDN, a LAMP server telepítés során követve a másik leírást eleve úgy adtam meg).

Így nem linkkel, hanem manuálisan a file-okba másolva sikerült megoldani. Így persze nem a legjobb megoldás.

ln -s /etc/letsencrypt/live/$(hostname -f)/fullchain.pem ispserver.crt
ln -s /etc/letsencrypt/live/$(hostname -f)/privkey.pem ispserver.key

 

De működik, tehát az IP helyett a fő doomain-t megadva az ISPConfig-nál, FTP-nél, Roundcube-nál már böngésző figyelmeztetés nélkül jól megy https.

 

2.

Sajnos ezek ellenére sem működik az SSL/TLS a levelezőben. Azaz sikerült a beállítás, mégis, ha egy levelezőkliensben akarom használni, csak START TLS módon veszi be.

És ami ennél is rosszabb, hogy minden levél, amit egy gmail címre küldök ott a SPAM mappába kerül.

Kipróbáltam Freemailos címre is, oda meg egyáltalán nem érkezett meg.

Rengeteg leírást megnéztem már a témában, de semmi se segített.

Ezt kezdem most megnézni, de brutál hosszú és kissé nem világos:

http://www.postfix.org/TLS_README.html

 

Van valami jó leírás erről kezdőknek?

 

 

 

- De miért nem SSL/TLS? A Thunderbird csak kivétellel fogadja el a tanúsítványt?

 

- Az igaz, hogy nem mindegyik gmail fiókban kerül a SPAM-ba, de ez így bizonytalan és gáz, ha nem kapják meg egyesek a leveleket pl. egy CMS-ből.

Saját gmail, tehát feketelistázásról szó sem lehet.

 

- És ott van még a frissen létrehozott freemail fiók, amit tesztelés miatt csináltam és oda meg sem érkezik a levél.

- Most csináltam egy outlook.hu-s email címet is, oda is a SPAM-ba megy.

Freemail-be továbbra sem érkezik meg.

 

- Amúgy meg nagyon lassú, percekkel később megy csak el, bár az lehet azért, mert mindössze 1 CPU van a VPS serveren és 1 GB RAM.

A fekete listázást nem a fogadó felére értettem, hanem hogy a weboldal domainjére, ahonnan kiküldöd a levelet, hogy esetleg az van feketelistázva. Ilyen előfordulhat például, ha egy korábban használt domain nevet sikerült kifogni, ami fekete listázva volt, vagy esetleg feltörték az SMTP szervert, és spammerek sok levelet küldtek ki az oldalról, és ezért kerülhetett fekete listára.

Nálam több domain névvel működnek weboldalak ezen a szerveren, amit ennek megfelelően állítottam be, és még nem volt egyetlen egyszer sem gondom vele. Ezért tippelek ilyesmikre.
A Thunderbird-ben valóban el kell fogadni a tanúsítványt, ez nálam is így van, amikor a Let's Encrypt kiállítja az új SSL-t, de ettől függetlenül működik nálam szépen minden, szintén Start TLS módban.