Woordenlijst · Domeinen, DNS, e-mail en certificaten
De TLS-handshake is de uitwisseling aan het begin van een HTTPS-verbinding waarin client en server een TLS-versie en cipher afspreken, de server zijn identiteit bewijst met zijn certificaat, en beide de sleutels afleiden die de rest van de verbinding versleutelen.
In TLS 1.3 stuurt de client een ClientHello met de naam van de site (SNI), de ciphers die hij ondersteunt en een key share. De server antwoordt met zijn keuze, zijn certificaat en een handtekening, en de client controleert de certificaatketen, de naam en de data. Dat kost één round trip; TLS 1.2 heeft er twee nodig.
De handshake is een eigen onderdeel van de responstijd: ongeveer één round trip aan latency plus het werk van de server. Hergebruikte verbindingen en session resumption slaan het grootste deel over; daarom ziet een monitor die voor elke controle een nieuwe verbinding opent meer TLS-tijd dan een browser op zijn tweede pagina.
Handshakes mislukken om een paar redenen: een verlopen of verkeerd certificaat, een ontbrekend tussencertificaat, geen certificaat voor de gevraagde naam, een server die alleen oude versies aanbiedt (TLS 1.0 en 1.1 zijn uitgefaseerd door RFC 8996), of een poort die in gewone HTTP antwoordt. Browsers tonen dit als beveiligingsfouten; voor monitoring is het downtime.
TLS-tijd ≈ round trips × round-trip time + serververwerking
Voorbeeld: Met 30 ms naar de server duurt een TLS 1.3-handshake ongeveer 30 ms plus het werk van de server, en een TLS 1.2-handshake ongeveer 60 ms.
Elke HTTPS-check in Uptimecheck opent een nieuwe verbinding en bevat dus een volledige handshake, en responstijden tonen de TLS-handshake als eigen fase naast DNS, connect, server en download. De checkdetails tonen de TLS-versie en de naam en uitgever van het certificaat. Als een handshake mislukt, zegt het incident wat dat waarschijnlijk betekent: geen certificaat voor de naam, alleen oude TLS-versies of ciphers, gewoon HTTP op de HTTPS-poort, een niet-vertrouwde of onvolledige keten, of een handshake die niet vóór de timeout klaar was.
14 dagen gratis proberen · Daarna gratis met 5 monitors · Geen creditcard
Guides 7 min. leestijd
NET::ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID en de andere SSL-waarschuwingen in de browser uitgelegd: wat ze betekenen, waardoor ze ontstaan en hoe je ze op je server oplost.
LezenMonitoring 7 min. leestijd
Responstijd is hoe lang je server nodig heeft om een verzoek te beantwoorden, niet hoe lang de pagina laadt. Wat goed is, waarom monitors en browsers anders meten en wat sites vertraagt.
LezenGuides 6 min. leestijd
Publieke TLS-certificaten zijn sinds 15 maart 2026 maximaal 200 dagen geldig, daarna 100 en 47 dagen. Het tijdschema, wat er verandert aan domeinvalidatie en een checklist om je voor te bereiden.
LezenOngeveer één round trip voor TLS 1.3 en twee voor TLS 1.2, plus de verwerking door de server: vaak 20 tot 100 ms naar een server in dezelfde regio. Veel meer wijst op een trage of verre server, of op een certificaatketen die de client zelf moet aanvullen.
Server Name Indication: de client noemt in zijn eerste handshakebericht de site die hij wil, zodat één IP-adres veel sites met verschillende certificaten kan bedienen. Zonder overeenkomende naam kan de server de handshake weigeren.
Meestal een verlopen, verkeerd of onvolledig certificaat, een server die alleen TLS-versies of ciphers aanbiedt die de client weigert, of een proxy of firewall die de verbinding verbreekt. Een SSL-checker laat zien welk deel faalt.
Stel je eerste monitor in binnen een minuut, of kijk eerst rond in de live demo.
14 dagen gratis proberen · Daarna gratis met 5 monitors · Geen creditcard
Met jouw toestemming laten Google Analytics en Microsoft Clarity ons zien welke pagina’s helpen en waar bezoekers vastlopen. Ze plaatsen cookies voor maximaal 13 maanden. Zonder jouw toestemming draait geen van beide. Je kunt je keuze altijd wijzigen via Cookie-instellingen onderaan de pagina. Privacybeleid