Voordat u het converteert: SSH-sleutel versus OpenVPN-certificaat

De import mislukt met een certificaatfout, dus de voor de hand liggende stap lijkt een conversie. Dat instinct stuurt mensen een pad op waar de bestandsextensie verandert en de afwijzing precies hetzelfde blijft. Een ssh-ed25519-regel in authorized_keys en een OpenVPN-clientcertificaat zijn afzonderlijke referentieobjecten, met verschillende uitgevers, verschillende coderingen en verschillende intrekkingspaden. Als u deze controles op volgorde doorloopt, weet u binnen een minuut of een conversie überhaupt kan helpen.

Welk object hebt u eigenlijk?

Er zijn vijf dingen die mensen een sleutel noemen, en slechts één daarvan is wat een TLS-profiel wil. Een openbare SSH-sleutel is één regel tekst met een typeprefix en een base64-payload. Een OpenSSH-certificaat is die sleutel plus een handtekening, principals en opties, geproduceerd door ssh-keygen dat als zijn eigen kleine CA optreedt. Een X.509-certificaat is een heel andere structuur, die een subject, een geldigheidsvenster, extensies en een handtekening van een certificaatautoriteit draagt. Een privésleutel is de geheime helft, en een uitgegeven bundel is meestal een certificaat plus de keten plus de privésleutel in één bestand.

De eerste test kost één opdracht. Richt openssl op het bestand en vraag het de certificaatstructuur te parseren:

openssl x509 -in client.crt -noout -subject -issuer

Als dat mislukt met een unable-to-load- of PEM-fout, is het bestand geen X.509-certificaat hoe u het ook hebt genoemd. Een hernoeming herschrijft de ASN.1 binnenin niet, en het inpakken van een openbare-sleutelregel in PEM-koptekst doet dat ook niet.

Vraagt het profiel überhaupt om een certificaat?

Clientcertificaten zijn één authenticatiemethode naast meerdere, en veel werkende TLS-profielen vragen er nooit een. Een server kan gebruikers authenticeren via een plug-in, een gebruikersnaam en wachtwoord of een token-backend, terwijl hij toch van de client eist dat die de identiteit van de server verifieert. Als het profiel geen clientcertificaat-richtlijn bevat, wordt er nooit een certificaat opgevraagd, en geen enkele conversie krijgt de gateway zover dat hij er een opvraagt.

Oudere configuraties met een statische sleutel zijn een derde geval. Ze dateren van vóór de TLS-handshake en verwachten een bestand met een vooraf gedeeld geheim, waardoor het plakken van een openbare sleutel in dat veld ook niet kan werken. Lees wat het profiel werkelijk vraagt voordat u besluit dat de referentie onjuist is.

Wat hercodering kan en niet kan doen

Privésleutels hebben wel legitieme alternatieve containers. Dezelfde RSA- of EC-sleutel kan als traditionele PEM, als PKCS#8 of in een PKCS#12-bundel worden geschreven, en hulpmiddelen converteren er graag tussen. Openbare sleutels hebben een vergelijkbaar verhaal: ssh-keygen kan de RFC 4716-vorm van een SSH-sleutel uitvoeren, en OpenSSH begrijpt ook zijn eigen certificaatformaat. Dat alles is representatie, en representatie is geen vertrouwen.

Wat een conversie niet kan, is een handtekening maken van een certificaatautoriteit die uw sleutel nooit heeft gezien. Een certificaat is een bewering van een uitgever dat een bepaalde openbare sleutel bij een bepaald subject hoort voor een bepaald doel. Hercodering bewaart de bytes van de sleutel en laat de bewering ontbreken, dus de gateway heeft niets om tegen zijn vertrouwensopslag te valideren.

Dit is de stap waar de meeste pogingen stilzwijgend mislukken: het bestand eindigt nu op .crt, de client leest het zonder klagen, en de handshake breekt alsnog af omdat de tegenpartij geen keten naar een vertrouwde uitgever kan opbouwen.

Waar de certificaatautoriteit in beeld komt

Een echte inschrijving begint met een sleutelpaar dat u beheert en een certificaatsignatuurverzoek met het subject dat de operator verwacht. De operator verifieert het recht, ondertekent het verzoek met de CA-sleutel en stuurt het uitgegeven certificaat terug samen met elke tussenliggende keten die de client moet overleggen. Daarna heeft de client het CA-certificaat nodig dat het heeft ondertekend, want dat is wat hem laat bevestigen dat de server waarmee hij spreekt bij dezelfde uitrol hoort.

Dat laatste bestand is makkelijk te vergeten en onmogelijk te vervangen. De ondertekeningssleutel van de CA zelf hoort nooit in de clientconfiguratie, en geen enkele lokale conversie levert de keten op die u had moeten ontvangen.

Wat hergebruik van de SSH-sleutel u kost

Stel dat een conversie toch iets acceptabels heeft opgeleverd. Hergebruik van één sleutelpaar voor zowel SSH-toegang als VPN-authenticatie koppelt nog steeds twee onafhankelijke beveiligingsbeslissingen. Het verwijderen van een authorized_keys-regel stopt SSH-logins, en het doet niets met een certificaat dat de VPN-CA al voor dezelfde openbare sleutel heeft uitgegeven. De VPN-kant wordt via zijn eigen mechanisme ingetrokken, dat wil zeggen de certificaatintrekkingslijst of de registratiegegevens van de operator.

De checklist eindigt dus met een stopconditie in plaats van een truc. Als openssl het bestand niet als certificaat parseert, stop dan met converteren en beschrijf wat u hebt: SSH-sleutel, SSH-certificaat, X.509-certificaat, privésleutel of bundel. Als het profiel geen clientcertificaat vraagt, stop en vraag welke authenticatiemethode de server verwacht. Pas wanneer beide antwoorden op X.509 wijzen, wordt inschrijving de volgende stap, en dat gesprek gaat veel sneller met het juiste zelfstandig naamwoord in de eerste zin.