Opdeling PFX certificaat voor SSL verbinding?

[!null]

Ik ben een SSL verbinding aan het opzetten waarbij ook gebruik gemaakt wordt van een client certificaat, in de vorm van een PFX met wachtwoord. Dit doe ik in Delphi met Indy componenten, hiervoor moet ik met certificaten in PEM vorm werken.

Ik heb dit al eerder gedaan, succesvol, hiervoor converteerde ik de PFX naar simpelweg twee losse delen, een key (het key gedeelte van de PFX) in PEM formaat en het certificaat gedeelte van de PFX naar PEM formaat. Dan nog een root certificaat erbij (ook in PEM formaat) en het werkte.
Wanneer je de PFX converteerde met OpenSSL of iets anders, kon je dat doen naar een PEM formaat met alles er nog in (dus nog niet opgedeelt). Dan zie je mooie tags als -----BEGIN PRIVATE KEY----- etc. In die PEM zag je dan duidelijk een key en een certificaat gedeelte.

Nu werk ik echter met een PFX die ook een key gedeelte heeft, maar 3 certificaten in zich heeft. Dit wordt duidelijk als ik naar een PEM converteer, dan zie ik het bekende key gedeelte, en daarna drie certificaat blokken. Hiervan moet ik de laatste hebben lijkt het, maar hij exporteert wat anders (1 van de drie) als ik van de oude manier gebruik maak. Valt ook niet meer terug te herkennen uit 1 van de drie.
De tekst van het laatste certificaat kan ik wel in een PEM file plakken, maar dat accepteren mijn componenten niet. Het andere (welke dat ook is) certificaat gedeelte wat ie op de oude wijze exporteert wordt wel geaccepteert maar niet mee gestuurd over de lijn, wanneer hij bezig is met SSL handshaking. Er wordt om het client certificaat gevraagd, waarbij de juiste situatie is dat hij de key + certificaat teruggeeft, maar in mijn geval alleen de key geeft. En dan faalt hij.

De vraag is eigenlijk hoe krijg ik dus het laatste certificaat blok (of van mij part allemaal) uit het PFX bestand? Misschien belangrijker nog, hoe werkt deze indeling? Want een PFX bestand met key en cert gedeelte snap ik, maar met drie cert blokken niet.

Ik heb overigens een werkend voorbeeld ernaast, met dezelfde certificaten in een browser wordt succesvol verbinding gemaakt. Dit kan ik in wireshark mooi naast elkaar leggen, waarin ik dus zie dat hij op de vraag naar het client certificaat alleen de key antwoordt en niet de key + cert.

[SiErRa]

Je zou de PFX eens gewoon in je windows certificate store kunnen installeren en dan alle losse certificaten kunnen exporteren.
Dit kan met de mmc certificates snapin.

Die drie blokken zijn denk ik de hele certificate chain (die blijkbaar 3 lang is)

[!null]

Ah, een chain. Ik heb middels de mmc certificates tool, lijkt toch net iets meer te kunnen dan m'n andere tools, het certificaat wat ik wilde eruit gepakt en ge-exporteerd. Daarna naar PEM geconverteerd, met hetzelfde resultaat als mijn eerdere copy paste actie uit de complete PEM versie van de PFX. Anyway, alsnog even geprobeerd maar het Delphi component accepteert hem niet. "Could not load key, check password" terwijl het helemaal niet om de key gaat maar om het cert gedeelte. Het key gedeelte gaat al goed.

Wat ik niet begrijp is hoe firefox in dit geval gewoon weet welk certificaat (uit de chain) hij moet halen en teruggeven aan de SSL server. Hij pakt dus de middelste uit de chain en het gaat daarmee goed. Mijn Delphi TIdSSLIOHandlerSocketOpenSSL component wenst alleen de eerste/laatste uit de certificate chain te zien, die persoonlijk is, en stuurt hem vervolgens niet eens op wanneer de server daarom vraagt.
Ik begin te twijfelen of de TIdSSLIOHandlerSocketOpenSSL van Delphi / Indy hier wel wat mee kan. Wellicht moeten er toch nog extra componenten van Eldos aangeschaft worden, maar ik ga het natuurlijk wel even proberen.
Ik wil eigenlijk nog proberen om een PEM te maken met alle certificaten (de hele chain dus) erin, ik weet alleen niet hoe.

[Niemand_Anders]

!null schreef op dinsdag 02 februari 2010 @ 22:32:
Wat ik niet begrijp is hoe firefox in dit geval gewoon weet welk certificaat (uit de chain) hij moet halen en teruggeven aan de SSL server.

Firefox pakt *ALLE* certificaten uit de chain. Dit is nodig om het certificaat te kunnen valideren. Het client certificaat is uitgegeven via een intermediate certfificate (degene in het midden van de chain). Het intermediate certificate is uitgegeven door een officiële CA root authrotity zoals Thawte of Verisign. Zowel de root als de intermediate certificate authrority houden ook een revoke list bij. Veel bedrijven die goedkope SSL certificaten aanbieden werken met intermediate certificaten. Zij mogen dan min of meer names de root CA certificaten uitgeven.

Echter als zo'n tussenpersoon zijn werk niet goed doet,kan de root CA het certificaat weer intrekken via de certificate revoke list (CRL). Dan betekend dan ook automatisch dat all certificaten welke met het certificaat van de tussenpersoon is ondertekend ook ongeldig zijn.

Zodra je dus met certificaten in de weer gaat en deze onderdeel is van een chain, dan dient de gehele chain te worden doorlopen. Vrijwel alle programma hebben (indirect) een lijst van trusted CA roots. Een tussenpersoon kan voor erg veel geld zijn certificaat (of eigenlijk zijn public key en fingerprint) laten opnemen in bijvoorbeeld Windows. Maar ook bijvoorbeeld Firefox of safari hebben een lijst met ingebouwde trusted authrorities. Een certificate welke is ondertekend door een authority welke niet in de trusted list staan wordt dus gezien als een ongeldig certificate. De root certificate is ook nodig om de checksum van het intermediate certificate te controleren.

In kort, jouw client certificate wordt gecontroleerd aan de hand van de intermediate certificate welke op zijn beurt weer wordt gecontrolleerd met het root certificate. Pas als de gehele chain is gecontrolleerd, kan het certificate gebruikt worden.

Waar developers van ssl clients het validatie process van het server certificaat meestal kunnen vervangen door een eigen validatie, kunnen servers dit andersom. In .NET is dat eenvoudig door ServicePointManager.ServerCertificateValidationCallback te overriden.

Een goed artikel over SSL development kun je hier vinden. Het artikel is weliswaar geschreven voor .NET development maar het concept blijft overeind staan voor andere talen/implementaties.

[!null]

Bedankt voor de uitleg. De chain is iets waar de standaard Indy componenten denk ik niet mee om kan gaan. Al snap ik het nog steeds niet, want het is gewoon onderdeel van SSLv3.

Vandaag hebben we besloten extra componenten aan te schaffen, waarin zich ook een professionele SSL client en ook HTTPS client (overerving) bevindt. Deze kan ik echt het complete certificaat geven, en niet alleen het persoonlijke deel. Tevens kunnen we die beter aansluiten op andere eerder gekochte componenten en ook op de Windows certificate storage. Die samenwerking en uberhaupt de componenten lonen wel. Geen OpenSSL (dll's) meer nodig, en geen PEM bestanden aanmaken op het file system etc. Gewoon alles veilig binnen de applicatie.
Ter naslag voor andere Delphi ontwikkelaars, het gaat om onderdelen van de Eldos SecureBlackBox.

Wat ik alleen niet met bovenstaande verhaal kan rijmen is waarom de middelste uit de chain als eerste gegeven wordt, samen met de key, aan de server. Je zou verwachten dat hij aan het begin of einde van de chain zou willen starten.

[Niemand_Anders]

Mijn ervaring is dat aanschaf van componenten zich vrij snel terug verdient. Zo kost mijn inzet 98 euro per uur. Als ik dus twee dagen aan het aanklooien ben dan kost dat 'virtueel' bijna 1600 euro. En als je met zeer strakke milestones werkt in de financiele wereld, dan is die besparing nog veel groter.

Wel leuk om te zien dat er anno 2010 nog steeds bedrijven ontwikkelen met Delphi. Heb er een flinke tijd mee applicaties geschreven tot 2001. Nog even een zijstap gemaakt met Kylix (Delphi voor Linux). Echter sinds ik sinds 2005 CDO (Chief Development Officer) ben, heb ik alle projecten naar 1 taal gebracht, namelijk c#.

De volgorde van inladen is intermediate certificate (2), root certificate (3) en dan pas jouw client certificate (1). De gegevens van de intermediate certificate (2) zijn nodig om jouw certificate te controleren. Echter heeft de intermediate certificate (2) een dependency op het root certificate (3). Bestaat de chain uit 4 of 5 certficaten dan is de volgorde 2, 3, 4 (, 5) en als laatste 1 - de client certificate.

[!null]

Ah op die manier. Logisch. Bedankt voor de uitleg. Ik zou verwachten hij pakt de client certificate en wil vandaar uit valideren.

Nou kost ik geen 98 euro per uur, maar even goed gaan de componenten zich wel snel terugverdienen. Als ik er weer mee verder ga (ik doe dit naast m'n baan) heb ik het zo aan de praat waarschijnlijk, binnen een paar uurtjes. En we gebruiken al andere componenten van ze (om XML's te signen dat soort dingen), bevalt goed.

Delphi gaat prima eigenlijk, het bevalt goed voor een Windows applicatie. Meestal heb je ook alles aan boord in de executable, weinig afhankelijkheden. Ik weet niet welke taal ik zou kiezen als ik met een nieuwe Windows applicatie zou beginnen. Maar met .net heb je wel iets meer zekerheid in de toekomst. Maar goed, ik schrijf niet meer Windows only applicaties. (help er wel aan mee)