Sikkerhed

Er certifikatet udløbet? Sådan fornyer du SSL manuelt og automatisk - SSL-certifikatfornyelse i detaljer

Er dit certifikat udløbet, eller er det ved at udløbe? I denne guide viser jeg dig specifikt, hvordan du Forny SSL-certifikat manuelt og automatisk - herunder typiske faldgruber, værktøjer og passende indstillinger.

Jeg guider dig gennem hosting, brugerdefinerede servere og WordPress for at hjælpe dig med at undgå udfald, øge sikkerheden og beskytte konverteringer - fra CSR til HSTS, fra Let's Encrypt til Wildcard.

Centrale punkter

Automatisk Udvid: Aktivér hoster-mulighed, tjek status
Manuel Forny: Opret CSR, installer, test kæde
WordPress sikker: Gennemtving HTTPS, brug plugins
Fejl undgå: .well-known, kæde, omdirigeringer
Forsigtighed mødes: Overvågning, Cronjobs, HSTS

Hvorfor SSL-certifikater udløber, og hvad det betyder for dig

Hvert certifikat har en fast løbetid, for offentlige certifikater maksimalt 397 dage. Efter udløb blokerer browseren forbindelsen, besøgende ser advarsler og hopper ofte af. Det skader tilliden, konverteringen og synligheden i søgemaskinerne. Jeg undgår denne risiko ved at holde øje med udløbsdatoen i god tid og planlægge fornyelsen. De, der fornyer til tiden, bliver juridisk kompatibel og holder dataoverførsler beskyttet.

Aktivér automatisk fornyelse med hostingudbyderen

Mange hostingpaneler tilbyder aktivering med et enkelt klik for Automatisk fornyelse. Jeg aktiverer indstillingen pr. domæne, kontrollerer den gemte validering (HTTP-01/DNS-01) og kontrollerer derefter gyldigheden i browserlåsen. Med flere domæner og underdomæner sparer jeg en masse tid og undgår huller mellem to certifikater. For en sikker grundlæggende start er den kompakte 5 trin til en sikker hjemmeside. Derefter holder jeg bare øje med hosterens udløbsmeddelelser og tester regelmæssigt HTTPS-tilgængeligheden.

Jeg sørger også for, at Kontakt e-mail er opdateret på hoster-kontoen, så udløbs- og fejlmeddelelser modtages. Hvis Auto-Renew kører via ACME, tager jeg højde for Prisgrænser af CA og - hvis det er muligt - bruge et staging-miljø til test, så jeg ikke utilsigtet kommer til at blokere mig selv. Til DNS-01-validering planlægger jeg TTL'er, så poster spredes hurtigt. Er der CAA-rekorder i zonen, kontrollerer jeg, om min certificeringsmyndighed er tilladt der - ellers vil fornyelsen mislykkes på trods af automatisk fornyelse.

For opsætninger med flere domæner eller wildcard tjekker jeg, om hosteren understøtter Automatisk DNS-opdatering støttet. Uden en API-forbindelse definerer jeg klare processer: Hvem opretter TXT-posterne, hvem kontrollerer opløsningen, og hvornår fjernes de igen? Dette forberedende arbejde sikrer, at Auto-Renew ikke mislykkes på grund af organisatoriske forhindringer.

Manuel udvidelse: Fra CSR til installation

Til særlige krav, rodservere eller visse certificeringsmyndigheder fornyer jeg manuelt. Først opretter jeg en ny CSR med en passende nøgle (RSA 2048+ eller ECDSA), inklusive det korrekte fælles navn/alternative navne på emnet. Jeg starter fornyelsesordren i CA-portalen, bekræfter domænekontrollen (f.eks. HTTP-01 via .well-known eller DNS-01 via TXT) og venter på udstedelse. Derefter downloader jeg certifikatet og de mellemliggende certifikater og kontrollerer kæden lokalt. Jeg gemmer certifikatet, nøglen og det mellemliggende certifikat i hostingpanelet (f.eks. Plesk eller cPanel) og tester kæden. Kæde med et SSL-tjek.

Jeg bruger normalt Nye nøgler ved hver fornyelse for at holde kryptostandarderne opdaterede. Til ECDSA bruger jeg f.eks. en kurve som prime256v1; til RSA vælger jeg mindst 2048 bits. CSR'en indeholder altid alle de værtsnavne, som jeg ønsker at sikre - herunder Basisdomæne og www (f.eks. example.tld og www.example.tld). Jeg planlægger installationen, så det nye certifikat er klar, før det gamle udløber; mange servere tillader dette Problemfri udskiftning med en genindlæsning uden nedetid.

Efter installationen tester jeg leveringen både med www og uden www, via IPv4 og IPv6og tjekker hele kæden. Hvis kæden ikke er korrekt, importerer jeg den relevante mellemliggende del af CA'en. Jeg sørger for, at serveren kun er Genindlæsning (genindlæs konfiguration), må du ikke genstarte hårdt, så aktive forbindelser ikke afbrydes.

Serverpraksis: Et overblik over Apache, Nginx og IIS

Med Apache Jeg gemmer stierne i vHost: SSLCertificateFile (servercertifikat), SSLCertificateKeyFile (privat nøgle) og - afhængigt af versionen - SSLCertificateChainFile eller en samlet fuld kædefil. Efter udvekslingen kontrollerer jeg konfigurationen og genindlæser den. For Nginx Jeg indstiller ssl_certificate (fuld kæde) og ssl_certificate_key (nøgle). Jeg tester konfigurationen, genindlæser den og tjekker derefter HTTP/2/HTTP/3 og SNI-håndtering via flere servernavne.

På IIS Jeg importerer certifikatet til certifikatlageret (computeren) og binder det til webstedet. Det er vigtigt, at for hvert værtsnavn SNI hvis flere certifikater kører på samme IP. For automatiserede Windows-opsætninger planlægger jeg en ACME-klient til at håndtere fornyelse og binding. I alle tilfælde dokumenterer jeg stierne, filtilladelserne (kun nøgle til webserverprocessen) og den nøjagtige procedure, så den næste fornyelsesdato forløber gnidningsløst.

SSL i WordPress: Opsæt, håndhæv, udvid automatisk

Med WordPress holder jeg det simpelJeg aktiverer Let's Encrypt i hostingen, gennemtvinger HTTPS via et plugin (f.eks. Really Simple SSL) og kontrollerer widgets med blandet indhold. Hvis WordPress kører på sin egen server, bruger jeg Certbot inklusive et cronjob til automatisk fornyelse. I multisite-opsætninger er det værd at bruge et wildcard-certifikat til at sikre underdomæner kollektivt. Jeg bruger denne vejledning til en hurtig start: Gratis SSL i WordPress. Derefter tjekker jeg låsesymbolet i browseren og certifikatets udløbsdato i WordPress-værktøjerne.

Efter omstillingen udskifter jeg hårde http-links i databasen, så billeder, scripts og stilarter indlæses rent via HTTPS. Jeg tjekker også caching-plugins og CDN-integrationer for at sikre, at de håndterer HTTPS-varianten korrekt. Vigtigt: Når jeg gennemtvinger HTTPS, er jeg opmærksom på rene omdirigeringer (en 301-kæde), så SEO-signaler ikke udvandes, og der ikke skabes endeløse sløjfer.

På mine egne servere planlægger jeg at bruge Certbot-Renewal som Cronjob og gemme posthooks, der genindlæser Nginx/Apache efter en vellykket fornyelse. I administrerede WordPress-miljøer bruger jeg hosterens automatiske fornyelsesfunktioner og kontrollerer regelmæssigt, om de kendte udfordringer er tilgængelige - især når sikkerhedsplugins eller WAF-regler håndhæves strengt.

Undgå typiske fejl: Validering, kæde, omdirigeringer

Ofte er Valideringhvis HTTP-01-filen under /.well-known/pki-validation/ ikke er tilgængelig. I forbindelse med fornyelsen deaktiverer jeg kort aggressive omdirigeringer (f.eks. fra ikke-www til www) eller regler, der blokerer for adgang. Hvis der mangler mellemliggende certifikater, afviser browsere certifikatet; jeg importerer den komplette kæde. Hvis der er flere certifikater på en IP, skal SNI være aktiv, ellers vil serveren levere det forkerte certifikat. Jeg sletter cacher efter hver ændring, så jeg kan se den rigtige, aktuelle status.

Andre typiske snublefarer: A AAAA-rekord (IPv6) peger på en anden server end A (IPv4), mislykkes udfordringen. Eller WAF'en blokerer for adgang til .well-known. Med DNS-01 forårsager høje TTL'er forsinkelser; jeg sætter dem midlertidigt lavere. Eksisterer CAA-rekorder uden godkendelse af den anvendte CA, annullerer jeg fornyelsen, indtil posten er rettet. I container- eller chroot-miljøer er jeg opmærksom på korrekte mounts og tilladelser, så webserveren eller ACME-klienten rent faktisk kan levere challenge-filerne.

Hosting-sammenligning: Hvem fornyer mest pålideligt?

Jeg er opmærksom på en Intuitiv interface, automatisk fornyelse af alle domæner og hurtig support. Det sparer mig for vedligeholdelsestid og reducerer nedetiden betydeligt. For udbydere med Let's Encrypt-integration indstiller jeg den automatiske fornyelse én gang og kontrollerer tilgængeligheden via HTTPS-overvågning. Der er klare instruktioner til All-Inkl, som gør aktiveringen meget hurtig: Let's Encrypt på All-Inkl. Følgende tabel viser, hvad jeg lægger særlig vægt på i sammenligningen.

Hosting-udbyder	Automatisk fornyelse	Overflade	Støtte	Værdiansættelse
webhoster.de	Ja	Meget intuitiv	Hurtig	1. plads
All-Inkl	Ja	Enkel	God	2. plads
Vært for Europa	Delvist	Medium	Medium	3. plads
SSD-webhosting	Delvist	Medium	Medium	4. plads

Jeg tjekker også, om udbyderen DNS-API'er for DNS-01 (vigtigt for jokertegn), giver logindblik i mislykkede valideringer, og om certifikater nemt kan eksporteres som en fuld kæde. Et godt panel viser Udløbende certifikater Systemet starter på et tidligt tidspunkt, giver detaljerede rettigheder (f.eks. kun SSL-ledelse) og dokumenterer hvert trin. Det sparer tid og forhindrer, at viden bliver bundet til enkelte personer.

Genkende processer og forebygge dem proaktivt

Jeg kan til enhver tid se status via Slot-ikonet i browseren, giver certifikatoplysningerne information om gyldighed og udsteder. Jeg indstiller også notifikationer i hostingpanelet og opsætter overvågning, der advarer om udløb. Mine egne servere modtager et cron-job, der kører Certbot regelmæssigt og tjekker logfiler. I WordPress holder jeg mig orienteret om notifikationer fra sikkerhedsplugins og tjekker konsollen for blandet indhold. Denne kombination forhindrer nedetid og holder krypteringen aktiv uden afbrydelser.

For Teknisk kontrol Jeg bruger enkle kontroller: Hentning af certifikatets udløbsdatoer, kontrol af kæden og protokolunderstøttelse (TLS 1.2/1.3). I overvågningen planlægger jeg advarselsniveauer (f.eks. 30, 14 og 7 dage før udløb) og kontrollerer, om reload hooks virkelig er blevet affyret efter en vellykket fornyelse. Det giver mig mulighed for at opdage problemer på et tidligt tidspunkt - før de besøgende ser advarselssider.

Sikkerhedstuning efter fornyelsen

Efter fornyelsen får jeg det maksimale ud af TLS og aktiverer TLS 1.3 (ud over 1.2) skal du deaktivere gamle protokoller og forældede cifre. HSTS med tilstrækkelig lang max-age binder klienter til HTTPS og reducerer angrebsflader. OCSP-hæftning reducerer ventetiden og aflaster OCSP-responderen fra CA'en. Hvis du bruger RSA, skal du vælge 2048 bit eller skifte til ECDSA for at få bedre ydelse, hvis det er nødvendigt. Til sidst validerer jeg opsætningen med en SSL-test og kigger nærmere på protokollerne og de kryptografiske indstillinger.

Jeg foretrækker Moderne chiffer med Forward Secrecy og aktiverer ALPN, så HTTP/2 og HTTP/3 bruges effektivt. Hvis det er muligt, indstiller jeg parallel ECDSA- og RSA-certifikater På den måde får moderne klienter den højtydende ECDSA-variant, mens ældre klienter forbliver kompatible via RSA. Jeg øger HSTS gradvist (f.eks. de første dage, derefter uger) for at undgå at cementere fejlkonfigurationer permanent. Jeg kontrollerer aktivt OCSP-hæftning efter genindlæsningen, så klienterne ikke får yderligere netværksforsinkelser.

Praktisk procedure i korte træk

Jeg starter med et statustjek, noterer mig Udløbsdato og beslutter: lad automatisk fornyelse være aktiv eller forny manuelt. Ved automatisk fornyelse kontrollerer jeg valideringsstien (HTTP-01/DNS-01) og tester tilgængeligheden af udfordringen. Ved manuel fornyelse opretter jeg CSR'en, anmoder om certifikatet fra certificeringsmyndigheden og installerer certifikatet plus kæde. Derefter håndhæver jeg HTTPS, sletter cacher og kontrollerer blandet indhold. Til sidst sætter jeg overvågning og notifikationer op, så jeg aldrig misser en deadline igen.

Særlige tilfælde: Jokertegn, multi-domæne og valideringstyper

Hvis jeg driver mange underdomæner, bruger jeg en Wildcard-certifikat (*.domain.tld) og sparer mig selv for separate certifikater. Til flere helt forskellige domæner er jeg afhængig af SAN/UCC-certifikater, der opsummerer flere værtsnavne. DV-certifikater er tilstrækkelige til de fleste projekter, OV/EV giver yderligere identitetsbekræftelse - nyttigt for butikker eller portaler med følsomme data. Jeg er opmærksom på runtime-grænserne og planlægger fornyelsen, så der ikke er noget skæringspunkt under spidsbelastning. Til DNS-validering på produktive zoner arbejder jeg med klare navngivningskonventioner, så jeg hurtigt kan finde poster igen og Forandring kan.

Med Wildcard er vigtig: Validering udføres udelukkende via DNS-01, så jeg bruger automatiserede DNS-opdateringer eller dedikerede vedligeholdelsesvinduer. I miljøer med flere domæner sørger jeg for, at alle varianter er på SAN-listen (inklusive underdomæner, der er blevet tilføjet i løbet af året). For load balancer-opsætninger planlægger jeg Distribution af de nye certifikater til alle noder og test derefter hver VIP/region separat. Med skiftende teams hjælper det at have klar dokumentation for, hvem der modtager hvilke hemmeligheder (nøgler) og hvornår, og hvordan de opbevares sikkert.

ACME og komplekse miljøer: CDN, WAF og reverse proxies

Skal jeg bruge CDN eller en WAF, sørger jeg for, at valideringen når frem til Origin: Enten får jeg challenge-anmodningerne besvaret ved Edge (hvis det understøttes), eller også udfører jeg målrettede bypasses for /.well-known/ på. For HTTP-01 kan der være en omdirigering til HTTPS, men udfordringen skal være tilgængelig uden auth-headers, hastighedsgrænser eller geoblokeringer. For DNS-01 tester jeg, om TXT-indgangen er tilgængelig i hele verden, og om der ikke er nogen split horizon-konfiguration, der forstyrrer evalueringen.

Bagved Omvendte proxyer Jeg tjekker overskrifterne længere tilbage (X-Forwarded-Proto), så programmet reagerer korrekt på HTTPS og ikke genererer fejl med blandet indhold. For fornyelser uden nedetid ruller jeg certifikater skridt for skridt Først en knude, så de andre - så jeg hurtigt kan rulle tilbage i tilfælde af problemer uden at risikere alle forbindelser.

Nødplan: aflysning, tab af nøgle og hurtig udskiftning

Hvis der er en Nøgle-lækage eller et kompromis, tilbagekalder jeg straks certifikatet og udsteder et nyt med nye nøgler. Jeg opbevarer en Tjekliste klar: Adgang til CA-portalen, tilbagekaldelsesprocedure, generering af nye nøgler, hurtig distribution og genindlæsning. Derefter tjekker jeg OCSP-hæftning og cacher for at fjerne gamle kæder fra cacherne. Jeg noterer årsag, tidspunkt og modforanstaltninger i dokumentationen - det gør audits nemmere og forhindrer gentagelser.

Kort opsummeret

Jeg fornyer certifikater i god tid, tjekker Automatisk fornyelse-funktion og holder valideringen tilgængelig. Hvor automatisk fornyelse ikke virker, fornyer jeg manuelt: genererer CSR, anvender, installerer kæde, tester HTTPS. Jeg sikrer WordPress med tvungen HTTPS og overvågning, og mine egne servere styres af cronjobs og Certbot. Jeg undgår fejl ved at holde øje med .well-known challenge, mellemliggende certifikater, SNI og videresendelsesregler. Med denne proces forbliver krypteringen aktiv, brugerne har tillid til webstedet, og synligheden lider ikke under udløbsadvarsler.