Mutual TLS (mTLS): implementatiepatronen

Standaard-TLS authenticeert alleen de server bij de client via een certificaat. Wederzijdse TLS (mTLS) breidt dit uit: beide partijen presenteren en verifiëren certificaten. De client presenteert een clientcertificaat nadat de server hierom heeft gevraagd (via CertificateRequest in de TLS-handshake). De server verifieert het clientcertificaat aan de hand van een vertrouwde certificeringsinstantie. mTLS is de basis van zero-trustnetwerken: in plaats van te vertrouwen op beveiliging van de netwerkperimeter, authenticeren services elkaar cryptografisch bij elke verbinding. Service meshes zoals Istio, Linkerd en Consul Connect implementeren mTLS transparant tussen microservices.

De mTLS-handshake breidt TLS 1.3 als volgt uit: na ServerHello en het servercertificaat en Finished stuurt de server een CertificateRequest-bericht met de geaccepteerde certificeringsinstanties en handtekeningalgoritmen. De client antwoordt met zijn Certificate (de certificaatketen van de client) en CertificateVerify (een handtekening over het handshakeverloop met de privésleutel van de client). De server verifieert de certificaatketen van de client aan de hand van zijn opslag voor vertrouwde certificeringsinstanties en controleert de handtekening van CertificateVerify. Als beide controles slagen, is de verbinding wederzijds geauthenticeerd. De client kan geen geldige CertificateVerify maken zonder de privésleutel die bij het certificaat hoort.

In omgevingen met service meshes worden clientcertificaten meestal uitgegeven door een interne certificeringsinstantie. Istio gebruikt SPIFFE (Secure Production Identity Framework for Everyone) SVID's: elke workload krijgt een certificaat met een SPIFFE URI SAN (alternatieve onderwerpnaam), zoals spiffe://cluster.local/ns/default/sa/payment-service. Deze certificaten hebben een korte geldigheidsduur (24 uur) en worden automatisch geroteerd door het besturingsvlak van de mesh (istiod). Bij mTLS voor eindgebruikers (bijvoorbeeld bedrijfs-VPN's en API-clients) kunnen certificaten worden uitgegeven door een bedrijfs-CA met een langere levensduur en via MDM (beheer van mobiele apparaten) worden geleverd aan apparaten van medewerkers.

mTLS-verificatie aan de serverzijde bestaat uit verschillende stappen: (1) Ketenvalidatie — controleer dat het clientcertificaat teruggaat tot een vertrouwde root-CA in de opslag voor client-CA's van de server. (2) Controle van de geldigheidsperiode — zorg ervoor dat het certificaat niet verlopen is en al geldig is. (3) Intrekkingscontrole — controleer via OCSP of CRL of het certificaat niet is ingetrokken. (4) SAN/CN-overeenkomst — haal de identiteitsclaim uit de SAN van het certificaat (SPIFFE-URI, DNS-naam of e-mailadres). (5) Autorisatie — controleer of de geauthenticeerde identiteit toegang heeft tot de opgevraagde bron. Voor stappen 4 en 5 is logica op applicatieniveau nodig die verder gaat dan een basisconfiguratie van TLS.

Kortlevende certificaten maken expliciete intrekking overbodig: als een certificaat na 24 uur verloopt, blijft de impact van een compromittering beperkt tot een kort tijdsvenster. Voor rotatie is het volgende nodig: (1) Vooraf roteren — geef een nieuw certificaat uit voordat het oude verloopt (roteer bij 80% van de levensduur). (2) Wisselen zonder onderbreking — de service moet tijdens het overgangsvenster zowel oude als nieuwe certificaten accepteren. (3) Gecontroleerd herladen — de TLS-stack moet aanmeldingsgegevens opnieuw laden zonder bestaande verbindingen te verbreken (nginx: nginx -s reload; Envoy: dynamische xDS-certificaatupdate). SPIFFE Workload API (geïmplementeerd door SPIRE) automatiseert het leveren en roteren van certificaten via een API voor Unix-domeinsockets.

Istio implementeert mTLS transparant via Envoy-sidecar-proxy's die in elke pod worden geïnjecteerd. Het besturingsvlak (istiod) fungeert als CA met een tussenliggend certificaat dat is ondertekend door de hoofd-CA van het servicemesh. De sidecar van elke pod ontvangt via de SDS (Secret Discovery Service)-API een SPIFFE SVID. Met PeerAuthentication-beleidsregels configureer je de mTLS-modus: STRICT (mTLS vereist), PERMISSIVE (zowel mTLS als platte tekst toegestaan, voor migratie) of DISABLE. AuthorizationPolicy-resources bepalen welke diensten met elkaar mogen communiceren; dit wordt gecontroleerd aan de hand van de SPIFFE-identiteit in het clientcertificaat. Zo implementeer je zero trust binnen het cluster zonder wijzigingen in de applicatiecode.

Voor externe API-clients biedt mTLS sterkere authenticatie dan API-sleutels of OAuth-tokens. De client bewaart een privésleutel in beveiligde opslag (HSM, sleutelopslag van het besturingssysteem of een softwaresleutel met wachtwoordzin). Het clientcertificaat is vastgepind op de verwachte CA van het API-eindpunt. Elke API-aanvraag wordt op de TLS-laag geauthenticeerd — een afzonderlijke Authorization-header is niet nodig. Cloudflare API Shield, clientcertificaten van AWS API Gateway en mTLS voor serviceaccounts van Google Cloud implementeren allemaal dit model. Een gecompromitteerde API-sleutel kan overal vandaan worden gebruikt; voor een gecompromitteerde mTLS-privésleutel moet ook het apparaat waarop de client draait worden gestolen.

mTLS-implementaties brengen verschillende operationele uitdagingen met zich mee. (1) Certificaatdistributie — clientcertificaten veilig aan alle diensten leveren, vooral in dynamische omgevingen waarin pods op- en afgeschaald worden. (2) Compromittering van de CA — de interne CA is een doelwit met hoge waarde; als deze wordt gecompromitteerd, worden alle dienstcertificaten ongeldig. CA's met HSM-ondersteuning en offline hoofd-CA's beperken dit risico. (3) Foutopsporing — versleuteld mTLS-verkeer is ondoorzichtig voor standaardtools voor foutopsporing; observeerbaarheid van het servicemesh met Jaeger en Kiali is nodig. (4) Compatibiliteit met tussenliggende netwerkapparatuur — TLS-inspectieproxy's verbreken mTLS tenzij ze expliciet zijn geconfigureerd om clientcertificaten door te geven. (5) Incidenten door verlopen certificaten — een fout in de rotatie kan volledige dienstuitval veroorzaken.

SPIFFE (Secure Production Identity Framework for Everyone) definieert een standaard voor werklastidentiteit met X.509 SVID's. SPIRE (SPIFFE Runtime Environment) is de referentie-implementatie. SPIRE Server fungeert als registratieautoriteit en CA. SPIRE Agents draaien op elk knooppunt, attesteren de identiteit van werklasten met attestors voor knooppunten (AWS-instance-identiteit, Kubernetes-serviceaccount-JWT, TPM) en attestors voor werklasten (Unix-PID, metagegevens van de containeromgeving). De Workload API levert SVID's aan werklasten via een Unix-domeinsocket met een eenvoudige gRPC-API. SPIRE integreert met Envoy, Nginx en belangrijke servicemeshes als certificaatbron.

Voor mTLS-implementaties met hoge beveiliging horen privésleutels in Hardware Security Modules (HSM's) te staan in plaats van in softwarematige sleutelopslagen. De TLS-bibliotheek (OpenSSL, BoringSSL) laadt de privésleutel via de PKCS#11-interface, die ondertekeningsbewerkingen doorstuurt naar de HSM. De privésleutel verlaat de grens van de HSM nooit in platte tekst. Cloudopties voor HSM's zijn AWS CloudHSM, Azure Dedicated HSM en Google Cloud HSM. Voor mTLS op apparaatniveau (IoT, zakelijke laptops) biedt TPM 2.0 een vergelijkbare functie — de TLS-clientsleutel is aan de TPM gebonden en voor ondertekening is TPM-autorisatie vereist, waardoor het uiterst moeilijk wordt om de sleutel van een gecompromitteerd apparaat te halen.

Voor het testen van mTLS heb je tools nodig die het aanbieden van clientcertificaten ondersteunen. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Voor het testen van het servicemesh toont istioctl proxy-config secret pod/name het huidige certificaat en de vervaldatum ervan. Gebruik kubectl exec in een pod en curl het beheereindpunt van de sidecar (localhost:15000) om actieve listeners en hun mTLS-configuratie te inspecteren. Geautomatiseerde controles van de rotatie moeten verifiëren dat verbindingen stabiel blijven tijdens certificaatrotaties.

mTLS voegt clientcertificaat-authenticatie toe aan TLS — beide partijen verifiëren elkaars certificaten. SPIFFE SVID's bieden gestandaardiseerde werklastidentiteit via SPIFFE-URI's in certificaat-SAN's. Istio implementeert mTLS transparant via Envoy-sidecars met STRICT/PERMISSIVE-modi. Kortlevende certificaten (24 uur) maken intrekking overbodig en beperken de periode waarin een compromittering gevolgen heeft. SPIRE automatiseert uitgifte en rotatie via de Workload API. mTLS-privésleutels horen bij implementaties met hoge beveiliging in HSM's of TPM's te staan. Operationele uitdagingen zijn onder meer de beveiliging van CA-sleutels, compatibiliteit met tussenliggende netwerkapparatuur en rotatie zonder onderbreking.