SSL-certifikat får vara giltiga i högst 199 dagar. Senast 2027-03-15 blir gränsen 99 dagar, för DigiCert-certifikat redan från 2027-02-24. Läs mer →
Svensk support på svenska, vardagar 10:00-16:00 +46 10 101 03 34 info@fairssl.se

RDP och RD Gateway: installera SSL-certifikat

Remote Desktop Gateway använder HTTPS för att tunnla RDP-trafik säkert över internet. Den här guiden går igenom certifikatkraven, automatisk konfiguration med simple-acme, manuell installation med PowerShell, Server Manager och RD Gateway Manager, distribution via GPO till RDP-servrar och felsökning.

Versioner som stöds

Remote Desktop ServicesVersionerRD Gateway (även utan RD Connection Broker), RD Web Access, RD Web Client, RD Connection Broker och RDP-lyssnarenKörs påWindows Server 2012 eller senareACME-klientsimple-acme 2.4.0+ (FairSSL-utgåvan, .NET 10 ingår) + ImportRDSFullFairSSL.ps1

Arkitektur

En typisk Remote Desktop-miljö med gateway består av komponenter som var och en behöver ett certifikat:

Internetklient

MSTSC / Remote Desktop

RD Gateway

HTTPS (port 443)

Publikt certifikat

RD Web Access

IIS (port 443)

Publikt certifikat

RDP-servrar

Internt nätverk

Internt eller publikt certifikat

RD Gateway och RD Web Access körs vanligtvis på samma server.

Certifikatkrav

Komponent Certifikattyp Värdnamn Anmärkning
RD Gateway Publikt (DV/OV) rdp.example.se Nås från internet, kräver certifikat från en publik CA
RD Web Access Publikt (DV/OV) rdp.example.se Samma värdnamn som gatewayen (bindning i IIS)
RDP-servrar Internt / publikt server01.intern.se Används endast för NLA-autentisering

Konfiguration med simple-acme

Simple-acme automatiserar certifikatets hela livscykel: utfärdande, installation i certifikatlagret i Windows, bindning i IIS och bindning till alla RDP-tjänster. Det medföljande skriptet ImportRDSFullFairSSL.ps1 uppdaterar RD Gateway, RD Connection Broker, RD Web Access och RDP-lyssnaren automatiskt vid varje förnyelse.

Kommando för simple-acme

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

Vad händer automatiskt?

När simple-acme körs (manuellt eller via Task Scheduler) utför programmet följande steg:

  1. 1 Utfärdar eller förnyar certifikatet via ACME med DNS-01-validering
  2. 2 Importerar certifikatet till certifikatlagret i Windows (Cert:\LocalMachine\My)
  3. 3 Uppdaterar HTTPS-bindningen i IIS (--installation iis)
  4. 4 Kör ImportRDSFullFairSSL.ps1, som binder certifikatet till RD Gateway, RD Connection Broker, RD Web Access och RDP-lyssnaren och startar om berörda tjänster

Viktiga inställningar i settings.json

Ställ in följande i settings.json för simple-acme (eller i settings_default.json):

  • Store.CertificateStore.PrivateKeyExportable till true (krävs för RDP-tjänsterna)
  • ScheduledTask.RenewalMinimumValidDays till 15 (förnya senast 15 dagar innan certifikatet går ut)

DNS-validering med FairSSL AutoDNS

Om du inte har API-åtkomst till din DNS-leverantör kan du använda FairSSL AutoDNS i stället för Cloudflare. Skapa en CNAME-post en gång, så sköter FairSSL DNS-valideringen automatiskt därefter:

# DNS: engångskonfiguration av CNAME
_dnsauth.example.se  CNAME  ditt-unika-id.autodns.fairssl.dk.

Se simple-acme-guiden för fullständig dokumentation av skriptparametrarna och konfigurationen i Task Scheduler.

Installera certifikatet manuellt

Utan simple-acme beror det på miljön var du installerar certifikatet:

Miljö Metod Windows Server i Microsofts dokumentation
En server med Remote Desktop som inte ingår i en RDS-driftsättning 1. RDP-lyssnaren via WMI Versioner som stöds; wmic visas för 2012 R2 och äldre, PowerShell för 2025
RDS-driftsättning med RD Connection Broker 2. Server Manager eller 4. Set-RDCertificate 2016, 2019, 2022, 2025
Fristående RD Gateway 3. RD Gateway Manager 2016, 2019, 2022, 2025

Stegen och kommandona följer Microsoft Learn, och varje underavsnitt länkar till sidan det bygger på. Ersätt THUMBPRINT med certifikatets tumavtryck och värdnamnen med dina egna.

1. RDP-lyssnaren på en server (Win32_TSGeneralSetting)

RDP-lyssnaren hittar sitt certifikat via tumavtrycket i egenskapen SSLCertificateSHA1Hash i WMI-klassen Win32_TSGeneralSetting i namnrymden Root\CimV2\TerminalServices. Microsoft beskriver metoden för en server som inte ingår i en RDS-driftsättning.

  1. 1 Importera certifikatet med den privata nyckeln till arkivet Personal för datorkontot (certlm.msc). Om det inte finns där misslyckas kommandot i steg 4 med Invalid Parameter.
  2. 2 Öppna certifikatet, välj fliken Details och kopiera värdet i Thumbprint. Ta bort alla mellanslag. På Windows Server 2012 R2 och äldre kan det kopierade värdet innehålla ett osynligt tecken; klistra in det i en kommandotolk för att se tecknet, och ta bort det.
  3. 3 Ge NETWORK SERVICE läsbehörighet till den privata nyckeln, eftersom Remote Desktop körs under det kontot. I certlm.msc: expandera Personal, högerklicka på certifikatet, välj All Tasks → Manage Private Keys, välj Add, skriv NETWORK SERVICE, välj OK, markera Read under Allow och välj OK.
  4. 4 Ange tumavtrycket för lyssnaren med Windows PowerShell:
Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices | Set-WmiInstance -Arguments @{SSLCertificateSHA1Hash="THUMBPRINT"}

Kör kommandot i Windows PowerShell 5.1 (powershell.exe), eftersom Get-WmiObject och Set-WmiInstance är borttagna i PowerShell 7 (pwsh.exe). För Windows Server 2012 och 2012 R2 visar Microsoft samma ändring med wmic i en kommandotolk:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

Microsoft har markerat wmic som föråldrat (deprecated) från och med Windows Server 21H1 och hänvisar till PowerShell i stället.

Kontrollera resultatet genom att läsa klassen med enbart Get-WmiObject. SSLCertificateSHA1Hash ska visa ditt tumavtryck och SSLCertificateSHA1HashType ska vara 3 (Custom). 1 betyder att lyssnaren fortfarande använder det självsignerade standardcertifikatet.

Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices

Källor: Remote Desktop listener certificate configurations ↗, Win32_TSGeneralSetting class ↗, wmic ↗, Get-WmiObject (PowerShell 5.1) ↗, Differences between Windows PowerShell 5.1 and PowerShell 7.x ↗ (Microsoft Learn).

2. RDS-driftsättning via Server Manager

I en RDS-driftsättning med RD Connection Broker anger du certifikaten för hela driftsättningen. Server Manager importerar certifikatet på alla servrar i driftsättningen och binder det till deras roller. Certifikatet ska vara utfärdat för Server Authentication, vara betrott av både servrar och klienter och ha en privat nyckel som kan exporteras. Du behöver det som en .pfx-fil med den privata nyckeln och tillhörande lösenord.

  1. 1 Välj Remote Desktop Services i den vänstra rutan i Server Manager. På fliken Overview, under Deployment Overview, väljer du TASKS → Edit Deployment Properties.
  2. 2 Välj Certificates. Tabellen visar rolltjänsterna RD Gateway, RD Web Access och de två rolltjänsterna för RD Connection Broker (Enable Single Sign On och Publishing).
  3. 3 Välj en rolltjänst och sedan Select existing certificate. Välj Browse, öppna .pfx-filen och ange lösenordet.
  4. 4 Markera Allow the certificate to be added to the Trusted Root Certification Authorities certificate store on the destination computers och välj OK.
  5. 5 Välj Apply och vänta tills certifikatet har tillämpats. Upprepa steg 3 till 5 för varje rolltjänst.

I Microsofts driftsättningsguide använder RD Gateway och RD Web Access det externa FQDN:et, och de två rolltjänsterna för RD Connection Broker använder det interna FQDN:et för RD Connection Broker-servern. Efter ett certifikatbyte kan du behöva starta om tjänsten TSGateway manuellt på varje RD Gateway-server. För RDP-lyssnaren på RD Session Host-servrarna hänvisar Microsoft till metoden i underavsnitt 1.

Källor: Use certificates in Remote Desktop Services ↗, Deploy your Remote Desktop environment ↗, Add high availability to the RD Web and Gateway web front ↗ (Microsoft Learn).

3. RD Gateway Manager

Importera certifikatet på gatewayservern i RD Gateway Manager:

  1. 1 Välj Remote Desktop Services → Servers i Server Manager. Högerklicka på servern och välj RD Gateway Manager.
  2. 2 Högerklicka på namnet på RD Gateway-servern i den vänstra rutan och välj Properties.
  3. 3 På fliken SSL Certificate väljer du Import a certificate into the RD Gateway och sedan Browse and Import Certificate.
  4. 4 Välj .pfx-filen, välj Open och ange lösenordet. Fliken visar sedan certifikatets uppgifter.

Microsoft rekommenderar ett offentligt utfärdat certifikat på RD Gateway, eftersom klienterna ansluter utifrån. Med ett certifikat från en privat CA måste alla klienter lita på kedjan i förväg.

Källa: Deploy the Remote Desktop Gateway role ↗ (Microsoft Learn).

4. Set-RDCertificate (PowerShell)

Set-RDCertificate i modulen RemoteDesktop importerar ett certifikat, eller tillämpar ett redan installerat, för en RDS-roll. Kör den i en PowerShell-session som körs som administratör på en dator med RDS-administrationsverktygen (RSAT) och den roll du konfigurerar. -Role tar RDGateway, RDWebAccess, RDRedirector eller RDPublishing; kör kommandot en gång för varje roll du använder. Utan -ConnectionBroker använder kommandot den lokala datorns FQDN.

Importera en .pfx-fil. Microsofts exempel anger RDWebAccess; ersätt PathToPFXFile med den fullständiga sökvägen till filen och ändra Role för de andra rollerna:

$password = Read-Host -AsSecureString -Prompt "Enter Password"
$parameters = @{
  Role        = "RDWebAccess"
  Password    = $password
  ImportPath  = "PathToPFXFile"
}
Set-RDCertificate @parameters

Använd ett certifikat som redan är installerat (Windows Server 2019 och senare). Microsofts exempel anger RDRedirector. Certifikatet måste finnas i LocalMachine\My på varje server som kör rollen:

Set-RDCertificate -Role RDRedirector -Thumbprint THUMBPRINT -ConnectionBroker "rdcb.intern.se"

Kontrollera resultatet. Get-RDCertificate visar subject, tumavtryck, utgångsdatum och nivå för varje roll; ett offentligt certifikat har nivån Trusted.

Get-RDCertificate -ConnectionBroker "rdcb.intern.se"

Källor: Set-RDCertificate ↗, Get-RDCertificate ↗, Use certificates in Remote Desktop Services ↗ (Microsoft Learn).

GPO-distribution (Active Directory)

Det här avsnittet gäller bara om RDP-servrarna är Windows-servrar som är anslutna till en Active Directory-domän. Med Group Policy kan du konfigurera RDP-lyssnaren och NLA-kraven centralt:

  1. 1 Öppna Group Policy Management Console och skapa en ny GPO för RDP-servrarna.
  2. 2 Gå till Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security.
  3. 3 Aktivera Server Authentication Certificate Template och ange certifikatmallen från din interna CA, eller använd Require use of specific security layer for remote (RDP) connections inställd på SSL.
  4. 4 Ställ in Require user authentication for remote connections by using NLA på Enabled för att kräva NLA.

För RDP-servrar bakom gatewayen fungerar certifikat från en intern CA bra. Distribuera rotcertifikatet via GPO till lagret Trusted Root Certification Authorities på klienterna. Då litar alla domänanslutna klienter automatiskt på RDP-servrarnas certifikat.

Hosts-filen: samma FQDN för gateway och intern RDP-server

RD Gateway och RDP-servern använder ofta samma publika FQDN (t.ex. rdp.example.se). Klienten ansluter till gatewayen via publik DNS, och gatewayen ska sedan vidarebefordra trafiken till den interna RDP-servern. Gatewayen kan dock inte slå upp rdp.example.se till den interna servern, eftersom den publika DNS-posten pekar på gatewayen själv.

Lägg därför till en rad i hosts-filen på gateway-servern:

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

Då slår gatewayen upp rdp.example.se till den interna IP-adressen (10.0.1.50) och vidarebefordrar RDP-trafiken dit. Klienten ser bara rdp.example.se och behöver inte känna till den interna IP-adressen.

Metoden kräver att RDP-servern tar emot anslutningar på värdnamnet rdp.example.se. Om RDP-servern använder NLA måste dess certifikat vara utfärdat för rdp.example.se eller innehålla namnet som SAN. Med ett wildcard-certifikat (*.example.se) på båda servrarna är det kravet uppfyllt.

Felsökning

"The remote computer could not be authenticated"

Klienten litar inte på certifikatet. Kontrollera: (1) Är certifikatkedjan komplett (mellanliggande certifikat och servercertifikat)? (2) Stämmer värdnamnet i certifikatet med det värdnamn klienten ansluter till? (3) Har certifikatet gått ut? Använd SSL Scanner för att kontrollera.

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

Oftast ett certifikatproblem på gatewayen. Kontrollera att certifikatet är bundet i RD Gateway Manager (inte bara i IIS). Kör Get-Item "RDS:\GatewayServer\SSLCertificate\Thumbprint" i PowerShell för att kontrollera. Se också till att tjänsten TSGateway har startats om efter certifikatbytet.

NLA misslyckas bakom gatewayen

NLA-autentiseringen sker mellan klienten och RDP-servern (inte gatewayen). Klienten måste lita på RDP-serverns certifikat. I en domänmiljö distribuerar du certifikatet via GPO. Utan domän importerar du rotcertifikatet manuellt till lagret Trusted Root Certification Authorities på klienten.

Certifikatet är förnyat men gatewayen använder det gamla

RD Gateway cachar certifikatbindningen. Starta om tjänsten TSGateway: Restart-Service TSGateway -Force. Kontrollera att skriptet som körs efter förnyelsen fungerar genom att läsa loggfilerna i loggmappen för simple-acme.

Certifikat på många servrar och appliances

Ett offentligt SSL-certifikat får vara giltigt i högst 199 dagar nu, 99 dagar senast 2027-03-15 och 46 dagar senast 2029-03-15. Varje certifikat måste då bytas minst två gånger om året nu och minst åtta gånger om året från 2029, på varje server, brandvägg och lastbalanserare där det används. sslbrain från FairSSL körs som en appliance i ert eget nätverk och förnyar och installerar certifikaten från ett ställe, även på utrustning utan agent.

Så förnyar och installerar sslbrain certifikat på Remote Desktop (RDP)(öppnar sslbrain.com i en ny flik)

Vanliga frågor om RDP och SSL-certifikat

Hitta svar på de vanligaste frågorna om SSL-certifikat och FairSSL.

Ja, ett wildcard-certifikat (t.ex. *.example.se) fungerar för RD Gateway, RD Web Access och interna RDP-anslutningar, så länge alla värdnamn ligger under samma domän. Konfigurationen blir enklare när ett enda certifikat täcker alla namn. Nackdelen är att alla tjänster under domänen påverkas om den privata nyckeln till wildcard-certifikatet komprometteras.
RD Gateway är en HTTPS-proxy som tunnlar RDP-trafik (port 443). RD Web Access är en webbapp i IIS som visar RemoteApp-ikoner och fullständiga skrivbord i webbläsaren. Båda kräver SSL-certifikat och körs vanligtvis på samma server. RD Gateway väljer sitt certifikat i RD Gateway Manager, medan RD Web Access använder HTTPS-bindningen i IIS.
Nej, inte nödvändigtvis. RDP-sessioner bakom gatewayen kan använda interna eller självsignerade certifikat, eftersom klienten redan har en krypterad anslutning via gatewayen. För NLA (Network Level Authentication) måste klienten dock lita på RDP-serverns certifikat. I en Active Directory-miljö kan du distribuera rotcertifikatet från en intern CA via GPO.
Ja. Använd simple-acme med DNS-validering och ett skript som körs efter förnyelsen och binder det nya certifikatet till RD Gateway och IIS. Se simple-acme-guiden för detaljer om skriptparametrarna.
NLA-fel beror oftast på att klienten inte litar på RDP-serverns certifikat. Kontrollera: (1) Är certifikatkedjan komplett (mellanliggande certifikat och servercertifikat)? (2) Stämmer värdnamnet i certifikatet med det namn klienten använder? (3) Har certifikatet gått ut? (4) I domänmiljöer: har certifikatet distribuerats via GPO till lagret Personal på RDP-servern?
För RD Gateway, som nås från internet, rekommenderar vi OV (organisationsvaliderat certifikat). OV visar företagsnamnet i certifikatet, så att användarna kan se vilken organisation de ansluter till. DV fungerar tekniskt men identifierar inte företaget. För interna RDP-servrar bakom gatewayen spelar certifikattypen mindre roll.

Säkra din Remote Desktop-miljö

Skapa ett gratis konto och beställ ditt första certifikat. Ett DV-certifikat utfärdas på under 2 minuter.