Hittar HAProxy-certifikatpaket, validerar certifikat och nyckel och kontrollerar aktivering lokalt.
Så går det till
- Serviceagenten på servern hämtar uppgiften från appliancen över utgående HTTPS, port 443.
- Discovery hittar konkreta PEM-filer från crt, certifikatmappar och crt-list, även RSA/ECDSA-fack. På appliance 0.4.44 väljs målet genom att bekräfta CERT_PATH, CONFIG_PATH och SERVICE_NAME manuellt när flera bindningar finns. Otillgängliga konfigurationer och flera konfigurationsfiler ger ett delvis resultat.
- Certifikat och nyckel kontrolleras före hashning. Den samlade PEM-filen förbereds privat och konfigurationstestas före atomiskt byte; journalen behåller tillståndet för retry och restore.
- Endast den valda tjänsten läses om. Lokal TLS-kontroll jämför serverat certifikat före och efter med bindningens port, SNI och nyckelalgoritm. Om det misslyckas: Restore används endast när en tidigare fungerande lokal tjänst nu är trasig. Det gamla målcertifikatet som fortfarande serveras ger fel utan service-restore. Om configtest avvisar filen efter bytet återställs den tidigare filen utan reload; operatörsändringar bevaras och fel visas separat.
Tekniska detaljer
- Anslutning
- Paketet körs genom serviceagenten på servern. Agenten ansluter över utgående HTTPS till appliancen, port 443 som standard. Ni öppnar ingen port in till servern.
- Tjänstens portar
- 443, 80
- Ni behöver
- Serviceagenten installerad på servern. Läsåtkomst till konfigurationen och skrivåtkomst till en separat certifikatmapp. Deploykontot får inte kunna ändra konfiguration, Lua-filer eller andra filer som kan köras vid configtest/reload. Med sudo: sudo -n för exakt haproxy -c -f med den valda originalkonfigurationen och reload av den valda tjänsten.
- Åtgärder
- Discovery, Installation, Kontroll, Rollback
- Paket
-
haproxy-ssh1.4.1 - Observera
-
- Discovery läser konfigurationen som den körande HAProxy startades med (processens -f, annars systemd-enheten), och först därefter /etc/haproxy/haproxy.cfg. Deploy godtar även en PEM-fil utanför standardkatalogerna när en bind-rad i den aktiva konfigurationen pekar på den.
- Om det nya certifikatet redan är aktivt byts inte certifikatet; riktad takeover kontrolleras fortfarande. Oklar aktivering ger en varning. Lokal identitetskontroll bevisar varken publik tillit, extern åtkomst eller aktivering på andra HA-noder.
- Genererade testkonfigurationer körs utan sudo. Om andra nycklar inte kan läsas rapporteras begränsningen; den fasta originalkonfigurationen testas fortfarande före reload. Ingen bred sudo-rätt till tillfälliga konfigurationer krävs.
- Paketet ersätter innan det inaktiverar: först skrivs vårt certifikat, HAProxy laddas om och den lokala kontrollen måste se det nya certifikatet. Först därefter stängs en påvisad ACME-klient-writer till den valda paketfilen av. En isolerad ACME-klient-hook (directory deploy-, pre- eller post-hook) förlorar bara kopieringen; befintlig reload av den valda tjänsten behålls. Står kopieringen i en hook-rad (renew_hook, pre_hook eller post_hook) i en lineages renewal-konfiguration och gör raden bara kopiering, chmod/chown av målet och reload av den valda tjänsten, tas en backup av filen och just den raden kommenteras bort. Andra lineages, ACME-klientens timer och andra tjänster rörs inte; klientens reconfigure-kommando, testförnyelse och hook-körning används inte. Ett privat kvitto och backup visar ändringen, och misslyckas deployen lägger en rollback av den tillbaka backupen; en avslutad övertagning står kvar. SSH-kontot måste kunna skriva filen utan extra sudo. En påvisad writer som inte kan avgränsas så (t.ex. i cli.ini, i en sh -c-sträng, i ett skript som en hook startar eller i en rad som också gör annat) stoppar deploy före bytet med en exakt förklaring. Detsamma gäller native HAProxy ACME och acme.sh-installation till målet. Villkorad eller oläslig hook-text, hooks i en lineage med autorenew avstängd och referenser rapporteras men stoppar inte deploy och bevisar inte exklusiv hantering.
- Nya probe-fält är valfria. Befintlig rå PEM-input på appliance 0.4.44 bevaras; binära runners och explicita base64-fält stöds. Inget eget reload-kommando accepteras.
- Alpine/musl och system med BusyBox stöder valda certifikatsökvägar. Bash 4+, OpenSSL 1.1.1+, GNU coreutils 8.24+ och flock från util-linux krävs fortfarande; installera dem på Alpine utöver BusyBox. Deploy stöder en konfigurationsfil; directory/multi-file configs och crt-store-aliaser är delvisa discovery-resultat. Agenten skickar endast reload: systemctl reload startar inte en stoppad tjänst; andra init-scripts kan bete sig annorlunda. Manuell rollback är villkorad och återställer inte ett aktivt nytt certifikat.