Hoppa till innehåll

← Alla integrationer

Linux · Webbserver

Hittar aktiva TLS-serverblock och byter certifikat och nyckel med lokal kontroll av aktiveringen.

Serviceagenten på servern hämtar uppgiften från appliancen över utgående HTTPS på port 443 och installerar certifikatet lokalt på servern. Appliancen ansluter aldrig till servern.

Så går det till

  1. Serviceagenten på servern hämtar uppgiften från appliancen över utgående HTTPS, port 443.
  2. Certifikat och nyckel valideras och förbereds vid valda CERT_PATH och KEY_PATH. De tidigare filerna sparas och en lokal journal registrerar förloppet. Om det misslyckas: Ogiltig PEM eller en nyckel som inte matchar certifikatet ger ett JSON-resultat utan att byta de aktiva filerna.
  3. Vid RELOAD=true testar Nginx konfigurationen och läser de förberedda filerna som kontroll före bytet.
  4. Filerna byts och Nginx läses om som standard. RELOAD_MAY_RESTART=true tillåter en nginx-omstart om två omläsningar fortfarande visar det tidigare certifikatet. Andra tjänster startas inte om.
  5. Kontroll: paketet jämför certifikatet som Nginx visar lokalt med det nya certifikatets SHA-256-fingeravtryck. Ett avbrutet förlopp stäms av mot journalen och den aktuella tjänsten före nytt arbete. Om det misslyckas: Om bytet bryter en tidigare fungerande lokal TLS-tjänst försöks återställning med separat resultat. Ett fungerande nytt certifikat återställs inte vid återupptagning. Rollback använder journalen och bevarar senare filändringar.

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. Serviceagenten ska kunna läsa nginx-konfigurationen och skriva i certifikatets och nyckelns kataloger samt vald konfigurationskatalog vid takeover. check-access kontrollerar åtkomst och nginx -t. Valfri sudo-behörighet för nginx -T läser aktiv konfiguration privat; den omfattar bara fasta nginx-kontroller och tjänsteåtgärder, inte filskrivning eller egna kommandon.
Åtgärder
Discovery, Installation, Kontroll, Rollback
Paket
nginx-ssh 1.4.0
Observera
  • Discovery frågar den körande Nginx var konfigurationen ligger: masterprocessens -c, annars systemd-enheten, annars nginx -V. Include-filer följs som Nginx själv gör. Deploy och rollback godtar även certifikat och nyckel utanför standardkatalogerna när ett serverblock i den aktiva konfigurationen använder just det paret.
  • CERT_PATH och KEY_PATH ska anges från discovery eller konfiguration, även vid ad hoc-installation. Paketet gissar inte filnamn från domänen. Discovery visar aktiva serverblock och kända certifikathanterare; en reservväg till aktiverade konfigurationsfiler markeras i resultatet.
  • CERT_PEM och KEY_PEM accepterar rå PEM från appliance 0.4.44 eller base64. Valfria CERT_PEM_BASE64 och KEY_PEM_BASE64 har var för sig företräde. Gränsen är 48 000 avkodade byte per värde. Ett angivet ogiltigt base64-värde ersätts inte med ett annat värde.
  • RELOAD=false ändrar filerna och eventuell vald certifikatbindning på disk utan att läsa om tjänsten. Aktivering är inte bekräftad; ursprungliga filer och journalen behålls för senare kontroll eller återställning. RELOAD_MAY_RESTART är false som standard. Paketet använder systemctl, OpenRC eller tjänstens befintliga nginx-kontroll.
  • En regel ändrar bara valt serverblock. Native ACME tas bort bara om ingen annan bindning i serverblocket använder det. Vanlig extern förnyelse och acme.sh med sparade installationsvägar och vanlig nginx-omläsning använder dedikerade certifikatfiler, så källans senare förnyelse inte skriver över vald bindning. Andra servrar, certifikat och gemensamma renewal-timers ändras inte; paketet kör inte hooks. Vid första övertagandet samordnar agenten konkret hittade acme.sh-writers till den berörda konfigurationsfilen: nya starter väntar, pågående challenges avslutas och klienten återupptas efter bytet. Det kan kortvarigt fördröja andra lineages i samma installation. LOCAL_TLS_SNI skiljer servrar med samma källcertifikat åt. Resultatet anger faktiska cert_path/key_path för senare kontroll.
  • Samordning använder Linux fanotify för att hålla tillbaka nya klientstarter utan att ändra klientfilen. Den konkreta installationen kräver befintlig CAP_SYS_ADMIN och kernel-stöd; fast nginx-sudo ger inte denna capability. Saknad capability ger ett konkret fel före bytet, inte ett allmänt root-krav. Vanlig förnyelse efter övertagandet bevaras. Dolda privilegierade launchers och egna asynkrona hooks utesluts inte universellt. Vid avbrott släpper kernel-barriären väntande starter; nästa agentkörning samordnar igen före recovery. Klientens inställningar och uppgraderingar bevaras.
  • Återställning av tidigare serverat certifikat kräver ett läsbart, matchande certifikat och nyckel. Native ACME-cache används bara när leaf och nyckel matchar den lokala observationen. Första native-övertagandet avvisas före konfigurationsändring eller omläsning med native_restore_material_unavailable om det fungerande gamla certifikatet saknar ett validerat, återställbart nyckelpar, inklusive vid state_path off eller oanvändbar cache. Bevara eller exportera det gamla paret före ett nytt försök. Ett validerat inkommande par som matchar det observerade gamla certifikatet kan också användas. Vanlig förnyelse efter övertagande bevaras. Äldre journaler där bytet redan har skett kan fortfarande ange restore_material_unavailable; journalen kan inte återskapa en privat nyckel.
  • LOCAL_TLS_HOST är 127.0.0.1 eller ::1. LOCAL_TLS_PORT och LOCAL_TLS_SNI kan anges för vald lyssnare. Kontrollen mäter det lokala certifikatets identitet; den bevisar inte extern åtkomst, hela tillitskedjan eller andra noder.

Kom igång