Een SSL-certificaat verloopt ondanks automatische vernieuwing

Begin niet met herstellen, maar met meten. Open de site in een browser, bekijk de certificaatdetails en noteer drie gegevens: de einddatum, de uitgever en de hostnamen waarvoor het certificaat geldt. Doe dit voor de variant met en zonder www en voor elk subdomein dat klanten gebruiken, zoals een winkel- of boekingsomgeving.

Controleer daarna op een tweede apparaat en een ander netwerk. Een verkeerde systeemklok of een bedrijfsfirewall kan een waarschuwing veroorzaken terwijl het certificaat in orde is. Zo onderscheid je drie situaties: het certificaat is werkelijk verlopen, er bestaat al een nieuw certificaat maar de server toont nog het oude, of het certificaat dekt de gevraagde hostnaam niet.

Kijk ook buiten je hoofdpagina. MDN raadt aan om alle pagina's en subresources via HTTPS te serveren (MDN over webbeveiliging). Een afbeelding, script of formulier op een andere host kan dus een eigen certificaatprobleem hebben. Noteer elke externe host die je pagina's laden en controleer die apart.

Een automatische vernieuwing doorloopt vier schakels. Werk ze in volgorde af en stop bij de eerste die niet klopt.

1. Aanvraag gestart? Zoek in het beheerpaneel of de logs van je host of beheerder of er een vernieuwingstaak bestaat, of die actief is en wanneer ze voor het laatst draaide.
2. Validatie geslaagd? Veel systemen bewijzen eigenaarschap via een bestand op je site of een DNS-record. Een gewijzigde DNS-provider, een nieuwe redirect, een firewallregel of een verwijderd record kan dit laten mislukken.
3. Uitgegeven maar niet geïnstalleerd? Het nieuwe certificaat kan klaarstaan terwijl de webserver niet herladen is of een load balancer of CDN een eigen, ouder certificaat gebruikt.
4. Melding niet aangekomen? Controleer naar welk adres waarschuwingen gaan. Is dat de mailbox van iemand die vertrokken is, dan merkte niemand dat stap 1 tot 3 mislukten.

Welke schermen of logbestanden je daarvoor opent, hangt af van je dienstverlener. Vraag die zo nodig om de vernieuwingslog van de laatste poging.

Dit is een denkhulp, geen bewijs. Bevestig elke hypothese in de logs voordat je iets wijzigt.

Vernieuwingen mislukken ook doordat niemand nog in het juiste account geraakt. Denk aan het domein- of hostingaccount, de DNS-omgeving en de mailbox die meldingen ontvangt. MDN adviseert om bij authenticatie niet enkel op wachtwoorden te vertrouwen en noemt passkeys en eenmalige wachtwoorden als sterkere methodes. Extra verificatie verhoogt de beveiliging, maar kan in de praktijk een afhankelijkheid van één telefoon of persoon creëren. Dat is een eigen redactionele waarschuwing, geen uitspraak van MDN.

Gebruikt je team Google-accounts, dan beschrijft Google op de pagina over tweestapsverificatie twee belangrijke grenzen. Als je een telefoonnummer toevoegt voor tweestapsverificatie, kan het tot 7 dagen duren voordat Google dat nummer vertrouwt. Een vertrouwde toegangssleutel of beveiligingssleutel kan dat proces versnellen. Bij werk- of schoolaccounts werken de stappen mogelijk niet en moet de beheerder helpen. Plan wijzigingen aan herstelmethodes daarom ruim voor een einddatum, en regel vooraf wie de beheerder is. Zit je al in een acuut toegangsprobleem, neem dan meteen contact op met de beheerder.

Controleer per account: wie kan inloggen, welk herstelnummer of welke sleutel hoort erbij en wat gebeurt er als die persoon onbereikbaar is. Wie je kunt bereiken en welke instellingen er zijn, controleert je beheerder zelf in het account, want schermen kunnen wijzigen.

Een alarm dat enkel meldt dat de vernieuwingstaak gelukt is, bewijst niet dat bezoekers het nieuwe certificaat zien. Laat het alarm daarom de einddatum controleren van het certificaat dat elk publiek eindpunt (ook CDN of load balancer) van buiten werkelijk toont.

Fictief voorbeeld, enkel invoer: een webwinkel met drie hostnamen (hoofdadres, www en een afrekenomgeving). De einddatum van het huidige certificaat is 30 juni. Het alarm start 30, 14, 7 en 2 dagen voor die datum. De verantwoordelijke is een rol met naam en een vervanger, en de melding gaat naar een gedeelde mailbox. De verwachte technische controle na elke vernieuwing: alle drie de hostnamen tonen een nieuwe einddatum.

Zet dit op één overdrachtsblad:

• Hostnamen en waar het certificaat geïnstalleerd is (server, CDN, load balancer)
• Hoe validatie verloopt en waar het DNS-record of controlebestand staat
• Wie toegang heeft tot welk account en hoe herstel werkt
• Naar welk adres meldingen gaan en wie de vervanger is
• Welke externe hosts je pagina's laden

Na een herstel controleer je opnieuw wat je in de eerste sectie noteerde: nieuwe einddatum, juiste hostnamen, hoofdadres, www en subdomeinen, op minstens twee apparaten. Laat daarna de eerstvolgende geplande vernieuwing niet aan het toeval over. Vraag je dienstverlener of die een testvernieuwing ondersteunt, of plan een controle kort na de eerstvolgende poging.

Let op de grenzen van dit artikel. De geraadpleegde bronnen gaan over webbeveiliging in het algemeen en over tweestapsverificatie van een Google-account. Ze beschrijven geen vernieuwingsprocedure van certificaten, en je exacte oorzaak vind je enkel in je eigen logs. Een publieke scan ziet bovendien enkel wat van buitenaf zichtbaar is en bewijst geen volledige technische inrichting.

Wil je weten welke publieke signalen je site nu toont, bekijk ze dan via Marketing Scan. We beloven niet dat onze scan alle controles uit deze gids uitvoert.