Bladcertificaat geldig, keten verlopen: lees de diepte

Je controleert het servercertificaat, ziet nog maanden op de klok, en de client weigert de verbinding toch met een verlopen-melding. De datum die je leest hoort bij het blad, en de klacht kan over iets diepers in het pad gaan. Verificatie loopt een keten af, en elk certificaat dat deze tocht selecteert kan in zijn eigen geldigheidsvenster mislukken. Lees welk exemplaar faalde voordat je iets vernieuwt.

De diepte noemt het certificaat dat faalde

In OpenSSL-diagnostiek is diepte 0 het doelcertificaat en diepte 1 de uitgever die het heeft ondertekend, met hogere nummers die verder naar de vertrouwensanker leiden. Een verlopen dat op diepte 1 wordt gemeld, wordt niet tegengesproken door een actuele notAfter op het blad, dus het zichtbare certificaat nog eens controleren zal de fout nooit verklaren.

Noteer de vingerafdruk van het mislukte certificaat samen met zijn subject, want verschillende certificaten kunnen dezelfde CA-naam dragen. Kruisondertekening veroorzaakt precies die situatie: dezelfde autoriteit verschijnt meer dan eens, met verschillende geldigheidsdatums, en de verifier koos degene die je niet verwachtte. Een vertrouwd label is geen identificatie, en een vingerafdruk is wat twee objecten met dezelfde naam onderscheidt.

Let ook op producten met meer dan één certificaatrol. Op OpenVPN Access Server zijn de certificaten die de webinterfaces beschermen gescheiden van die voor VPN-verbindingen, dus een browser die de adminpagina opent bewijst niets over het pad van de tunnel.

Vertrouwensinvoer is niet hetzelfde als ketenkandidaten

Geef de verifier de twee invoeren apart en expliciet. Het vertrouwensbestand bevat de ankers die je accepteert; de niet-vertrouwde bundel bevat tussenliggende certificaten die worden aangeboden om het pad te bouwen. Ze mengen is hoe mensen per ongeluk een tussenliggend certificaat tot root promoveren en zich dan afvragen waarom dezelfde fout hen tussen machines volgt.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Het uitschakelen van het standaardpad en -archief met -no-CApath -no-CAstore houdt de test eerlijk: het resultaat hangt dan af van de bestanden die je noemde, niet van wat het werkstation toevallig vertrouwt. De OpenSSL-verificatiereferentie documenteert deze opties en de diagnostiek die ze opleveren.

-show_chain drukt de gebouwde keten af wanneer verificatie slaagt, wat handig is om te bevestigen dat het pad het bedoelde is. Als het mislukt, houd dan de gemelde diepte en het subject vast; die twee velden vertellen de volgende lezer welk certificaat te inspecteren.

Wat dit niet doet, is het beleid van elke client nabootsen. Een pin, een doelbeperking of een clientspecifieke identiteitscontrole leeft in de client, niet in dit commando. Dat zijn de instellingen om te inspecteren wanneer verificatie op de server slaagt en de verbinding nog steeds mislukt. Houd de twee diagnoses gescheiden, anders vernieuw je een gezond certificaat terwijl je een pinning-fout jaagt.

Wat de controle bewijst en wat ze weglaat

Dit is een pad- en doelcontrole tegen een vertrouwensbestand dat je zelf hebt aangeleverd. Voor een HTTPS-naamcontrole voeg je de verwachte hostnaam toe via de juiste optie; voor een VPN-verbinding behoud je de geconfigureerde identiteitscontroles van de client en gebruik je het vertrouwensmateriaal dat die client werkelijk leest.

Wat een server stuurt is een verzameling kandidaten, niet het pad dat je client uiteindelijk bouwt. Lokaal vertrouwen en de constructieregels van de bibliotheek vormen beide het resultaat, daarom kan hetzelfde antwoord op de ene machine verifiëren en op de andere mislukken. Vergelijk het onderhouden vertrouwensarchief en de TLS-implementatie van de mislukkende client met die van een werkende client voordat je identieke evaluatie aanneemt. Een verschil daar verklaart veel meldingen „alleen deze laptop mislukt“.

Om het venster van elk certificaat te zien in plaats van één per keer, druk ze af als een set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Dat tweede commando somt subjecten en uitgevers op zonder elk bestand met de hand te decoderen, zo zie je een tussenliggend certificaat waarvan de datum is verstreken terwijl het blad er nog goed uitziet.

Repareer het pad zonder verificatie te verzwakken

Wanneer een verlopen tussenliggend of een verouderd kruisondertekend certificaat wordt aangeleverd, haal dan de momenteel ondersteunde keten van de uitgever en rol die uit via de gedocumenteerde certificaatworkflow van de dienst. Wanneer de client het bedoelde onderhouden anker mist, werk dan zijn beheerde vertrouwensconfiguratie of de clientsoftware bij. Weersta de snelweg om elk certificaat in de bundel als root te markeren alleen om de melding te dempen.

De omgang met de root verdient een noot, omdat samenvattingen die vaak overdrijven. RFC 5280 behandelt het anker als invoer die buiten het voorgenomen pad staat, terwijl OpenSSL geldigheidscontroles documenteert die zijn root-CA-certificaat omvatten. Beide uitspraken gelden voor hun eigen systemen; het root-verloopgedrag van één bibliotheek generaliseren naar elke client levert zelfverzekerde foute antwoorden op.

Forceer na de wijziging een nieuwe authenticatie op de getroffen client en bevestig dat de specifieke verlopen-melding weg is. Vernieuw het blad alleen als het blad zelf ongeschikt is. Tijdcontroles uitschakelen of een historisch kruiscertificaat herstellen levert geen geldig actueel pad op; het stelt alleen de volgende fout uit.