RDP og RD Gateway: SSL-certifikat opsætning

Q: Kan jeg bruge et wildcard-certifikat til RD Gateway?

Ja, et wildcard-certifikat (f.eks. *.example.dk ) virker fint til RD Gateway, RD Web Access og interne RDP-forbindelser, så længe alle hostnavne er under samme domæne. Det forenkler opsætningen, fordi ét certifikat dækker alt. Overvej dog sikkerhedsimplikationen: hvis wildcard-nøglen kompromitteres, er alle services under domænet påvirket.

Remote Desktop Gateway bruger HTTPS til at tunnelere RDP-trafik sikkert over internet. Denne guide dækker certifikatkrav, automatisk opsætning med simple-acme, GPO-distribution til RDP-servere og fejlfinding.

Arkitektur

En typisk Remote Desktop-opsætning med gateway har flere komponenter, der hver kræver certifikater:

Internet-klient

MSTSC / Remote Desktop

RD Gateway

HTTPS (port 443)

Offentligt certifikat

RD Web Access

IIS (port 443)

Offentligt certifikat

RDP-servere

Internt netværk

Internt/offentligt cert

RD Gateway og RD Web Access kører typisk på samme server.

Certifikatkrav

Komponent	Certifikattype	Hostname	Bemærkning
RD Gateway	Offentligt (DV/OV)	rdp.example.dk	Internet-eksponeret, offentligt CA nødvendigt
RD Web Access	Offentligt (DV/OV)	rdp.example.dk	Samme hostname som gateway (IIS-binding)
RDP-servere	Internt / offentligt	server01.intern.dk	Kun NLA-autentificering

Opsætning med simple-acme

Simple-acme automatiserer hele certifikatlivscyklussen: udstedelse, installation i Windows Certificate Store, IIS-binding og binding til alle RDP-tjenester. Med det indbyggede ImportRDSFull.ps1 script håndteres RD Gateway, RD Connection Broker, RD Web Access og RDP-listener automatisk ved hver fornyelse.

Simple-acme kommando

simple-acme.exe ^
  --baseuri https://fairssl.dk/acme/ ^
  --source manual ^
  --host rdp.example.dk ^
  --validationmode dns-01 ^
  --validation cloudflare ^
  --cloudflareapitoken JERES_CF_TOKEN ^
  --csr ec ^
  --store certificatestore ^
  --installation iis,script ^
  --siteid 1 ^
  --script "Scripts\ImportRDSFull.ps1" ^
  --scriptparameters "{CertThumbprint}" ^
  --accepttos

Hvad sker der automatisk?

Når simple-acme kører (manuelt eller via Task Scheduler), udfører den disse trin:

1 Udsteder eller fornyer certifikatet via ACME med DNS-01 validering
2 Importerer certifikatet i Windows Certificate Store (Cert:\LocalMachine\My)
3 Opdaterer IIS HTTPS-binding (--installation iis)
4 Kører ImportRDSFull.ps1 der binder certifikatet til RD Gateway, RD Connection Broker, RD Web Access og RDP-listener, og genstarter de relevante tjenester

Vigtige indstillinger i settings.json

I simple-acmes settings.json (eller settings_default.json), sæt:

Store.CertificateStore.PrivateKeyExportable til true (nødvendigt for RDP-tjenester)
ScheduledTask.RenewalMinimumValidDays til 15 (forny senest 15 dage før udløb)

DNS-validering med FairSSL AutoDNS

Har I ikke API-adgang til jeres DNS-udbyder, kan I bruge FairSSL AutoDNS i stedet for Cloudflare. Opsæt en CNAME-record én gang, og FairSSL håndterer al DNS-validering automatisk:

# DNS: engangs CNAME-opsætning
_dnsauth.example.dk  CNAME  dit-unikke-id.autodns.fairssl.dk.

Se simple-acme guiden for fuld dokumentation af scriptparametre og Task Scheduler-konfiguration.

GPO-distribution (Active Directory)

Denne sektion er kun relevant, hvis dine RDP-servere er domænetilsluttede Windows-maskiner i et Active Directory-miljø. Med Group Policy kan du konfigurere RDP-listeneren og NLA-krav centralt:

1 Åbn Group Policy Management Console og opret en ny GPO for RDP-servere.
2 Navigér til Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
3 Aktivér Server Authentication Certificate Template og angiv certifikatskabelonen fra jeres interne CA, eller brug Require use of specific security layer for remote (RDP) connections sat til SSL.
4 Under Require user authentication for remote connections by using NLA: sæt til Enabled for at kræve NLA.

Et internt CA-certifikat til RDP-servere bag gateway er en god løsning. Distribuer root-certifikatet via GPO til klienternes Trusted Root Certification Authorities-lager. Dermed stoler alle domæne-klienter automatisk på RDP-servernes certifikater.

Hosts-fil trick: samme FQDN for gateway og intern RDP

Et almindeligt scenarie: RD Gateway og RDP-serveren bruger samme offentlige FQDN (f.eks. rdp.example.dk). Klienten forbinder til gateway via det offentlige DNS, og gateway skal viderestille til den interne RDP-server. Men gateway kan ikke resolve rdp.example.dk til den interne server, fordi offentlig DNS peger på gatewayen selv.

Løsningen er en hosts-fil entry på gateway-serveren:

# C:\Windows\System32\drivers\etc\hosts på RD Gateway-serveren
10.0.1.50    rdp.example.dk

Nu resolver gateway rdp.example.dk til den interne IP (10.0.1.50) og viderestiller RDP-trafikken korrekt. Klienten ser kun rdp.example.dk og behøver ikke kende den interne IP.

Denne tilgang kræver at RDP-serveren accepterer forbindelser på rdp.example.dk hostnavnet. Hvis RDP-serveren bruger NLA, skal dens certifikat matche rdp.example.dk eller have det som SAN. Med et wildcard-certifikat (*.example.dk) på begge servere er dette automatisk opfyldt.

Fejlfinding

"The remote computer could not be authenticated"

Klienten stoler ikke på certifikatet. Tjek: (1) Er certifikatkæden komplet (intermediate + leaf)? (2) Matcher hostname i certifikatet det hostname klienten forbinder til? (3) Er certifikatet udløbet? Brug SSL Scanner til at verificere.

RD Gateway: "Your computer can't connect to the remote computer"

Typisk et certifikatproblem på gateway-siden. Tjek at certifikatet er bundet i RD Gateway Manager (ikke kun IIS). Kør Get-Item "RDS:\GatewayServer\SSLCertificate\Thumbprint" i PowerShell for at verificere. Sørg også for at TSGateway-tjenesten er genstartet efter certifikatændring.

NLA fejler bag gateway

NLA-autentificering sker mellem klient og RDP-server (ikke gateway). Klienten skal stole på RDP-serverens certifikat. I et domænemiljø: distribuer certifikatet via GPO. Uden domæne: importér root-certifikatet manuelt i klientens Trusted Root store.

Certifikat fornyet, men gateway bruger det gamle

RD Gateway cacher certifikatbindingen. Genstart TSGateway-tjenesten: Restart-Service TSGateway -Force. Tjek at post-fornyelse scriptet kører korrekt ved at se logfilerne i simple-acmes logmappe.

Relateret indhold

Simple-ACME guide

Komplet Windows-guide med DNS-validering, IIS og post-fornyelse scripts.

Windows ACME-opsætning

Generel Windows Server ACME-guide for IIS, Exchange, RDP og SQL Server.

Installationsservice

FairSSL installerer og konfigurerer certifikater for jer. Fast pris.

Ofte stillede spørgsmål om RDP og SSL

Find svar på de mest almindelige spørgsmål om SSL certifikater og FairSSL.

Kan jeg bruge et wildcard-certifikat til RD Gateway?

Ja, et wildcard-certifikat (f.eks. *.example.dk) virker fint til RD Gateway, RD Web Access og interne RDP-forbindelser, så længe alle hostnavne er under samme domæne. Det forenkler opsætningen, fordi ét certifikat dækker alt. Overvej dog sikkerhedsimplikationen: hvis wildcard-nøglen kompromitteres, er alle services under domænet påvirket.

Hvad er forskellen på RD Gateway og RD Web Access?

RD Gateway er en HTTPS-proxy der tunnelerer RDP-trafik (port 443). RD Web Access er en IIS-webapp der viser RemoteApp-ikoner og fuldskærms-desktops i browseren. Begge kræver SSL-certifikater, og begge kører typisk på samme server. RD Gateway bruger sit eget certifikatlager via RD Gateway Manager, mens RD Web Access bruger IIS HTTPS-binding.

Skal RDP-serverne bag gateway have offentlige certifikater?

Ikke nødvendigvis. RDP-sessioner bag gateway kan bruge interne certifikater eller selvunderskrevne certifikater, da klienten allerede har en krypteret forbindelse via gateway. Men for NLA (Network Level Authentication) skal klienten stole på RDP-serverens certifikat. I et Active Directory-miljø kan du distribuere et internt CA-certifikat via GPO.

Kan jeg automatisere certifikatfornyelse med simple-acme?

Ja. Brug simple-acme med DNS-validering og et post-fornyelse script der binder det nye certifikat til RD Gateway og IIS. Se simple-acme guiden for detaljer om scriptparametre.

NLA fejler med "The authentication was not successful"

NLA-fejl skyldes typisk at klienten ikke stoler på RDP-serverens certifikat. Tjek: (1) Er certifikatkæden komplet? (intermediate + leaf). (2) Matcher certifikatets hostname det navn klienten bruger? (3) Er certifikatet udløbet? (4) I domænemiljøer: er certifikatet distribueret via GPO til Personal-lageret på RDP-serveren?

Hvad er forskellen på DV og OV til RDP?

Til RD Gateway, der er eksponeret mod internet, anbefaler vi OV (Organisation Validation). OV viser virksomhedsnavnet i certifikatet, hvilket giver brugerne tillid til at de forbinder til den rigtige organisation. DV virker teknisk, men giver ingen virksomhedsidentifikation. Til interne RDP-servere bag gateway er certifikattypen mindre vigtig.

Sikr jeres Remote Desktop-miljø

Opret en gratis konto og udsted dit første certifikat på under 10 minutter.

Opret gratis konto Sammenlign certifikater