Hoe SSL/TLS-certificaten werken
Kort antwoord
Een TLS-certificaat bewijst de identiteit van een server aan een verbindende client en maakt versleutelde communicatie tussen beide mogelijk. Het wordt vertrouwd omdat het is ondertekend door een Certificate Authority waarvan het eigen certificaat al vertrouwd wordt door browsers en besturingssystemen, wat een keten van vertrouwen vormt tot aan een vertrouwde root. Een self-signed certificaat versleutelt de verbinding net zo goed, maar doorbreekt die keten van vertrouwen. Daarom waarschuwen browsers ervoor.
Wat een certificaat precies doet
Een TLS-certificaat doet twee dingen tegelijk. Het bewijst identiteit: het certificaat geeft aan bij welk domein het hoort, en de bijbehorende private key is alleen in handen van de legitieme server. Zo kan een client die verbinding maakt met dat domein erop vertrouwen dat hij écht met de juiste server praat, en niet met iets dat zich voordoet als die server. En het maakt versleuteling mogelijk: het certificaat bevat de publieke helft van een sleutelpaar dat wordt gebruikt om een versleutelde verbinding op te zetten, zodat alles wat daarna wordt uitgewisseld onleesbaar is voor wie het verkeer onderweg onderschept.
Beide zaken zijn nodig, samen. Versleuteling zonder identiteitscontrole zou afluisteren tegenhouden, maar niet imitatie, want iedereen kan een sleutelpaar genereren en een verbinding versleutelen terwijl hij zich toch voordoet als iemand anders. Het identiteitsbewijs is wat dat gat dicht.
De keten van vertrouwen
Dat een certificaat claimt een bepaald domein te vertegenwoordigen, wordt niet zomaar op zijn woord aangenomen. Het wordt ondersteund door een handtekening van een Certificate Authority (CA), een organisatie die heeft geverifieerd dat de aanvrager van het certificaat daadwerkelijk zeggenschap heeft over dat domein, voordat ze het ondertekende. Het eigen certificaat van de CA is op zijn beurt een certificaat dat browsers en besturingssystemen standaard al vertrouwen, als onderdeel van een ingebouwde lijst met vertrouwde rootcertificaten. Vaak zit er een intermediate certificate tussen de root en het certificaat van je server, zodat de volledige keten loopt van jouw certificaat, via een of meer intermediates, naar een root die al standaard wordt vertrouwd.
Wanneer een browser verbinding maakt met een server, controleert hij deze hele keten: is het certificaat van de server geldig ondertekend door het intermediate certificaat, is dat intermediate certificate geldig ondertekend door een vertrouwde root, en komt het domein in het certificaat overeen met het domein dat wordt bezocht. Klopt elke schakel, dan gaat de verbinding door zonder waarschuwing. Ontbreekt een schakel, is die verlopen, of komt hij niet overeen, dan geeft de browser een waarschuwing.
Self-signed versus door een CA uitgegeven certificaten
Bij een self-signed certificaat ondertekent de server zijn eigen certificaat, in plaats van dat een CA dat doet. Technisch gezien maakt het net zo goed versleuteling mogelijk als een door een CA uitgegeven certificaat. Wat het niet biedt, is het identiteitsbewijs: er is geen onafhankelijke partij die garandeert dat het certificaat daadwerkelijk toebehoort aan wie het claimt te zijn, dus sluit niets in de keten aan op een vertrouwde root. Browsers reageren daarop door de bezoeker te waarschuwen in plaats van stilzwijgend verbinding te maken.
Dat maakt self-signed certificaten een redelijke keuze voor interne tools, lokale ontwikkeling of testen: situaties waarin je de server al kent en vertrouwt en de waarschuwing gewoon ruis is. Het is geen redelijke keuze voor iets dat publiek toegankelijk is, waar bezoekers geen onafhankelijke manier hebben om te weten of de server waarmee ze verbonden zijn echt is. En jezelf trainen om een beveiligingswaarschuwing weg te klikken, is precies de gewoonte die phishingsites laat werken.
Kortere geldigheidsduur van certificaten en automatische vernieuwing
De geldigheidsduur van certificaten krimpt al jaren, branchebreed: van de meerjarige certificaten die vroeger gebruikelijk waren, naar periodes die in maanden worden gemeten. Een kortere geldigheidsduur beperkt hoelang een gecompromitteerd of ten onrechte uitgegeven certificaat geldig blijft voordat het vernieuwd moet worden, en zorgt ervoor dat het vernieuwingsproces regelmatig echt wordt doorlopen, in plaats van iets waar jarenlang niemand naar omkijkt totdat het ertoe doet.
Het praktische gevolg is dat een certificaat handmatig vernieuwen, elk jaar of twee jaar, werkbaar was toen certificaten lang geldig waren, maar niet opschaalt naar een geldigheidsduur die in weken of maanden wordt gemeten. Daarom is geautomatiseerde uitgifte en vernieuwing, via het ACME-protocol waar diensten als Let's Encrypt op zijn gebouwd, de standaardaanpak geworden in plaats van een optioneel gemak. Een ACME-client op de server (of ervoor) vraagt een certificaat aan, bewijst automatisch controle over het domein, en vernieuwt het certificaat ruim voor het verloopt, zonder dat iemand het handmatig hoeft te onthouden.