SoftEther ServerCertSet: a megújított lánc importálása vpncmd-vel

A Certbot sikeres megújítást jelent, a lemezen lévő fájlok új dátumokat hordoznak, az ügyfelek mégis a régi identitással találkoznak. A SoftEther az SSL-kiszolgálótanúsítványát a saját, kiszolgálószintű konfigurációjában tartja, ezért egy új fájl a lemezen semmit sem változtat, amíg a levél és a kulcsa be nem kerül. Az alábbi sorrend egy kézi importot, egy minden megújítás után futó burkolót és egy ellenőrzést mutat be, amely azt olvassa ki, amit a figyelő valóban bemutat. Minden lépés bizonyítékot hagy, amelyet a következő megújítás után össze tud hasonlítani.

A megújított fájl nem változtatja meg a kiszolgáló identitását

A kibocsátás és a telepítés külön események, külön hiba módokkal. Az ACME-ügyfél fájlokat ír egy leszármazási könyvtárba, és sikert rögzít; a SoftEther továbbra is azt a tanúsítványt használja, amelyet legutóbb betöltöttek a konfigurációjába. A nulla kilépési állapot tehát a fájlokat írja le, nem a szolgáltatást, és a kettő addig térhet el egymástól, amíg senki sem nézi. Tekintse az importot a telepítési lépésnek, a megújítást pedig annak bemenetének.

Ez a megkülönböztetés magyarázza a zavaró félhibát is: a régi tanúsítvány a lejáratáig működik, ezért eleinte semmi sem tűnik töröttnek. Amikor viszont lejár, minden ügyfél egyszerre hibázik, ami kimaradt telepítési lépés helyett kiesésnek látszik. A bemutatott identitás ellenőrzése minden megújítás után rutinfelügyeletté alakítja ezt a meglepetést.

Válassza azt a kihívást, amelyik illik a figyelőhöz

A tanúsítványnak azt a gazdagépet kell megneveznie, amelyet az ügyfelek ellenőriznek, ezért a nyilvános DNS-nevet használja belső címke vagy cím helyett. A HTTP-01 megköveteli, hogy a kihívásra egy pillanatig a 80-as porton válaszoljanak, ami ideiglenes figyelő, és soha nem ok arra, hogy a SoftEther saját portját áthelyezze. A DNS-01 rekordon keresztül bizonyítja az irányítást, és egyáltalán nem igényel bejövő HTTP-t.

A felügyelet nélküli megújítás automatizált DNS-integrációt jelent az egy zónára korlátozott hitelesítő adatokkal, nem pedig kézzel gépelt TXT-rekordot minden második hónapban. A helyettesítő karakter a kihívás típusát változtatja meg, nem az automatizálás szükségességét. Ezt még az első tanúsítvány létezése előtt döntse el, mert a kihívás típusának későbbi váltása az ügyfél konfigurációjának és a tűzfalnak az együttes megérintését jelenti.

Tartsa rendben az összetevőket, amíg itt van. A levél és a köztes tanúsítványok külön fájlokként és egyetlen egyesített láncfájlként érkeznek, a privát kulcs ismét külön van, és az importhoz a láncra van szükség a hozzá illő kulccsal, nem pedig egy nyilvános tanúsítványra önmagában.

Importálja a láncot kiszolgálószinten

Készítsen biztonsági másolatot a kiszolgáló konfigurációjáról, és erősítse meg, hogy még eléri a felügyeleti felületet, mielőtt a tanúsítványhoz nyúl. Kiszolgálói rendszergazdaként csatlakozzon, ne Virtual Hub-rendszergazdaként, mert a tanúsítvány a kiszolgálóobjektumhoz tartozik. Ezután töltse be a láncot és a kulcsot abszolút útvonalon, olyan fájlokból, amelyeket a parancsot futtató fiók olvashat. Vegye figyelembe, hogy az útvonalak abszolútak, mert a parancs a vpncmd-t futtató folyamat munkakönyvtárából oldja fel őket:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

Olvassa el a parancs kimenetét ahelyett, hogy sikert feltételezne, majd olvassa vissza a láncot ahelyett, hogy megbízna az átadott fájlban. A teljes PEM-csomagot importáló buildek és a csak az első tanúsítványt felvevő buildek közötti határ nincs egy helyen dokumentálva, ezért az ellenőrzés dönti el az Ön előtt álló build esetében. Számolja meg a figyelő által bemutatott tanúsítványokat; a köztesek nélküli levél annak az importálónak az aláírása, amely csak az első blokkot használta fel.

Az importált kulcsot csak a kiszolgálót futtató fiók számára tegye olvashatóvá, és a felügyeleti jelszót tartsa a shell-előzményeken kívül. Ennél az első importnál írja be a jelszót a parancssorba ahelyett, hogy parancsargumentumként adná át. Ez a két szokás semmibe sem kerül, és eltávolítja a leggyakoribb módját annak, hogy egy tanúsítványtelepítés kiszivárogtasson valamit, amit védenie kellett volna. Ezt az első import előtt tegye, ne utána.

A telepítést akassza be, ne a megújítást

Amikor a kézi import működik, tegye pontosan ezeket a lépéseket egy kis burkolóba, és hívja meg az ACME-ügyfélből egy sikeres megújítás után. A Certbot beállítja a RENEWED_LINEAGE és RENEWED_DOMAINS változót a hook számára, így a burkoló egyetlen tanúsítványon tud működni egy olyan gépen, amely többet kezel. A leszármazás szerint szűrjön ahelyett, hogy a gazdagép minden megújítására reagálna. A burkoló telepítési kód, amely a kiszolgáló jogosultságaival fut, ezért úgy vizsgálja át, mint bármely más szkriptet ebben a helyzetben.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

A felügyelet nélkül futó hooknak saját védett hitelesítőtára és emberhez eljutó hiba jelzésre van szüksége. Ha a kibocsátás sikerül és az import meghiúsul, próbálja újra az importot ahelyett, hogy másik tanúsítványt kérne, mert a második kérés egy friss fájl mögé rejti a telepítési hibát. A Certbot megújítási dokumentációja egyértelműen kimondja, hogy a semmit nem frissítő futás normális eredmény, ezért a hook az, ami megkülönbözteti a kettőt.

Hasonlítsa össze a bemutatott láncot a fájllal

A figyelőt olvassa, ne a lemezt. Csatlakozzon az ügyfelek felé néző portra azzal a kiszolgálónévvel, amelyet az ügyfelek használnak, majd hasonlítsa össze az ujjlenyomatot és a szállított láncot a hook által telepített leszármazással. Két parancs lefedi, és az első azt is megmutatja, hogy egyáltalán megérkeznek-e a köztesek:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

Ezután hozzon létre új ügyfélkapcsolatot, mert az import előtt létrehozott munkamenetek a korábbi identitás ellen hitelesítődtek, és semmit sem bizonyítanak az újról. Ha az ügyfelek a régi levelet rögzítik, koordinált frissítésre van szükségük akkor is, amikor a nyilvános lánc érvényes, és ez a feladat ugyanabba a runbookba tartozik, mint a megújítás. A szolgáltatás előtti fordított proxy jó tanúsítványt mutathat, miközben a VPN-figyelő még a régit tartja, ezért az ellenőrzésnek meg kell neveznie azt a portot, amelyet az ügyfelek ténylegesen elérnek. Jegyezze fel az ujjlenyomatot a megújítás dátuma mellé, hogy a következő összehasonlítás ellenőrzés legyen, ne emlékezeti művelet.