SoftEther ServerCertSet: importă lanțul reînnoit cu vpncmd

Certbot raportează o reînnoire reușită, fișierele de pe disc au date noi, iar clienții întâlnesc în continuare identitatea veche. SoftEther păstrează certificatul SSL al serverului în propria configurație la nivel de server, așa că un fișier nou pe disc nu schimbă nimic până când frunza și cheia ei nu sunt importate. Secvența de mai jos acoperă o importare manuală, un înveliș care rulează după fiecare reînnoire și o verificare care citește ce prezintă de fapt listenerul. Fiecare pas lasă dovezi pe care le puteți compara după următoarea reînnoire.

Un fișier reînnoit nu schimbă identitatea serverului

Emiterea și implementarea sunt evenimente separate, cu moduri de eșec separate. Clientul ACME scrie fișiere într-un director de linie și înregistrează succesul; SoftEther continuă să folosească certificatul încărcat ultima dată în configurația sa. Un cod de ieșire zero descrie deci fișierele, nu serviciul, iar cele două pot fi în dezacord atâta timp cât nimeni nu se uită. Tratați importarea ca pasul de implementare, iar reînnoirea ca intrarea ei.

Această distincție explică și eșecul parțial derutant: certificatul vechi funcționează până la expirare, așa că la început nimic nu pare stricat. Când expiră, toți clienții eșuează deodată, ceea ce arată ca o întrerupere și nu ca un pas de implementare omis. Verificarea identității prezentate după fiecare reînnoire transformă acea surpriză într-o observație de rutină.

Alegeți provocarea potrivită pentru listener

Certificatul trebuie să numească gazda pe care o verifică clienții, așa că folosiți numele DNS public în locul unei etichete interne sau al unei adrese. HTTP-01 cere ca provocarea să primească răspuns pe portul 80 pentru o clipă, ceea ce este un listener temporar și niciodată un motiv pentru a muta portul propriu al SoftEther. DNS-01 dovedește controlul printr-o înregistrare și nu are nevoie deloc de HTTP de intrare.

Reînnoirea nesupravegheată înseamnă o integrare DNS automatizată cu acreditări limitate la o singură zonă, nu o înregistrare TXT tastată manual la fiecare două luni. Un wildcard schimbă tipul provocării, nu nevoia de acea automatizare. Decideți asta înainte de a exista primul certificat, pentru că schimbarea tipului de provocare mai târziu înseamnă să atingeți simultan configurația clientului și firewallul.

Țineți artefactele în ordine cât timp sunteți aici. Frunza și certificatele intermediare vin ca fișiere separate și ca un singur fișier de lanț combinat, cheia privată este din nou separată, iar importarea are nevoie de lanțul cu cheia potrivită, nu de un certificat public singur.

Importați lanțul la nivel de server

Faceți o copie de siguranță a configurației serverului și confirmați că ajungeți încă la interfața de administrare înainte de a atinge certificatul. Conectați-vă ca administrator de server și nu ca administrator de Virtual Hub, pentru că certificatul aparține obiectului server. Apoi încărcați lanțul și cheia pe cale absolută, din fișiere pe care contul care rulează comanda le poate citi. Observați căile sunt absolute pentru că comanda le rezolvă din directorul de lucru al procesului care a rulat vpncmd:

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

Citiți ieșirea comenzii în loc să presupuneți succesul, apoi recitiți lanțul în loc să vă încredeți în fișierul pe care l-ați dat. Granița dintre buildurile care importă un pachet PEM întreg și buildurile care iau doar primul certificat nu este documentată într-un singur loc, așa că verificarea este cea care o decide pentru buildul din fața dumneavoastră. Numărați certificatele pe care le prezintă listenerul; o frunză fără intermediare este semnătura unui importator care a consumat doar primul bloc.

Țineți cheia importată lizibilă doar pentru contul care rulează serverul, și țineți parola de administrare în afara istoricului shell-ului. La această primă importare, tastați parola la prompt în loc să o transmiteți ca argument al comenzii. Aceste două obiceiuri nu costă nimic și elimină cea mai comună cale prin care o implementare de certificate scapă ceva ce trebuia să protejeze. Faceți asta înainte de prima importare, nu după.

Atașați implementarea, nu reînnoirea

Când importarea manuală funcționează, puneți exact acești pași într-un înveliș mic și apelați-l din clientul ACME după o reînnoire reușită. Certbot setează RENEWED_LINEAGE și RENEWED_DOMAINS pentru hook, așa că învelișul poate acționa asupra unui certificat pe o mașină care gestionează mai multe. Filtrați după linie în loc să reacționați la fiecare reînnoire de pe gazdă. Învelișul este cod de implementare care rulează cu privilegiile serverului, așa că revizuiți-l ca orice alt script în acea poziție.

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

Un hook care rulează nesupravegheat are nevoie de propriul depozit protejat de acreditări și de un semnal de eșec care ajunge la o persoană. Dacă emiterea reușește și importarea eșuează, reîncercați importarea în loc să cereți alt certificat, pentru că o a doua cerere ascunde defectul de implementare în spatele unui fișier nou. Documentația Certbot despre reînnoire spune clar că o rulare care nu actualizează nimic este un rezultat normal, așa că hookul este cel care le distinge.

Comparați lanțul prezentat cu fișierul

Citiți listenerul, nu discul. Conectați-vă la portul orientat spre clienți cu numele de server pe care îl folosesc clienții, apoi comparați amprenta și lanțul livrat cu linia pe care a instalat-o hookul. Două comenzi acoperă asta, iar prima arată și dacă intermediarele ajung deloc:

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

Apoi faceți o conexiune de client nouă, pentru că sesiunile stabilite înainte de importare au fost autentificate față de identitatea anterioară și nu dovedesc nimic despre cea nouă. Dacă clienții fixează frunza veche, au nevoie de o actualizare coordonată chiar și atunci când lanțul public este valid, iar acea sarcină aparține aceluiași runbook ca reînnoirea. Un proxy invers în fața serviciului poate prezenta un certificat bun în timp ce listenerul VPN îl ține încă pe cel vechi, și de aceea verificarea trebuie să numească portul la care ajung clienții cu adevărat. Notați amprenta lângă data reînnoirii, ca următoarea comparație să fie o verificare și nu un act de memorie.