Is je certificaat verlopen of staat het op het punt te verlopen? In deze gids laat ik je specifiek zien hoe je SSL-certificaat vernieuwen handmatig en automatisch - inclusief typische valkuilen, hulpmiddelen en geschikte instellingen.
Ik leid je door hosting, aangepaste servers en WordPress om storingen te voorkomen, de beveiliging te verhogen en conversies te beschermen - van CSR tot HSTS, van Let's Encrypt tot Wildcard.
Centrale punten
- Automatisch Uitbreiden: hosteroptie activeren, status controleren
- Handmatig Vernieuwen: CSR aanmaken, installeren, keten testen
- WordPress veilig: HTTPS afdwingen, plugins gebruiken
- Fout vermijden: .bekend, keten, omleidingen
- Voorzorgsmaatregel ontmoeten: Bewaking, Cronjobs, HSTS
Waarom SSL-certificaten verlopen en wat dit voor u betekent
Elk certificaat heeft een vaste looptijd, voor publieke certificaten maximaal 397 dagen. Na afloop blokkeert de browser de verbinding, bezoekers zien waarschuwingen en haken vaak af. Dit schaadt het vertrouwen, de conversie en de zichtbaarheid in zoekmachines. Dit schaadt het vertrouwen, de conversie en de zichtbaarheid in zoekmachines. Ik voorkom dit risico door de vervaldatum op tijd in de gaten te houden en de verlenging te plannen. Degenen die op tijd verlengen blijven wettelijk conform en houdt de gegevensoverdracht beschermd.
Automatische verlenging activeren bij de hostingprovider
Veel hostingpanelen bieden activering met één klik voor Automatisch vernieuwen. Ik activeer de optie per domein, controleer de opgeslagen validatie (HTTP-01/DNS-01) en controleer vervolgens de geldigheid in het slot van de browser. Met meerdere domeinen en subdomeinen bespaar ik veel tijd en voorkom ik hiaten tussen twee certificaten. Voor een veilige basisstart is de compacte 5 stappen naar een veilige website. Daarna houd ik gewoon de vervalberichten van de hoster in de gaten en test ik regelmatig de HTTPS-toegankelijkheid.
Ik zorg er ook voor dat de Contact e-mail up-to-date is in het hosteraccount zodat verval- en foutmeldingen worden ontvangen. Als Auto-Renew via ACME loopt, houd ik rekening met Tariefgrenzen van de CA en - indien beschikbaar - gebruik ik een staging-omgeving voor tests zodat ik mezelf niet per ongeluk blokkeer. Voor DNS-01 validatie plan ik TTL's zodat entries snel propageren. Is er CAA-gegevens in de zone, controleer ik of mijn certificeringsinstantie daar is toegestaan - anders mislukt de verlenging ondanks automatisch verlengen.
Voor instellingen met meerdere domeinen of wildcards controleer ik of de hoster de Automatische DNS-update ondersteund. Zonder API-verbinding definieer ik duidelijke processen: Wie maakt de TXT-records aan, wie controleert de resolutie en wanneer worden ze weer verwijderd? Dit voorbereidende werk zorgt ervoor dat Auto-Renew niet mislukt door organisatorische hindernissen.
Handmatige verlenging: Van CSR tot installatie
Voor speciale vereisten, root servers of bepaalde certificeringsautoriteiten, vernieuw ik handmatig. Eerst maak ik een nieuw CSR aan met een geschikte sleutel (RSA 2048+ of ECDSA), inclusief de juiste common name/subject alternative names. Ik start de verlengingsopdracht in het CA-portaal, bevestig de domeincontrole (bijv. HTTP-01 via .well-known of DNS-01 via TXT) en wacht op uitgifte. Vervolgens download ik het certificaat en de tussenliggende certificaten en controleer ik de keten lokaal. Ik sla het certificaat, de sleutel en de tussenliggende certificaten op in het hostingpaneel (bijv. Plesk of cPanel) en test de Ketting met een SSL-controle.
Ik gebruik meestal Nieuwe sleutels bij elke vernieuwing om de crypto-standaarden up-to-date te houden. Voor ECDSA gebruik ik bijvoorbeeld een curve zoals prime256v1; voor RSA kies ik minimaal 2048 bits. Het CSR bevat altijd alle hostnamen die ik wil beveiligen - inclusief Basisdomein en www (bijvoorbeeld example.tld en www.example.tld). Ik plan de installatie zo dat het nieuwe certificaat klaar is voordat het oude verloopt; veel servers staan dit toe Naadloze vervanging met een reload zonder downtime.
Na de installatie test ik de levering zowel met www als zonder www, via IPv4 en IPv6en controleer de volledige keten. Als de keten niet correct is, importeer ik het juiste tussenproduct van de CA. Ik zorg ervoor dat de server alleen herladen (configuratie opnieuw laden), niet hard herstarten zodat actieve verbindingen niet worden geannuleerd.
Serverpraktijk: Apache, Nginx en IIS in een oogopslag
Met Apache Ik sla de paden op in de vHost: SSLCertificateFile (servercertificaat), SSLCertificateKeyFile (privésleutel) en - afhankelijk van de versie - SSLCertificateChainFile of een gebundeld full-chain bestand. Na de uitwisseling controleer ik de configuratie en laad deze opnieuw. Voor Nginx Ik stel ssl_certificate (volledige keten) en ssl_certificate_key (sleutel) in. Ik test de configuratie, laad deze opnieuw en controleer vervolgens HTTP/2/HTTP/3 en SNI-afhandeling via verschillende servernamen.
Op IIS Ik importeer het certificaat in de certificate store (computer) en bind het aan de site. Het is belangrijk dat voor elke hostnaam SNI als er meerdere certificaten op hetzelfde IP draaien. Voor geautomatiseerde Windows-instellingen plan ik een ACME-client in om het vernieuwen en binden af te handelen. In alle gevallen documenteer ik de paden, de bestandsrechten (alleen voor het webserverproces) en de exacte procedure zodat de volgende vernieuwingsdatum soepel verloopt.
SSL in WordPress: instellen, afdwingen, automatisch uitbreiden
Met WordPress houd ik het eenvoudigIk activeer Let's Encrypt in de hosting, dwing HTTPS af via een plugin (bijv. Really Simple SSL) en controleer de widgets voor gemengde inhoud. Als WordPress op zijn eigen server draait, gebruik ik Certbot inclusief een cronjob voor automatische vernieuwing. In multisite setups is een wildcard certificaat de moeite waard om subdomeinen gezamenlijk te beveiligen. Ik gebruik deze tutorial voor een snelle start: Gratis SSL in WordPress. Ik controleer dan het slotsymbool in de browser en de vervaldatum van het certificaat in de WordPress tools.
Na het overschakelen vervang ik harde http-links in de database zodat afbeeldingen, scripts en stijlen netjes laden via HTTPS. Ik controleer ook cachingplugins en CDN-integraties om er zeker van te zijn dat ze de HTTPS-variant correct afhandelen. Belangrijk: Bij het forceren van HTTPS let ik op schone redirects (een 301-keten) zodat SEO-signalen niet verwateren en er geen eindeloze loops ontstaan.
Op mijn eigen servers ben ik van plan om de Certbot-Renewal te gebruiken als Cronjob en post hooks opslaan die Nginx/Apache herladen na een succesvolle vernieuwing. In beheerde WordPress-omgevingen gebruik ik de auto-renew functies van de hoster en controleer ik regelmatig of de .well-known uitdagingen toegankelijk zijn - vooral wanneer beveiligingsplugins of WAF-regels strikt worden gehandhaafd.
Typische fouten vermijden: Validatie, keten, omleidingen
Vaak is de Validatieals het HTTP-01-bestand onder /.well-known/pki-validation/ niet toegankelijk is. Voor de vernieuwing deactiveer ik even agressieve redirects (bijvoorbeeld van non-www naar www) of regels die de toegang blokkeren. Als er tussenliggende certificaten ontbreken, weigeren browsers het certificaat; ik importeer de volledige keten. Als er meerdere certificaten op één IP staan, moet SNI actief zijn, anders levert de server het verkeerde certificaat. Ik verwijder caches na elke wijziging zodat ik de echte, huidige status kan zien.
Andere typische struikelgevaren: A AAAA record (IPv6) naar een andere server wijst dan A (IPv4), mislukt de uitdaging. Of de WAF blokkeert de toegang tot .well-known. Met DNS-01 veroorzaken hoge TTL's vertragingen; ik stel ze tijdelijk lager in. Bestaan CAA-gegevens zonder goedkeuring voor de gebruikte CA, annuleer ik de verlenging totdat de invoer is gecorrigeerd. In container- of chroot-omgevingen let ik op de juiste mounts en permissies, zodat de webserver of ACME-client de uitdagingsbestanden daadwerkelijk kan afleveren.
Hostingvergelijking: Wie vernieuwt het betrouwbaarst?
Ik let op een Intuïtief interface, automatische verlenging voor alle domeinen en snelle ondersteuning. Dit bespaart me onderhoudstijd en vermindert de downtime aanzienlijk. Voor providers met Let's Encrypt-integratie stel ik de optie voor automatische verlenging eenmalig in en controleer ik de toegankelijkheid via HTTPS-monitoring. Er zijn duidelijke instructies voor All-Inkl waardoor de activering heel snel gaat: Let's Encrypt bij All-Inkl. De volgende tabel laat zien waar ik bijzonder belang aan hecht in de vergelijking.
| Hostingprovider | Automatische verlenging | Oppervlak | Steun | Waardering |
|---|---|---|---|---|
| webhoster.de | Ja | Zeer intuïtief | Snel | 1e plaats |
| All-Inkl | Ja | Eenvoudig | Goed | 2e plaats |
| Gastheer Europa | Gedeeltelijk | Medium | Medium | 3e plaats |
| SSD webhosting | Gedeeltelijk | Medium | Medium | 4e plaats |
Ik controleer ook of de provider DNS API's voor DNS-01 (belangrijk voor wildcards), geeft inzicht in het logboek voor mislukte validaties en of certificaten handig kunnen worden geëxporteerd als een volledige keten. Een goed paneel toont Verlopen certificaten Het systeem begint in een vroeg stadium, staat granulaire rechten toe (bijvoorbeeld alleen SSL-beheer) en documenteert elke stap. Dit bespaart tijd en voorkomt dat kennis aan individuele personen wordt gebonden.
Processen herkennen en proactief voorkomen
Ik kan de status op elk moment zien via de Kasteel-icoon in de browser, de details van het certificaat geven informatie over de geldigheid en de uitgever. Ik stel ook meldingen in het hostingpaneel in en stel monitoring in die waarschuwt als het certificaat verloopt. Mijn eigen servers krijgen een cron job die Certbot regelmatig uitvoert en logs controleert. In WordPress houd ik mezelf op de hoogte van meldingen van de beveiligingsplugins en controleer ik de console op gemengde inhoud. Deze combinatie voorkomt downtime en houdt de versleuteling ononderbroken actief.
Voor de Technische controle Ik gebruik eenvoudige controles: Het ophalen van de vervaldata van certificaten, het controleren van de keten en protocolondersteuning (TLS 1.2/1.3). Bij het monitoren plan ik waarschuwingsniveaus (bijvoorbeeld 30, 14 en 7 dagen voor de vervaldatum) en controleer ik of herlaadhaken echt zijn geactiveerd na een succesvolle verlenging. Hierdoor kan ik problemen in een vroeg stadium herkennen - voordat bezoekers waarschuwingspagina's te zien krijgen.
Veiligheidstuning na de vernieuwing
Na de verlenging haal ik het maximale uit TLS en activeer ik TLS 1.3 (in aanvulling op 1.2), deactiveer oude protocollen en verouderde cijfers. HSTS met een voldoende lange max-age bindt clients aan HTTPS en verkleint het aanvalsoppervlak. OCSP stapling vermindert latenties en ontlast de OCSP responder van de CA. Als je RSA gebruikt, kies dan 2048 bit of schakel indien nodig over op ECDSA voor betere prestaties. Aan het eind valideer ik de setup met een SSL-test en neem ik de protocollen en cryptografische instellingen onder de loep.
Ik geef de voorkeur aan modern cijfer met Forward Secrecy en activeer ALPN zodat HTTP/2 en HTTP/3 efficiënt worden gebruikt. Indien beschikbaar, stel ik parallel ECDSA- en RSA-certificaten Op deze manier krijgen moderne clients de krachtige ECDSA-variant, terwijl oudere clients compatibel blijven via RSA. Ik verhoog HSTS geleidelijk (bijv. eerst dagen, dan weken) om te voorkomen dat verkeerde configuraties permanent worden vastgezet. Ik controleer OCSP stapling actief na het herladen zodat clients geen extra netwerklatenties hebben.
Praktische procedure in het kort
Ik begin met een statuscontrole, maak een notitie van de Vervaldatum en beslis: automatisch verlengen actief laten of handmatig verlengen. Voor automatisch vernieuwen controleer ik het validatiepad (HTTP-01/DNS-01) en test ik de toegankelijkheid van de uitdaging. Voor handmatige verlenging maak ik het CSR aan, vraag het certificaat aan bij de certificeringsinstantie en installeer het certificaat plus keten. Vervolgens dwing ik HTTPS af, verwijder ik caches en controleer ik gemengde inhoud. Tot slot stel ik monitoring en notificaties in zodat ik nooit meer een deadline mis.
Speciale gevallen: Wildcard, multi-domein en validatietypes
Als ik veel subdomeinen beheer, gebruik ik een Wildcard-certificaat (*.domein.tld) en bespaar mezelf aparte certificaten. Voor meerdere compleet verschillende domeinen vertrouw ik op SAN/UCC certificaten die meerdere hostnamen samenvatten. DV-certificaten zijn voldoende voor de meeste projecten, OV/EV bieden extra identiteitsverificatie - handig voor winkels of portals met gevoelige gegevens. Ik let op de runtime-limieten en plan de vernieuwing zo dat er geen doorsnijding is tijdens piekoperaties. Voor DNS-validatie op productieve zones werk ik met duidelijke naamgevingsconventies zodat ik entries snel terug kan vinden en Verander kan.
Op Wildcard is belangrijk: Validatie wordt uitsluitend uitgevoerd via DNS-01, dus ik gebruik geautomatiseerde DNS-updates of speciale onderhoudsvensters. In omgevingen met meerdere domeinen zorg ik ervoor dat alle varianten in de SAN-lijst staan (inclusief subdomeinen die in de loop van het jaar zijn toegevoegd). Voor loadbalancer-opstellingen plan ik de Distributie van de nieuwe certificaten naar alle knooppunten en test dan elke VIP/regio apart. Met wisselende teams helpt het om duidelijke documentatie te hebben over wie welke geheimen (sleutels) ontvangt en wanneer, en hoe ze veilig worden opgeslagen.
ACME en complexe omgevingen: CDN, WAF en reverse proxies
Gebruik ik CDN of een WAF, zorg ik ervoor dat de validatie de Origin bereikt: of ik laat de challenge requests beantwoorden bij de Edge (indien ondersteund) of ik voer gerichte bypasses uit voor /.bekend/ aan. Voor HTTP-01 kan er een omleiding naar HTTPS zijn, maar de uitdaging moet toegankelijk zijn zonder auth-headers, snelheidslimieten of geo-blocks. Voor DNS-01 test ik of de TXT entry wereldwijd beschikbaar is en of er geen split horizon configuratie is die de evaluatie verstoort.
Achter Omgekeerde proxy's Ik controleer de headers verder terug (X-Forwarded-Proto) zodat de applicatie correct reageert op HTTPS en geen mixed-content fouten genereert. Voor zero-downtime vernieuwingen rol ik certificaten stap voor stap eerst één knoop, dan de andere - zodat ik snel terug kan gaan in geval van problemen zonder alle verbindingen op het spel te zetten.
Noodplan: annulering, sleutelverlies en snelle vervanging
Als er een Key-Leak of een compromis, trek ik het certificaat onmiddellijk in en geef ik een nieuw certificaat uit met nieuwe sleutels. Ik bewaar een Checklist klaar: Toegang tot het CA-portaal, intrekkingsprocedure, genereren van nieuwe sleutels, snelle distributie en herladen. Vervolgens controleer ik OCSP-nietjes en caches om oude ketens uit de caches te verwijderen. Ik noteer de oorzaak, tijd en tegenmaatregelen in de documentatie - dit maakt audits eenvoudiger en voorkomt herhaling.
Kort samengevat
Ik vernieuw certificaten op tijd, controleer de Automatisch vernieuwen-functie en houd de validatie toegankelijk. Waar automatisch vernieuwen niet werkt, vernieuw ik handmatig: CSR genereren, toepassen, keten installeren, HTTPS testen. Ik beveilig WordPress met afgedwongen HTTPS en monitoring, mijn eigen servers worden gecontroleerd door cronjobs en Certbot. Ik voorkom fouten door de .well-known challenge, intermediate certificaten, SNI en forwarding rules in de gaten te houden. Met dit proces blijft de encryptie actief, vertrouwen gebruikers de site en heeft de zichtbaarheid geen last van vervalwaarschuwingen.
