Security Professionals
- ipfw add deny all from eindgebruikers to any
Server certificaat als client
Ben een programmeur en geen system beheerder, mag toch de beheer voor sommige servers doen.
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Reacties (10)
Als je extreem veel moeite krijgt te doen, waarbij de halve server van je klant herprogrammeert, mag ik het niet onmogelijk krijgen te noemen, alleen of het functioneel is? het is niet de bedoeling en de software is er standaard ook niet op gemaakt, krijg je tóch zo iets te programmeren, pas je de software dermate aan dat het totaal andere software geworden is.
wat een vreemde situatie, lijkt op vragen of het mogelijk is dat de client bij https onderhandeling het server certificaat hanteert, tja onmogelijk is het niet.. alleen dat lijkt ongeveer de situatie hier ??? kreeg je die klant wel duidelijk te verstaan... ??
wat een vreemde situatie, lijkt op vragen of het mogelijk is dat de client bij https onderhandeling het server certificaat hanteert, tja onmogelijk is het niet.. alleen dat lijkt ongeveer de situatie hier ??? kreeg je die klant wel duidelijk te verstaan... ??
Door leonZaat: Ben een programmeur en geen system beheerder, mag toch de beheer voor sommige servers doen.
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Ja . Dwz, SSL/TLS sessies waarbij de client zich _ook_ authenticeert met een certificaat bij de server zijn mogelijk.
Dat wordt inderdaad nog wel eens gebruikt bij server-server API koppelingen.
Een browser ondersteund dat ook, dus je kunt gewoon testen met een webbrowser .
De client in die connectie moet dan (ook) beschikken over het geheime deel van de key van het certificaat dat hij presenteert als credential .
Of wat jij doet de goede weg is, weet ik niet. Maar je hebt een certificaat nodig waarvan de signing authority bekend is op de server waartegen je authenticeert .
18-10-2018, 09:14 door
Bitwiper
Een webservercertificaat is onbruikbaar als clientcertificaat - "tenzij".
Eerst enkele achtergronden (ik laat de tekst inspringen, sla maar over als het je niet interesseert).
Het eeste probleem bij het gebruik van een webservercertificaat als clientcertificaat is dat de server de client op dat moment niet bezoekt (maar andersom). De validatie is dus minder sterk dan de andere kant op; voor een aanvaller volstaat het om ongeautoriseerd een private key in handen te krijgen, of een certificaatuitgever te bewegen onterecht een certificaat af te geven. En wat de server sowieso moet doen, is een lijst bijhouden van welke clients toegang mogen hebben (immers ik denk zomaar dat het niet de bedoeling is dat elke client met een willekeurig geldig webservercertificaat plus bijbehorende private key toegang zou moeten krijgen, zoals nu.nl).
Daarnaast is het goed gebruik om de toepassingsmogelijkheden van certificaten te beperken door, in het certificaat, het gebruiksdoel op te nemen. Mocht de private key van een webserver in verkeerde handen vallen, dan kan daar bijv. geen code digitaal mee worden ondertekend, want dat gebruiksdoel is -normaal gesproken- uitgesloten. Hetzelfde kan gelden voor een clientcertificaat: als de certificaat-controlerende software de in het certificaat opgenomen beperkingen respecteert, zal een clientcertificaat (tenzij is aangegeven dat het ook als servercertificaat mag worden gebruikt) onbruikbaar zijn als servercertificaat en vice versa.
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
Eerst enkele achtergronden (ik laat de tekst inspringen, sla maar over als het je niet interesseert).
Een certificaat wordt niet gebruikt voor authenticatie, maar voor identificatie. Als jouw browser verbinding maakt met https://www.security.nl/, stuurt die site een perfecte kopie van haar webservercertificaat naar jouw browser. Daarna heb jij dat certificaat in jouw bezit en kun je daar oneindig veel perfecte kopïën van maken en aan derden geven. Maar gelukkig betekent dat niet dat jij een webserver kunt opzetten die zich voordoet als security.nl, en die vertrouwd wordt omdat deze dat webservercertificaat naar bezoekers stuurt.
Identificatie van een webserver (ook http) beslaat overigens meerdere stappen. Als jij https://www.security.nl/ als URL in jouw webbrowser intikt en Enter drukt, zal jouw browser een DNS lookup doen van www.security.nl en met het zo verkregen IP-adres verbinding proberen te maken. Dat laatste vereist dat netwerkpakketjes op LAN en WAN (internet) werkelijk naar het bedoelde IP-adres worden gerouteerd en dat anwoorden daarop bij jouw browser aankomen. Zodra de verbinding met dat IP-adres er is, zal jouw browser vragen om met www.security.nl te worden "doorverbonden" (op, of achter, 1 IP-adres kunnen namelijk meerdere websites -met verschillende domeinnamen- draaien). Dit zijn allemaal stappen waar aanvallers, afhankelijk van de omstandigheden, soms relatief eenvoudig op kunnen ingrijpen. Denk daarbij aan gehackte modem/routers met DNS-changer malware, DNS spoofing attacks, hacken van DNS-admin accounts bij DNS registrars, MITM (Man In The Middle) aanvallen bij public WiFi verbindingen, WPAD/NBNS of ARP spoofing attacks op LAN niveau en/of BGP hijack attacks op WAN niveau.
Authenticatie (identiteit bewijzen) bij https vindt plaats doordat de server bewijst dat deze een private key in haar bezit heeft - zonder die private key ooit met iemand te hoeven delen. Wat die server wel deelt is de bijpassende public key, een soort complementaire sleutel die onderdeel is van elk digitaal certificaat. Aangezien jij de private key van security.nl niet in jouw bezit hebt (hoop ik), kan jouw server zich niet voordoen als https://www.security.nl/, ook al heeft de browser van de bezoeker een IP-verbinding met een webserver die dat claimt te zijn.
Een webservercertificaat wordt tegenwoordig ook niet meer gebruikt voor de versleuteling van de verbinding (vroeger werd een symmetrische sleutel door de client versleuteld met de public key uit het certificaat, waardoor uitsluitend de bezitter van de private key die versleutelds symmetrische sleutel kan ontsleutelen en inzetten voor het versleutelen van de verbinding). Tegenwoordig gebeurt dat meestal met de Diffie-Hellman key agreement (zie bijv. Wikipedia voor meer info).
De belangrijkste functie van een webservercertificaat is het koppelen van een public key aan haar identiteit, de webserver-domeinnaam. We gebruiken de term "certificaat" omdat genoemde koppeling digitaal is ondertekend, meestal door een derde partij die -als het goed is- heeft vastgesteld dat de aanvrager van het certificaat inderdaad de eigenaar is van de identiteit plus de public key. Van fundamenteel belang is dat een bezoeker van een webserver de CA (certificate authority = certificaatuitgever) vertrouwt, in de zin van dat die CA nooit certificaten aan anderen dan de rechtmatige eigenaar van een identiteit (zoals een webserver domeinnaam) zal verstrekken (d.w.z. een vals CSR = certificate signing request zal ondertekenen).
Kortom, identificatie van een https website zoals https://www.security.nl/ bestaat uit de volgende stappen:
1) DNS lookup: meestal betrouwbaar, maar je weet het nooit zeker,
2) Routering op LAN en internet: minder of meer lastig aan te vallen, maar eenvoudig op public WiFi;
3) Verbinding met de juiste website bij meerdere op 1 IP-adres (www.security.nl maakt hier overigens geen gebruik van, maar goedkope webhosters en sommige CDN providers wel): configuratiefouten, bugs en compromittering kunnen ertoe leiden dat je niet bij de gewenste bestemming uitkomt;
4) Jouw browser ontvangt een webservercertificaat van de gevraagde domeinnaam en stelt vast dat de domeinnaam in de URL balk overeenkomt met één van de in het certificaat genoemde domeinnamen.
Die laatste stap vervalsen is het eenvoudigst voor aanvallers, want iedereen die https://www.security.nl/ bezoekt, ontvangt het webservercertificaat van die site. Het fraaie van https is dat je in één keer alle bovengenoemde aanvalsscenario's onmogelijk maakt, doordat de server moet bewijzen over de private key te beschikken die past bij de public key in het certificaat.
Certificaten en TLS verbindingen zijn helaas ook niet perfect veilig, maar aanvallers zullen zowel over een vals certificaat + private key moeten beschikken als één van bovengenoemde aanvallen moeten uitvoeren, en daarmee maken wij hen het zo lastig mogelijk. Als de betrouwbaarheid van de certificaataanvraag uitsluitend afhankelijk is van bovengenoemde 3 stappen -zoals bij DV (Domain Validated) certificaten- is die natuurlijk ver te zoeken (en daarom noem ik ze speelgoedcertificaten).
Identificatie van een webserver (ook http) beslaat overigens meerdere stappen. Als jij https://www.security.nl/ als URL in jouw webbrowser intikt en Enter drukt, zal jouw browser een DNS lookup doen van www.security.nl en met het zo verkregen IP-adres verbinding proberen te maken. Dat laatste vereist dat netwerkpakketjes op LAN en WAN (internet) werkelijk naar het bedoelde IP-adres worden gerouteerd en dat anwoorden daarop bij jouw browser aankomen. Zodra de verbinding met dat IP-adres er is, zal jouw browser vragen om met www.security.nl te worden "doorverbonden" (op, of achter, 1 IP-adres kunnen namelijk meerdere websites -met verschillende domeinnamen- draaien). Dit zijn allemaal stappen waar aanvallers, afhankelijk van de omstandigheden, soms relatief eenvoudig op kunnen ingrijpen. Denk daarbij aan gehackte modem/routers met DNS-changer malware, DNS spoofing attacks, hacken van DNS-admin accounts bij DNS registrars, MITM (Man In The Middle) aanvallen bij public WiFi verbindingen, WPAD/NBNS of ARP spoofing attacks op LAN niveau en/of BGP hijack attacks op WAN niveau.
Authenticatie (identiteit bewijzen) bij https vindt plaats doordat de server bewijst dat deze een private key in haar bezit heeft - zonder die private key ooit met iemand te hoeven delen. Wat die server wel deelt is de bijpassende public key, een soort complementaire sleutel die onderdeel is van elk digitaal certificaat. Aangezien jij de private key van security.nl niet in jouw bezit hebt (hoop ik), kan jouw server zich niet voordoen als https://www.security.nl/, ook al heeft de browser van de bezoeker een IP-verbinding met een webserver die dat claimt te zijn.
Een webservercertificaat wordt tegenwoordig ook niet meer gebruikt voor de versleuteling van de verbinding (vroeger werd een symmetrische sleutel door de client versleuteld met de public key uit het certificaat, waardoor uitsluitend de bezitter van de private key die versleutelds symmetrische sleutel kan ontsleutelen en inzetten voor het versleutelen van de verbinding). Tegenwoordig gebeurt dat meestal met de Diffie-Hellman key agreement (zie bijv. Wikipedia voor meer info).
De belangrijkste functie van een webservercertificaat is het koppelen van een public key aan haar identiteit, de webserver-domeinnaam. We gebruiken de term "certificaat" omdat genoemde koppeling digitaal is ondertekend, meestal door een derde partij die -als het goed is- heeft vastgesteld dat de aanvrager van het certificaat inderdaad de eigenaar is van de identiteit plus de public key. Van fundamenteel belang is dat een bezoeker van een webserver de CA (certificate authority = certificaatuitgever) vertrouwt, in de zin van dat die CA nooit certificaten aan anderen dan de rechtmatige eigenaar van een identiteit (zoals een webserver domeinnaam) zal verstrekken (d.w.z. een vals CSR = certificate signing request zal ondertekenen).
Kortom, identificatie van een https website zoals https://www.security.nl/ bestaat uit de volgende stappen:
1) DNS lookup: meestal betrouwbaar, maar je weet het nooit zeker,
2) Routering op LAN en internet: minder of meer lastig aan te vallen, maar eenvoudig op public WiFi;
3) Verbinding met de juiste website bij meerdere op 1 IP-adres (www.security.nl maakt hier overigens geen gebruik van, maar goedkope webhosters en sommige CDN providers wel): configuratiefouten, bugs en compromittering kunnen ertoe leiden dat je niet bij de gewenste bestemming uitkomt;
4) Jouw browser ontvangt een webservercertificaat van de gevraagde domeinnaam en stelt vast dat de domeinnaam in de URL balk overeenkomt met één van de in het certificaat genoemde domeinnamen.
Die laatste stap vervalsen is het eenvoudigst voor aanvallers, want iedereen die https://www.security.nl/ bezoekt, ontvangt het webservercertificaat van die site. Het fraaie van https is dat je in één keer alle bovengenoemde aanvalsscenario's onmogelijk maakt, doordat de server moet bewijzen over de private key te beschikken die past bij de public key in het certificaat.
Certificaten en TLS verbindingen zijn helaas ook niet perfect veilig, maar aanvallers zullen zowel over een vals certificaat + private key moeten beschikken als één van bovengenoemde aanvallen moeten uitvoeren, en daarmee maken wij hen het zo lastig mogelijk. Als de betrouwbaarheid van de certificaataanvraag uitsluitend afhankelijk is van bovengenoemde 3 stappen -zoals bij DV (Domain Validated) certificaten- is die natuurlijk ver te zoeken (en daarom noem ik ze speelgoedcertificaten).
Het eeste probleem bij het gebruik van een webservercertificaat als clientcertificaat is dat de server de client op dat moment niet bezoekt (maar andersom). De validatie is dus minder sterk dan de andere kant op; voor een aanvaller volstaat het om ongeautoriseerd een private key in handen te krijgen, of een certificaatuitgever te bewegen onterecht een certificaat af te geven. En wat de server sowieso moet doen, is een lijst bijhouden van welke clients toegang mogen hebben (immers ik denk zomaar dat het niet de bedoeling is dat elke client met een willekeurig geldig webservercertificaat plus bijbehorende private key toegang zou moeten krijgen, zoals nu.nl).
Daarnaast is het goed gebruik om de toepassingsmogelijkheden van certificaten te beperken door, in het certificaat, het gebruiksdoel op te nemen. Mocht de private key van een webserver in verkeerde handen vallen, dan kan daar bijv. geen code digitaal mee worden ondertekend, want dat gebruiksdoel is -normaal gesproken- uitgesloten. Hetzelfde kan gelden voor een clientcertificaat: als de certificaat-controlerende software de in het certificaat opgenomen beperkingen respecteert, zal een clientcertificaat (tenzij is aangegeven dat het ook als servercertificaat mag worden gebruikt) onbruikbaar zijn als servercertificaat en vice versa.
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
Door Bitwiper: Een webservercertificaat is onbruikbaar als clientcertificaat - "tenzij".
[knip - lang, en correct verhaal]
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
[knip - lang, en correct verhaal]
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
Let op : de TS zit aan de 'moet zich authenticeren' kant - grotendeels is je uitleg gericht op de _andere_ kant .
Inderdaad wordt bij ietwat kleinschalige deployments vaak een eigen root-CA gebruikt en worden daarmee client certificaten getekent die de gebruikers aangeleverd krijgen.
Voor TS: dan zou jouw klant je dus een certificaat moeten sturen waarmee je je authenticeert bij zijn server.
De andere manier is wanneer je 'officieel' client certificaat voor je server hebt - in dat geval moet de klant waarbij je moet inloggen nog wel op z'n server instellen dat een valide certificaat met CN=jouw.server.jouwdomein.nl geaccepteerd wordt.
(en een valide certificaat met CN=mijn.eigen.vanity.wegwerp.domain.com niet ).
Two way ssl, is een redelijk ingeburgerd begrip intussen. Kan afhankelijk van de oplossing gedaan worden met zowel client- als servercertificaten. Dat is een kwestie van de juiste reverse proxy kiezen.
25-10-2018, 10:55 door
nadhim
For those engaged in transactions on the web, certificates mean an end to anonymity and instead provide assurance that this is someone you can trust; that they are who they say they are. In an online world where our safety is being challenged constantly, such reassurance is invaluable.
Door nadhim: For those engaged in transactions on the web, certificates mean an end to anonymity and instead provide assurance that this is someone you can trust; that they are who they say they are. In an online world where our safety is being challenged constantly, such reassurance is invaluable.
Dit klinkt als verkooppraatje van een certificatenboer (zie ook: "Honest Achmed").Je zegt hier dat een (pki) certificaat betekent dat je de houder kan vertrouwen. Omdat je weet wie het is. Nou, nee.
In weze is een certificaat niet meer dan een aangeklede publieke sleutel. Je kan er prima een voor jezelf uitgeven. Die is dan "door zichzelf ondertekend". Oftewel het signatuur op het certificaat is gegenereerd met de geheime sleutel die bij het certificaat hoort. Een certificaat uitgegeven door een certificatenboer is ondertekend met een de geheime sleutel van een (sub)certificaat van die certificatenboer. Hun verkooppunt is dat hun (hoofd)certificaat, wat ook een zelfondertekend certificaat is, bij "iederen" alvast in het lijstje "vertrouwde" certificaten van de browser staat. Het hele "vertrouwen" rust op de manier waarop die certificatenboer de certificaten uitdeelt. Niet op het bestaan van het certificaat zelf.
Maargoed, in het geval van TS waarin een relatie wordt opgezet van regelmatig verbindingen maken "met de server" en dat zowel server als client een certificaat presenteren, maakt dat hele feest niet uit. Je spreekt "out of band" af welke certificaten over en weer gebruikt worden, en dat kan dus heel goed en veilig met zelfondertekende certificaten. Want het stukje vertrouwen zit in de klantrelatie, en hoeft dus niet afhankelijk gemaakt te worden van een derde partij. Liever niet zelfs.
@LeonZaat, ja een server certificaat kan ook naast de enhanced key usage "server certificate" OOK de EKU client certificate hebben.
Je kan dit certificaat kopen of zelf maken via bijv OpenSSL.
Als je m zelf maakt moet je de issuing CA zelf importeren op zowel de lokale server als de doelserver om het vertrouwen in te stellen.
Je kan dit certificaat kopen of zelf maken via bijv OpenSSL.
Als je m zelf maakt moet je de issuing CA zelf importeren op zowel de lokale server als de doelserver om het vertrouwen in te stellen.
Door leonZaat: Ben een programmeur en geen system beheerder, mag toch de beheer voor sommige servers doen.
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Een klant van mij beweert dat ik een ceritficaat voor onze server zou moeten gebruiken om contact te kunnen maken met hun server.
Ik heb een cfx gecreerd van uit onze CER en probeer deze mee te sturen als authenticatie.
We gebruiken het certificaat normaal voor binnen komende berichten/bestanden en dan gaat de authenticatie goed.
Maar nu willen ze hetzelfde certificaat gebruiken voor een get, waar wij dus het verzoek doen.
Kan dit uberhaupt?
groet,
Leon
Door Anoniem:
Let op : de TS zit aan de 'moet zich authenticeren' kant - grotendeels is je uitleg gericht op de _andere_ kant .
Inderdaad wordt bij ietwat kleinschalige deployments vaak een eigen root-CA gebruikt en worden daarmee client certificaten getekent die de gebruikers aangeleverd krijgen.
Voor TS: dan zou jouw klant je dus een certificaat moeten sturen waarmee je je authenticeert bij zijn server.
De andere manier is wanneer je 'officieel' client certificaat voor je server hebt - in dat geval moet de klant waarbij je moet inloggen nog wel op z'n server instellen dat een valide certificaat met CN=jouw.server.jouwdomein.nl geaccepteerd wordt.
(en een valide certificaat met CN=mijn.eigen.vanity.wegwerp.domain.com niet ).
Door Bitwiper: Een webservercertificaat is onbruikbaar als clientcertificaat - "tenzij".
[knip - lang, en correct verhaal]
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
[knip - lang, en correct verhaal]
In de praktijk is het verstandig om zelf clientcertificaten uit te geven, en het rootcertificaat daarvoor op de server te zetten. Dat betekent wel dat je die clientcertificaten moet kunnen "intrekken" (mocht de private key "gelekt" worden of een slechte random number zijn gebruikt voor het genereren van het sleutelpaar) door ze op de een of andere manier te blacklisten. Omdat je nooit 100% kunt uitsluiten dat een leidinggevende of jouw opvolger besluit om dat rootcertificaat ook voor andere doeleinden in te zetten (en omdat het waarschijnlijk in de trusted root certificate store van de webserver staat, en je daar alleen trusted code op wilt uitvoeren), raad ik aan om het gebruiksdoel van clientcertificaten zoveel mogelijk tot dat doel te beperken. En als je zelf certificaten "uitgeeft", is het natuurlijk jouw verantwoording om te checken dat de aanvrager is wie zij zegt dat zij is...
Succes!
Let op : de TS zit aan de 'moet zich authenticeren' kant - grotendeels is je uitleg gericht op de _andere_ kant .
Inderdaad wordt bij ietwat kleinschalige deployments vaak een eigen root-CA gebruikt en worden daarmee client certificaten getekent die de gebruikers aangeleverd krijgen.
Voor TS: dan zou jouw klant je dus een certificaat moeten sturen waarmee je je authenticeert bij zijn server.
De andere manier is wanneer je 'officieel' client certificaat voor je server hebt - in dat geval moet de klant waarbij je moet inloggen nog wel op z'n server instellen dat een valide certificaat met CN=jouw.server.jouwdomein.nl geaccepteerd wordt.
(en een valide certificaat met CN=mijn.eigen.vanity.wegwerp.domain.com niet ).
Let op!
CN is al sinds enigedeprecated. Je moet de server FQDN (en evt het IP) in de Subject Alternative Name als DNS (en evt IP) waarde opgeven. CN mag elke waarde hebben die je wilt bijvoorbeeld: Mijn server referentie
25-10-2018, 14:27 door
Mike22april
Door Anoniem: Two way ssl, is een redelijk ingeburgerd begrip intussen. Kan afhankelijk van de oplossing gedaan worden met zowel client- als servercertificaten. Dat is een kwestie van de juiste reverse proxy kiezen.
hier is niet eens een reverse proxy voor nodig.
Apache bijvoorbeeld doet dit native: https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
