Inventariseer hostnamen, afhankelijkheden en eigenaarschap
Noteer elke hostnaam die bezoekers of integraties gebruiken: apex, www, subdomeinen, API’s, asset-hosts, portals en regionale namen. Leg voor elk vast waar TLS wordt beëindigd, wie het kan aanpassen, certificaatdekking en vervaldatum, vernieuwingsmethode en afhankelijkheden die URL’s genereren. Een certificaat moet de gevraagde hostnaam dekken in de Subject Alternative Name-lijst. Neem de CMS, CDN, tagmanager, objectopslag, betalingsprovider, e-mailsjablonen en externe embeds op; deze introduceren vaak HTTP-URL’s na de eerste HTTPS-uitrol.
Selecteer een canonieke www- of apex-hostnaam en stuur het alternatief direct via HTTPS naar die canonieke naam.
Deploy het certificaat en geldende TLS-versies
Configureer de webserver, reverse proxy, CDN of load balancer die het publieke verzoek beantwoordt. Installeer het certificaat en de vereiste keten, koppel ze aan de bedoelde namen en verifieer ze van buiten het hostingnetwerk. De browser controleert de keten, hostnaam en datums; een publieke waarschuwing is een release-blocker. Stel standaard in op TLS 1.3 en behoud TLS 1.2 alleen waar compatibiliteit dit vereist. Schakel SSL en TLS 1.0 en 1.1 uit. Gebruik onderhouden platformrichtlijnen in plaats van een gekopieerde verouderde cipherlijst en houd de server en TLS-bibliotheek gepatcht.
Beperk toegang tot private keys en registreer elk systeem dat er één deelt zodat vervanging alle systemen bereikt.
Redirect HTTP één keer en maak HTTPS canoniek
Stuur een server-side permanente redirect, gewoonlijk 301 of 308, van elke HTTP-URL naar de equivalente HTTPS-URL. Vermijd chains: die voegen vertraging en meer faalpunten toe. Publiceer canonieke HTTPS-URL’s in interne links, canonical-tags, sitemaps, gestructureerde data, social tags, e-mails en applicatiegegenereerde absolute links. Test de startpagina, een diepe pagina, een query-URL, foutroutes en hostnaamvarianten. Wanneer TLS eindigt bij een proxy, configureer dan de verwerking van vertrouwde forwarded-protocolheaders zodat de applicatie niet blijft rondcirkelen tussen HTTP en HTTPS.
Het kan alleen beschikbaar blijven om te redirecten of om een certificaatchallenge te voltooien, niet om een aparte publieke site te bedienen.
Vind en repareer mixed content bij de bron
Mixed content is een HTTPS-pagina die een bron via HTTP of een ander onveilig protocol opvraagt. Browsers kunnen sommige media upgraden, maar blokkeren veel risicovolle verzoeken, inclusief scripts, stylesheets, frames, fetch-aanroepen en fonts. Vervang elke verwijzing door een geteste HTTPS-URL, een relatieve URL voor eigen content of een goedgekeurd alternatief. Doorzoek representatieve templates en inspecteer developer tools terwijl je belangrijke gebruikersreizen voltooit. Controleer CSS, JavaScript, CMS-blokken, asset-manifesten, tag-manager entries, downloads en vendor-embeds. Een veilige pagina mag geen HTTP-download aanbieden.
Automatische browserupgrades kunnen nog steeds een onbeschikbare of niet-ondersteunde derde partij achterlaten; corrigeer de opgeslagen URL.
Automatiseer vernieuwing en oefen certificaatherstel
Behandel vernieuwing als een geautomatiseerde deployment, niet als een kalenderherinnering. Het moet vernieuwen, naar elke serverlaag worden uitgerold en de service veilig herladen. Test dezelfde validatieroute vóór productieverval. Let’s Encrypt, bijvoorbeeld, raadt aan hun 90-dagen certificaten elke 60 dagen te vernieuwen; volg de lifecycle voor jouw issuer en platform. Bewaar certificaatnamen, issuer-account, challengemethode, automatisering, sleutel-locatie, doelwitten en noodcontacten in een inventaris. Verifieer datums vanaf het publieke eindpunt na deployment.
Bij een mislukte vernieuwing, controleer DNS, challenge-routing, permissies, issuer-toegang, rate limits en CDN-naar-origin deployment.
Gebruik HSTS alleen wanneer het HTTPS-landschap klaar is
Voeg HSTS pas toe nadat elke hostnaam die door het beleid wordt gedekt, betrouwbaar via HTTPS bereikbaar is en een geldig certificaat heeft. Met de Strict-Transport-Security-header vertelt een HTTPS-respons browsers om die hostnaam gedurende de opgegeven `max-age` alleen via HTTPS te bezoeken; bij certificaatfouten kunnen gebruikers niet doorklikken. Begin met een beperkte `max-age`, controleer of alle subdomeinen veilig HTTPS ondersteunen voordat je `includeSubDomains` gebruikt, en beoordeel preload afzonderlijk. Een browser kan HSTS pas verwijderen nadat hij een geldige HTTPS-respons met `max-age=0` heeft ontvangen.
max-age=0 werkt alleen nadat een browser een geldige HTTPS-respons heeft bereikt; het kan een onbereikbare secure host niet repareren.
Rol uit, test en rol terug zonder het transport te verzwakken
Leg de bekende-goede certificaat-, edge- en redirectconfiguratie vast vóór de wijziging. Definieer wie een rollback goedkeurt, voer waar mogelijk gefaseerd uit en wijzig één controleklasse tegelijk. Controleer direct de publieke eindpunten vanaf meer dan één netwerk, volg redirects, inspecteer het certificaat en voltooi belangrijke bezoekersacties. Test browsers en cliëntgroepen die voor je publiek relevant zijn. Raadpleeg voor betalings- of gereguleerde flows de betalingsprovider en een gekwalificeerde beveiligingsspecialist over de vereiste controles. Als een wijziging HTTPS breekt, herstel dan een gevalideerde veilige configuratie; gebruik geen HTTP-klantpagina’s als noodoplossing.
Leg hostnaam, tijd, client, fout, wijziging en resultaat vast zodat de volgende vernieuwing of migratie makkelijker te diagnosticeren is.