Hoppa till innehåll 
Har ditt certifikat löpt ut eller är det på väg att löpa ut? I den här guiden kommer jag att visa dig specifikt hur du Förnya SSL-certifikat manuellt och automatiskt - inklusive typiska fallgropar, verktyg och lämpliga inställningar.
Jag guidar dig genom hosting, anpassade servrar och WordPress för att hjälpa dig att undvika avbrott, öka säkerheten och skydda konverteringar - från CSR till HSTS, från Let's Encrypt till Wildcard.
Centrala punkter
- Automatisk Förlänga: Aktivera hoster option, kontrollera status
- Manuell Förnya: Skapa CSR, installera, testa kedjan
- WordPress säker: Tillämpa HTTPS, använd plugins
- Fel undvika: .välkänd, kedja, omdirigeringar
- Försiktighetsåtgärder träffas: Övervakning, Cronjobs, HSTS
Varför SSL-certifikat upphör att gälla och vad det innebär för dig
Varje certifikat har en bestämd löptid, för publika certifikat högst 397 dagar. Efter utgången blockerar webbläsaren anslutningen, besökarna ser varningar och hoppar ofta av. Detta skadar förtroendet, konverteringen och synligheten i sökmotorerna. Jag undviker denna risk genom att hålla ett öga på utgångsdatumet i god tid och planera förnyelsen. De som förnyar i tid stannar kvar juridiskt kompatibel och håller dataöverföringar skyddade.
Aktivera automatisk förnyelse med hostingleverantören
Många hostingpaneler erbjuder aktivering med ett klick för Autoförnyelse. Jag aktiverar alternativet per domän, kontrollerar den lagrade valideringen (HTTP-01/DNS-01) och kontrollerar sedan giltigheten i webbläsarlåset. Med flera domäner och underdomäner sparar jag mycket tid och undviker luckor mellan två certifikat. För en säker grundläggande start, den kompakta 5 steg till en säker webbplats. Efter det håller jag bara ett öga på hostens utgångsmeddelanden och testar regelbundet HTTPS-åtkomsten.
Jag ser också till att Kontakta oss via e-post är uppdaterat på hoster-kontot så att förfallo- och felmeddelanden tas emot. Om Auto-Renew körs via ACME tar jag hänsyn till Gränsvärden för priser av CA och - om tillgängligt - använda en staging-miljö för tester så att jag inte oavsiktligt blockerar mig själv. För DNS-01-validering planerar jag TTL så att poster sprids snabbt. Finns det CAA Rekord i zonen kontrollerar jag om min certifikatutfärdare är tillåten där - annars kommer förnyelsen att misslyckas trots automatisk förnyelse.
För konfigurationer med flera domäner eller jokertecken kontrollerar jag om hostern stöder Automatisk DNS-uppdatering stöd. Utan en API-anslutning definierar jag tydliga processer: Vem skapar TXT-posterna, vem kontrollerar upplösningen och när tas de bort igen? Detta förberedande arbete säkerställer att Auto-Renew inte misslyckas på grund av organisatoriska hinder.
Manuell förlängning: Från CSR till installation
För speciella krav, root-servrar eller specifika certifieringsinstanser förnyar jag manuellt. Först skapar jag en ny CSR med en lämplig nyckel (RSA 2048+ eller ECDSA), inklusive korrekt gemensamt namn/alternativa namn för ämnet. Jag startar förnyelsebeställningen i CA-portalen, bekräftar domänkontrollen (t.ex. HTTP-01 via .well-known eller DNS-01 via TXT) och väntar på utfärdandet. Jag laddar sedan ner certifikatet och mellanliggande certifikat och kontrollerar kedjan lokalt. Jag lagrar certifikatet, nyckeln och det mellanliggande certifikatet i hostingpanelen (t.ex. Plesk eller cPanel) och testar Kedja med en SSL-kontroll.
Jag brukar använda Nya nycklar vid varje förnyelse för att hålla kryptostandarderna uppdaterade. För ECDSA använder jag till exempel en kurva som prime256v1; för RSA väljer jag minst 2048 bitar. CSR:n innehåller alltid alla de värdnamn som jag vill skydda - inklusive Basdomän och www (t.ex. example.tld och www.example.tld). Jag planerar installationen så att det nya certifikatet är klart innan det gamla löper ut; många servrar tillåter detta Smidig ersättning med en omladdning utan stilleståndstid.
Efter installationen testar jag leveransen både med www och utan www, via IPv4 och IPv6och kontrollerar hela kedjan. Om kedjan inte är korrekt importerar jag lämplig mellanprodukt från CA. Jag kontrollerar att servern endast är Ladda om (reload configuration), men starta inte om hårt så att aktiva anslutningar inte avbryts.
Serverpraxis: Apache, Nginx och IIS i en överblick
Med Apache Jag lagrar sökvägarna i vHost: SSLCertificateFile (servercertifikat), SSLCertificateKeyFile (privat nyckel) och - beroende på version - SSLCertificateChainFile eller en buntad fullständig kedjefil. Efter utbytet kontrollerar jag konfigurationen och laddar om den. För Nginx Jag ställer in ssl_certificate (full chain) och ssl_certificate_key (key). Jag testar konfigurationen, laddar om den och kontrollerar sedan HTTP/2/HTTP/3- och SNI-hanteringen via flera servernamn.
På IIS Jag importerar certifikatet till certifikatlagret (datorn) och binder det till webbplatsen. Det är viktigt att för varje värdnamn SNI om flera certifikat körs på samma IP. För automatiserade Windows-installationer schemalägger jag en ACME-klient för att hantera förnyelse och bindning. I samtliga fall dokumenterar jag sökvägarna, filbehörigheterna (nyckel endast för webbserverprocessen) och den exakta proceduren så att nästa förnyelsedatum går smidigt.
SSL i WordPress: Konfigurera, genomdriva, automatiskt förlänga
Med WordPress håller jag det enkelJag aktiverar Let's Encrypt i webbhotellet, tvingar fram HTTPS via plugin (t.ex. Really Simple SSL) och kontrollerar widgetar med blandat innehåll. Om WordPress körs på en egen server använder jag Certbot inklusive ett cronjob för automatisk förnyelse. I multisite-konfigurationer är det värt att använda ett wildcard-certifikat för att säkra underdomäner kollektivt. Jag använder den här handledningen för en snabb start: Gratis SSL i WordPress. Sedan kontrollerar jag låssymbolen i webbläsaren och certifikatets utgångsdatum i WordPress-verktygen.
Efter omställningen ersätter jag hårda http-länkar i databasen så att bilder, skript och stilar laddas rent via HTTPS. Jag kontrollerar också cacheplugins och CDN-integrationer för att säkerställa att de hanterar HTTPS-varianten korrekt. Viktigt: När jag tvingar HTTPS är jag uppmärksam på rena omdirigeringar (en 301-kedja) så att SEO-signaler inte späds ut och inga ändlösa loopar skapas.
På mina egna servrar planerar jag att använda Certbot-förnyelsen som Cronjob och lagra inläggskrokar som laddar om Nginx/Apache efter en lyckad förnyelse. I hanterade WordPress-miljöer använder jag hostens funktioner för automatisk förnyelse och kontrollerar regelbundet om .well-known-utmaningarna är tillgängliga - särskilt när säkerhetsplugins eller WAF-regler tillämpas strikt.
Undvik typiska fel: Validering, kedja, omdirigeringar
Ofta är Valideringom HTTP-01-filen under /.well-known/pki-validation/ inte är tillgänglig. Inför förnyelsen avaktiverar jag kort aggressiva omdirigeringar (t.ex. från icke-www till www) eller regler som blockerar åtkomst. Om mellanliggande certifikat saknas avvisar webbläsarna certifikatet; jag importerar hela kedjan. Om det finns flera certifikat på en IP måste SNI vara aktivt, annars kommer servern att leverera fel certifikat. Jag raderar cacheminnet efter varje ändring så att jag kan se den verkliga, aktuella statusen.
Andra typiska snubbelrisker: A AAAA rekord (IPv6) pekar på en annan server än A (IPv4), misslyckas utmaningen. Eller så blockerar WAF åtkomst till .well-known. Med DNS-01 orsakar höga TTL-fördröjningar; jag ställer tillfälligt in dem lägre. Existerar CAA Rekord utan godkännande för den CA som används, avbryter jag förnyelsen tills posten är korrigerad. I container- eller chroot-miljöer är jag uppmärksam på korrekta mounts och behörigheter så att webbservern eller ACME-klienten faktiskt kan leverera utmaningsfilerna.
Hosting-jämförelse: Vem förnyar mest tillförlitligt?
Jag är uppmärksam på en Intuitiv gränssnitt, automatisk förnyelse för alla domäner och snabb support. Detta sparar mig underhållstid och minskar driftstoppet avsevärt. För leverantörer med Let's Encrypt-integration ställer jag in alternativet för automatisk förnyelse en gång och kontrollerar tillgängligheten via HTTPS-övervakning. Det finns tydliga instruktioner för All-Inkl som gör aktiveringen mycket snabb: Let's Encrypt på All-Inkl. Följande tabell visar vad jag fäster särskild vikt vid i jämförelsen.
| Hostingleverantör | Automatisk förnyelse | Yta | Stöd | Värdering |
|---|---|---|---|---|
| webhoster.de | Ja | Mycket intuitiv | Snabb | 1:a plats |
| All-Inkl | Ja | Enkel | Bra | 2:a plats |
| Värd Europa | Delvis | Medium | Medium | 3:e plats |
| SSD webbhotell | Delvis | Medium | Medium | 4:e plats |
Jag kontrollerar också om leverantören DNS API:er för DNS-01 (viktigt för jokertecken), ger logginformation om misslyckade valideringar och om certifikat enkelt kan exporteras som en hel kedja. En bra panel visar Utgående certifikat Systemet startar i ett tidigt skede, tillåter detaljerade rättigheter (t.ex. endast SSL-hantering) och dokumenterar varje steg. Detta sparar tid och förhindrar att kunskapen blir knuten till enskilda personer.
Att känna igen processen och proaktivt förebygga den
Jag kan när som helst se statusen via Slottet-ikonen i webbläsaren, ger certifikatinformationen information om giltighet och utfärdare. Jag ställer också in aviseringar i hostingpanelen och ställer in övervakning som varnar för utgång. Mina egna servrar får ett cron-jobb som kör Certbot regelbundet och kontrollerar loggar. I WordPress håller jag mig informerad om aviseringar från säkerhetspluginsen och kontrollerar konsolen för blandat innehåll. Denna kombination förhindrar driftstopp och håller krypteringen aktiv utan avbrott.
För Teknisk kontroll Jag använder enkla kontroller: Hämta ut certifikatets utgångsdatum, kontrollera kedjan och protokollstödet (TLS 1.2/1.3). Vid övervakningen planerar jag varningsnivåer (t.ex. 30, 14 och 7 dagar före utgångsdatum) och kontrollerar om reload hooks verkligen har avfyrats efter en lyckad förnyelse. På så sätt kan jag upptäcka problem i ett tidigt skede - innan besökarna ser varningssidorna.
Säkerhetstuning efter förnyelsen
Efter förnyelsen får jag ut maximalt av TLS och aktiverar TLS 1.3 (utöver 1.2), avaktivera gamla protokoll och föråldrade chiffer. HSTS med tillräckligt lång max-age binder klienter till HTTPS och minskar attackytorna. OCSP-häftning minskar latenstiderna och avlastar OCSP-svararen från CA. Om du använder RSA, välj 2048 bitar eller byt till ECDSA för bättre prestanda om det behövs. I slutet validerar jag installationen med ett SSL-test och tar en närmare titt på protokollen och de kryptografiska inställningarna.
Jag föredrar modern chiffer med Forward Secrecy och aktiverar ALPN så att HTTP/2 och HTTP/3 används på ett effektivt sätt. Om tillgängligt ställer jag in parallella ECDSA- och RSA-certifikat På så sätt får moderna klienter den högpresterande ECDSA-varianten, medan äldre klienter förblir kompatibla via RSA. Jag ökar HSTS gradvis (t.ex. de första dagarna, sedan veckor) för att undvika att felkonfigurationer cementeras permanent. Jag kontrollerar aktivt OCSP-häftning efter omladdningen så att klienterna inte får några ytterligare nätverksfördröjningar.
Det praktiska förfarandet i korthet
Jag börjar med en statuskontroll, antecknar Utgångsdatum och bestämmer: Låt automatisk förnyelse vara aktiv eller förnya manuellt. För automatisk förnyelse kontrollerar jag valideringssökvägen (HTTP-01/DNS-01) och testar tillgängligheten för utmaningen. För manuell förnyelse skapar jag CSR, begär certifikatet från certifikatutfärdaren och installerar certifikatet plus kedjan. Sedan verkställer jag HTTPS, tar bort cacheminnen och kontrollerar blandat innehåll. Slutligen ställer jag in övervakning och aviseringar så att jag aldrig mer missar en deadline.
Specialfall: Jokertecken, flera domäner och valideringstyper
Om jag driver många underdomäner använder jag en Joker-certifikat (*.domän.tld) och sparar mig separata certifikat. För flera helt olika domäner förlitar jag mig på SAN/UCC-certifikat som sammanfattar flera värdnamn. DV-certifikat är tillräckliga för de flesta projekt, OV/EV ger ytterligare identitetsverifiering - användbart för butiker eller portaler med känsliga uppgifter. Jag är uppmärksam på körtidsgränserna och planerar förnyelsen så att det inte finns någon korsning under toppdrift. För DNS-validering på produktiva zoner arbetar jag med tydliga namngivningskonventioner så att jag snabbt kan hitta poster igen och Förändring kan.
Med Joker är viktigt: Validering utförs uteslutande via DNS-01, så jag använder automatiska DNS-uppdateringar eller dedikerade underhållsfönster. I miljöer med flera domäner ser jag till att alla varianter finns i SAN-listan (inklusive underdomäner som har lagts till under årets gång). För inställningar av lastbalanserare planerar jag Distribution av de nya certifikaten till alla noder och testa sedan varje VIP/region separat. När team byts ut är det bra att ha tydlig dokumentation om vem som får vilka hemligheter (nycklar) och när, samt hur de förvaras på ett säkert sätt.
ACME och komplexa miljöer: CDN, WAF och omvända proxyer
Använder jag CDN eller en WAF, ser jag till att valideringen når Origin: Antingen låter jag challenge-begärandena besvaras vid Edge (om det stöds) eller så utför jag riktade förbikopplingar för /.välkänd/ på. För HTTP-01 kan det finnas en omdirigering till HTTPS, men utmaningen måste vara tillgänglig utan auth-rubriker, hastighetsbegränsningar eller geoblockeringar. För DNS-01 testar jag om TXT-posten är tillgänglig över hela världen och om det inte finns någon split horizon-konfiguration som stör utvärderingen.
Bakom Omvända proxyservrar Jag kontrollerar rubrikerna längre bak (X-Forwarded-Proto) så att programmet reagerar korrekt på HTTPS och inte genererar några fel med blandat innehåll. För förnyelser utan nedtid rullar jag certifikat steg för steg först en knut, sedan de andra - så att jag snabbt kan rulla tillbaka om det uppstår problem utan att riskera alla anslutningar.
Nödplan: avbokning, nyckelförlust och snabb ersättning
Om det finns en Nyckel-läcka eller en kompromiss, återkallar jag omedelbart certifikatet och utfärdar ett nytt med nya nycklar. Jag behåller en Checklista klar: Tillgång till CA-portalen, återkallelseförfarande, generering av nya nycklar, snabb distribution och omladdning. Jag kontrollerar sedan OCSP-häftning och cacher för att ta bort gamla kedjor från cacherna. Jag noterar orsaken, tiden och motåtgärderna i dokumentationen - detta underlättar revisioner och förhindrar upprepningar.
Kortfattat sammanfattat
Jag förnyar certifikat i god tid, kontrollerar Autoförnyelse-funktion och hålla valideringen tillgänglig. Där automatisk förnyelse inte fungerar förnyar jag manuellt: genererar CSR, tillämpar, installerar kedja, testar HTTPS. Jag säkrar WordPress med tvingande HTTPS och övervakning, mina egna servrar styrs av cronjobs och Certbot. Jag undviker fel genom att hålla ett öga på .well-known-utmaningen, mellanliggande certifikat, SNI och vidarebefordringsregler. Med den här processen förblir krypteringen aktiv, användarna litar på webbplatsen och synligheten lider inte av utgångsvarningar.
