Begin met namen en verbindingsgrenzen
Inventariseer adressen die een beveiligde verbinding nodig hebben: hoofddomein, www, account- of betaalsubdomeinen en beheerdiensten. Leg vast wie hostname, DNS-zone en server beheert. Het certificaat moet de aangevraagde naam dekken voordat een HTTPS-doorverwijzing werkt. Een redirect vervangt geen passend certificaat op het ingangspunt.
Een publiek certificaat bevat informatie die clients mogen inspecteren. De bijbehorende privésleutel bewijst bezit tijdens de verbinding en vraagt gecontroleerde opslag. Verwar deze niet met de accountsleutel van een automatische certificaatclient. Documenteer eigenaarschap en vervanging, zodat een ontwikkelaarswissel of hostingverhuizing geen onbeheerde afhankelijkheid achterlaat.
Hoe domeinvalidatie in het proces past
De certificaatautoriteit verlangt bewijs van controle over het domein. Automatische clients kunnen afhankelijk van dienst en namen een webbron of DNS-record gebruiken. Bij HTTP-01 moet het controlebestand op de vereiste plek bereikbaar zijn. Een firewall, verkeerde routering of uiteenlopende antwoorden van meerdere servers kan de controle laten mislukken.
DNS-01 bewijst controle met een specifiek DNS-record en ondersteunt wildcardnamen. Hiervoor zijn mogelijk beperkte API-rechten en wachttijd nodig totdat records zichtbaar worden. Volledige DNS-accountgegevens op de webserver vergroten de gevolgen van een besmetting. Kies een ondersteunde validatie met beperkte rechten in plaats van een volledig beheertoken naar de configuratie te kopiëren.
Kies dekking bewust en begrijp wildcards
Een certificaat kan meerdere expliciete namen bevatten. Een wildcard zoals *.example.com betreft een bepaald niveau subdomeinen. Neem niet aan dat deze ook example.com of iedere dieper gelegen naam dekt. Lees de echte namenlijst. Validatie en installatie van een wildcard kunnen afwijken van het standaard automatische hostingcertificaat.
De passende keuze volgt uit sitestructuur en verantwoordelijkheid voor verlenging. Een kleine website kan enkele namen nodig hebben; een verspreide toepassing vraagt gecoördineerde eindpunten. Namen uit voorzorg toevoegen kan onafhankelijke teams aan één verlengingsproces koppelen. Een beheersbare inventaris met duidelijk doel is nuttiger dan de grootst mogelijke dekking.
Installeer waar TLS werkelijk eindigt
De browser kan verbinden met een CDN, reverse proxy of load balancer in plaats van de server waarop het CMS staat. Die publieke component presenteert het bezoekerscertificaat. Een aparte beschermde verbinding naar de oorspronkelijke server kan een ander certificaat en vertrouwen gebruiken. Controleer beide grenzen wanneer ze bestaan; één veilige schakel configureert de andere niet automatisch.
Controleer na installatie het publiek geleverde certificaat, de namen, geldigheid en vereiste volledige keten. Een bestand op schijf of groen schakelaartje bewijst niet dat het actieve proces is vernieuwd. Als meerdere eindpunten dezelfde naam beantwoorden, moet installatie worden afgestemd om te voorkomen dat bezoekers soms nog een oud certificaat ontvangen.
Maak verlenging tot herhaalbaar onderhoud
Verlenging moet toegang tot validatie behouden, een nieuw certificaat verkrijgen en dit actief beschikbaar maken. Wijzigingen in DNS, firewall, toegang of hosting kunnen een eerder werkend proces breken. Gebruik ondersteunde verlengingscontroles en stuur meldingen naar een onderhouden beheercontact, niet naar het privéaccount van een voormalige opdrachtnemer.
Volg actuele looptijden en clientadviezen van de uitgever; certificaatduur en beleid kunnen veranderen. Bewaak het certificaat dat publieke clients zien ruim vóór verval. Houd logboeken bruikbaar zonder tokens of privésleutels bloot te stellen. Automatisering vraagt aantoonbaar succes en een bekende reactie op fouten, ook als dagelijkse tussenkomst niet nodig is.
Voorbeeld: lokaal verlengd, publiek verlopen
Een automatische client verlengt het certificaat van de oorspronkelijke server, maar de publieke proxy bewaart de oude kopie. De beheerder ziet een geslaagde verlenging terwijl klanten een vervalwaarschuwing krijgen. Uitgifte werkte; installatie op het juiste TLS-eindpunt niet. Domeinvalidatie herhalen herstelt dat specifieke probleem waarschijnlijk niet.
Bepaal het certificaat op ieder relevant eindpunt en hoe nieuw materiaal de actieve dienst bereikt. Pas de ondersteunde installatie- of herlaadprocedure toe en controleer daarna de publieke hostname. Bewaar waar passend de oude configuratie voor een bevoegde terugdraaiing. Dit fictieve voorbeeld maakt duidelijk dat het verlengingstijdstip en het publieke vervaldatum verschillende bewijzen zijn.
- Noteer de falende hostname en het publiek aangeboden certificaat.
- Vergelijk verantwoordelijkheden van publieke component en oorspronkelijke server.
- Herstel validatie, installatie of herladen en controleer de daadwerkelijke openbare verbinding.
Voltooi HTTPS zonder overhaaste beleidswijziging
Werk links en bronnen bij naar de gewenste HTTPS-adressen en controleer gemengde inhoud. Redirects en canonieke metadata moeten bij de gekozen publieke URL passen. HSTS verplicht browsers HTTPS te gebruiken en versterkt toekomstige verbindingen, maar verwijdert normale mogelijkheden om certificaatfouten te omzeilen. Uitbreiding naar alle subdomeinen vereist kennis van hun gereedheid.
Voer geen breed HSTS- of preloadbeleid in uitsluitend voor een beveiligingsscore. Zorg eerst voor betrouwbare HTTPS en verlenging, bekijk afhankelijke subdomeinen en actuele implementatie-eisen. Certificaatbeheer beschermt de transportidentiteit; toegangsrechten, applicatie-updates, back-ups en passende gegevensverwerking houden eigen verantwoordelijkheden en controles.
Vragen over dit begrip
Kan ik een TLS-certificaat kopiëren zonder de privésleutel te kopiëren?
Een server die moet bewijzen dat hij de gecertificeerde sleutel bezit, heeft via zijn ondersteunde inzetmethode toegang nodig tot de bijbehorende privésleutel, en het openbare certificaat alleen kan dat bewijs niet leveren. Beheerde platforms houden de sleutel mogelijk binnen hun eigen systemen, zodat handmatig kopiëren onnodig is. Zie sleuteloverdracht als een gecontroleerde operationele stap en publiceer hem nooit samen met websitebestanden of in screenshots voor ondersteuning.
Waarom mislukt automatische vernieuwing na een hostingverhuizing?
Vernieuwing hangt af van het bestaande validatie- en inzetpad. Een verhuizing kan DNS-doelen, challenge-routering, firewalltoegang, DNS-API-inloggegevens of het onderdeel dat TLS levert veranderen, en een oude client kan nog gewoon succesvol tegen de oude omgeving draaien. Breng het nieuwe openbare eindpunt in kaart, bepaal de ondersteunde validatie en controleer het live certificaat in plaats van te vertrouwen op het vernieuwingsschema van de vorige aanbieder.
Dekt een wildcardcertificaat elk adres?
Nee. De dekking volgt de specifieke namen en het wildcardniveau in het certificaat. Een wildcard voor *.example.com dekt op zichzelf niet example.com of willekeurig diepere namen, al kan een certificaat extra namen apart bevatten. Controleer de exacte inventaris en de validatiemethode van uw uitgever voordat u uitrolt, in plaats van aan te nemen dat het woord “wildcard” onbeperkte dekking betekent.
Kan ik HTTPS repareren door een redirect toe te voegen?
Een redirect kan een HTTP-verzoek sturen of een canonieke hostnaam kiezen zodra een verbinding bestaat. Een HTTPS-verzoek heeft eerst een geldige TLS-verbinding nodig, inclusief dekking voor de gevraagde hostnaam, en als die controle faalt, krijgt de browser de redirect misschien nooit te zien. Richt certificaten in voor de benodigde HTTPS-toegangspunten en controleer daarna redirects en canonieke adressen als aparte stappen.
Is het installeren van een certificaat genoeg voor volledige websitebeveiliging?
Nee. Het dekt een belangrijk deel van verbindingsauthenticatie en transportbescherming, maar een website kan nog kwetsbare plug-ins, zwakke beheerderstoegang, onveilige bestandsuploads of verkeerd behandelde gegevens hebben. Houd applicatie-updates, rechten, back-ups en monitoring naast HTTPS op orde. Het item over het SSL-certificaat legt de grenzen van bezoekersvertrouwen uit, terwijl dit item zich richt op betrouwbaar technisch eigenaarschap van validatie, uitrol en vernieuwing.