SSL/TLS X.509 Certificaat RD Gateway

[Funzy83]

Hoi iedereen

Aangezien een remote desktop gateway het RDP protocol in HTTPS inpakt. Moet er voor het gebruik van een remote desktop gateway een SSL/TLS certificaat geconfigureerd worden. Er zijn verschillende mogelijkheden voor het aanschaffen en configureren van een SSL/TLS X.509 certificaat voor een remote desktop gateway.

Optie 1: self signed CA certificate:

Lijkt me enkel nuttig voor testomgevingen.

Optie 2: private CA certificate:

Certificaat verkregen door een intern PKI. Is niet van toepassing omdat het bedrijf in kwestie geen interne PKI heeft.

Optie 3: Public CA certificate:

Aan te kopen bij sites als bv GoDaddy. Lijkt me de beste oplossing voor de situatie waarin ik me bevind.

Uitgaande van het feit dat er een RD Gateway in DMZ staat, en 4 Windows 7 PC in het LAN waarmee RDP connectie moet woren opgezet, over de RD gateway uiteraard. Zijn er enkele onduidelijkheden voor mij betreffende de implementatie van het certificaat op de verschillende devices.

Wat volgens mijn bedenkingen moet gebeuren:

1. Plaatsen van het certificaat op RD Gateway tijdens installatie
2. Manueel importeren van certificaat op de 4 windows 7 PC's

Bedenkingen bij de verbinding van de remote client?

De Remote cliënt zet uiteindelijk verbinding op met RD Gateway, wordt dan onderling het certificaat uitgewisseld, zoals bij een HTTPS browser sessie? Of moeten de computers van de remote werknemers ook manueel voorzien worden van het certificaat?

Alvast bedankt

[ Voor 6% gewijzigd door Funzy83 op 31-03-2014 00:25 ]

[Verwijderd]

Stap 1 is idd nodig. Zorg er wel voor dat je het juiste SSL certificaat aankoopt. Lees hiervoor de relevante documentatie door.

Ik begrijp niet waar je stap twee voor nodig denkt te hebben. Ik ken de setup natuurlijk niet maar ik ga er voor het gemak vanuit dat de RD gateway en de windows 7 desktops elkaar vertrouwen (via AD bijvoorbeeld). Indien dit niet het geval is, zie ik niet zo een, twee, drie waarom het handmatig importeren van het certificaat op de Windows 7 pc's gaat helpen.

De certificaten in SSL worden gebruikt als verificatie van de afzender. Het is een bewijs dat je idd verbinding hebt met de juiste server. Dit gebeurt door te controleren of de hostname op het certificaat en de hostname van de server overeen komen. Daarnaast word het certificaat gecontroleerd op echtheid bij een Certificate Authority (das waar je maandelijks/jaarlijks geld voor betaald). Het handmatig importeren van een certificaat heeft als effect dat de computer geen contact meer hoeft op te nemen met de CA als hij een ssl verbinding met die specefieke server wil starten. Dit werkt niet de andere kant op (dus je windows 7 machine gaat niet na of de machine die de ssl verbinding opzet wel is wie hij zegt dat hij is).

[PerfectPC]

Verwijderd schreef op maandag 31 maart 2014 @ 00:55:
De certificaten in SSL worden gebruikt als verificatie van de afzender. Het is een bewijs dat je idd verbinding hebt met de juiste server. Dit gebeurt door te controleren of de hostname op het certificaat en de hostname van de server overeen komen. Daarnaast word het certificaat gecontroleerd op echtheid bij een Certificate Authority (das waar je maandelijks/jaarlijks geld voor betaald). Het handmatig importeren van een certificaat heeft als effect dat de computer geen contact meer hoeft op te nemen met de CA als hij een ssl verbinding met die specefieke server wil starten. Dit werkt niet de andere kant op (dus je windows 7 machine gaat niet na of de machine die de ssl verbinding opzet wel is wie hij zegt dat hij is).

Dat is wel heel kort door de bocht... Gelukkig is het niet nodig om een CA te contacteren om een geldige SSL/TLS verbinding op te zetten. (offline SSL/TLS zou onmogelijk zijn anders)

Wat is er dan wel nodig: een geldige en volledige keychain, quid:
- de naam (of in geval er geen fqdn gebruikt wordt het IP) van de server (of client) moet overeenkomen met de Common Name (of SAN) van het certificaat
- het certificaat moet geldig zijn, dus nog niet vervallen of toekomstig
- het certificaat moet geschikt zijn voor de gebruikte activiteit (server/client SSL, codesigning, ...)
- en vooral, het certificaat moet ondertekend zijn door (een child van) een geldig certificaat in de trusted root certificate store van het OS (of in uitzonderlijke gevallen de applicatie)

Om dit laatste te bekomen heb je onderdaad 3 opties:
- self signed, dan moet je dit certificaat importeren als trusted peer certificate en/of trusted root certificate
- private pki, in een windows AD omgeving is de root van de CA automatisch getrust in het domain, andere pc's moeten dit root CA cert importeren als trusted root certifiacte
- public pki, veruit het eenvoudigste, deze zijn meestal al getrust door je OS of applicatie

Vergeet niet om eventuele intermediate certificates mee op te nemen in de keychain (aan de kant van de server)

Voor de volledigheid: een client/server kan wel degelijk contact opnemen met een CA, maar enkel om na tekijken of een certificaat niet revoked is, al is dit niet mandatory.

[Funzy83]

PerfectPC schreef op maandag 31 maart 2014 @ 01:49:
[...]

Dat is wel heel kort door de bocht... Gelukkig is het niet nodig om een CA te contacteren om een geldige SSL/TLS verbinding op te zetten. (offline SSL/TLS zou onmogelijk zijn anders)

Wat is er dan wel nodig: een geldige en volledige keychain, quid:
- de naam (of in geval er geen fqdn gebruikt wordt het IP) van de server (of client) moet overeenkomen met de Common Name (of SAN) van het certificaat
- het certificaat moet geldig zijn, dus nog niet vervallen of toekomstig
- het certificaat moet geschikt zijn voor de gebruikte activiteit (server/client SSL, codesigning, ...)
- en vooral, het certificaat moet ondertekend zijn door (een child van) een geldig certificaat in de trusted root certificate store van het OS (of in uitzonderlijke gevallen de applicatie)

Om dit laatste te bekomen heb je onderdaad 3 opties:
- self signed, dan moet je dit certificaat importeren als trusted peer certificate en/of trusted root certificate
- private pki, in een windows AD omgeving is de root van de CA automatisch getrust in het domain, andere pc's moeten dit root CA cert importeren als trusted root certifiacte
- public pki, veruit het eenvoudigste, deze zijn meestal al getrust door je OS of applicatie

Vergeet niet om eventuele intermediate certificates mee op te nemen in de keychain (aan de kant van de server)

Voor de volledigheid: een client/server kan wel degelijk contact opnemen met een CA, maar enkel om na tekijken of een certificaat niet revoked is, al is dit niet mandatory.

Bedankt voor de reactie

Nog even voor alle duidelijkheid. Als alles goed geconfigureerd is zal de cliënt via RDP verbinding opzetten met de RD Gateway. Bij het contacteren van de Gateway zend de gateway het certificaat naar de cliënt. De cliënt doet controle over internet bij de respectievelijke CA. Indien echtheid bevestigd kan de RDP connectie versleuteld opgezet worden.

Correct of zie ik nog iets over het hoofd?

[johnkeates]

De client doet geen controle over internet bij de respectievelijke CA. Op z'n best zal ie de CRL van de CA even checken, en dat gaat asynchroon als het al gebeurt.

De controle is gewoon simpelweg pubkey. Cert signature wordt met Root CA cert gedecodeerd, als dat werkt issie dus echt. Daarna wordt aan de hand van fingerprint de CRL nagezocht om te kijken of er een match is, als er internet is, en als de client ingesteld is om dat te doen.