Finder HAProxy-certifikatbundles, validerer certifikat og nøgle og kontrollerer aktivering lokalt.
Sådan forløber det
- Service-agenten på serveren henter opgaven fra appliancen over udgående HTTPS, port 443.
- Discovery finder konkrete PEM-filer fra crt, certifikatmapper og crt-list, også RSA/ECDSA-slots. På appliance 0.4.44 vælges målet ved at bekræfte CERT_PATH, CONFIG_PATH og SERVICE_NAME manuelt, når flere bindings findes. Utilgængelige konfigurationer og flere configfiler giver et delvist resultat.
- Certifikat og nøgle kontrolleres før hashing. Den samlede PEM-fil klargøres privat og konfigurationstestes før atomisk udskiftning; journalen bevarer tilstanden til retry og restore.
- Kun den valgte tjeneste genindlæses. Lokal TLS-kontrol sammenligner det serverede certifikat før og efter, med bindingens port, SNI og nøglealgoritme. Hvis det fejler: Restore bruges kun, når en tidligere fungerende lokal tjeneste nu er brudt. Det gamle målcertifikat, der stadig serveres, giver fejl uden service-restore. Afviser configtest filen efter udskiftning, gendannes den forrige fil uden reload; operatørændringer bevares og fejl vises særskilt.
Tekniske detaljer
- Forbindelse
- Pakken kører gennem service-agenten på serveren. Agenten forbinder over udgående HTTPS til appliancen, port 443 som standard. I åbner ingen port ind til serveren.
- Tjenestens porte
- 443, 80
- I skal bruge
- Service-agenten installeret på serveren. Læseadgang til konfigurationen og skriveadgang til en separat certifikatmappe. Deploykontoen må ikke kunne ændre konfiguration, Lua-filer eller andre filer, der kan eksekveres ved configtest/reload. Ved sudo: sudo -n til præcis haproxy -c -f med den valgte originale konfiguration og reload af den valgte tjeneste.
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
haproxy-ssh1.4.1 - Bemærk
-
- Discovery læser den konfiguration, den kørende HAProxy er startet med (processens -f, ellers systemd-enheden), og først derefter /etc/haproxy/haproxy.cfg. Deploy accepterer også en PEM-fil uden for standardmapperne, når en bind-linje i den aktive konfiguration peger på den.
- Hvis det nye certifikat allerede er aktivt, skiftes certifikatet ikke; målrettet takeover kontrolleres stadig. Uafklaret aktivering giver en advarsel. Lokal identitetskontrol beviser hverken offentlig tillid, ekstern adgang eller aktivering på andre HA-noder.
- Genererede testkonfigurationer køres uden sudo. Kan andre nøgler ikke læses, rapporteres begrænsningen; den faste originale konfiguration testes stadig før reload. Ingen bred sudo-ret til midlertidige konfigurationer kræves.
- Pakken erstatter før den deaktiverer: først skrives vores certifikat, HAProxy reloades, og den lokale kontrol skal se det nye certifikat. Først derefter slås en påvist ACME-klient-writer til den valgte bundlefil fra. En isoleret ACME-klient-hook (directory deploy-, pre- eller post-hook) mister kun kopieringen; den eksisterende reload af den valgte tjeneste bevares. Står kopieringen i én hook-linje (renew_hook, pre_hook eller post_hook) i én lineages renewal-konfiguration og gør linjen kun kopiering, chmod/chown af målet og reload af den valgte tjeneste, tages en backup af filen, og netop den linje udkommenteres. Andre lineages, ACME-klientens timer og andre tjenester røres ikke; klientens reconfigure-kommando, testfornyelse og hook-kørsel bruges ikke. En privat kvittering og backup viser ændringen, og fejler deployet, lægger en rollback af det backuppen tilbage; en afsluttet overtagelse bliver stående. SSH-kontoen skal kunne skrive filen uden ekstra sudo. En påvist writer, der ikke kan afgrænses sådan (fx i cli.ini, i en sh -c-streng, i et script, som en hook starter, eller i en linje, der også gør andet), stopper deploy før skift med en præcis forklaring. Det samme gælder native HAProxy ACME og acme.sh-installation til målet. Betinget eller ulæselig hook-tekst, hooks i en lineage med autorenew slået fra og referencer rapporteres, men stopper ikke deploy og beviser ikke eksklusiv styring.
- Nye probe-felter er valgfrie. Eksisterende rå PEM-input på appliance 0.4.44 bevares; binære runners og eksplicitte base64-felter understøttes. Ingen custom reload-kommando accepteres.
- Alpine/musl og systemer med BusyBox understøtter de valgte certifikatstier. Bash 4+, OpenSSL 1.1.1+, GNU coreutils 8.24+ og flock fra util-linux kræves stadig; installer dem på Alpine ud over BusyBox. Deploy understøtter én configfil; directory/multi-file configs og crt-store-aliaser er delvise discovery-resultater. Agenten sender kun reload: systemctl reload starter ikke en stoppet tjeneste; andre init-scripts kan have anden adfærd. Manuel rollback er betinget og ruller ikke et aktivt nyt certifikat tilbage.