Oba server RD GW, IIS imaju veoma ograničenu mogućnost automatske izrade self-signed sertifikata. Ograničenje se odnosi na max. period trajanja sertifikata koji je u slučaju RD GW samo 6 meseci, dok IIS, uz pomoć CA Authority servisa, može da generiše sertifikat u trajanju od godinu dana. Niže je naveden postupak izrade takvog sertifikata. Ovo nije najsrećnije rešenje, savet je da se koristi Openssl program opisan niže.

Iako postoji Microsoft alat pod nazivm MakeCert (deo Windows SDK) on nije dovoljan za potpuno izvođenje ove operacije jer ne može da kreira KeyUsage svojstvo sertifikata.

Alat koji može da napravi potpun sertifikat proizvoljne dužine trajanja (više desetina godina) je Linuxov Openssl.

Komanda za izradu sertifikata koji (bi trebalo da) odgovara RemoteApps serverima je:

[12.03.2020 Milano] Bolje je koristiti Windows 10 način, sertifikat dobijen iz Linuxa umeda pravi problem sa nekim od potrebnih servisa za RemoteApp.

openssl req -x509 -config extended.conf -extensions v3_ca -nodes -sha512 -days 3650 -newkey rsa:4096 -keyout sertifikat.key -out sertifikat.crt

gde su:

extended.conf - fajl sa specijalnih podešavanjima, na primer ovakav skript
v3_ca - blok unutar skripta koji definiše extended svojstva sertifikata (specifična namena)
sertifikat.key - fajl u kome će se sačuvati privatni ključ sertifikata
sertifikat.crt - fajl u kome će se sačuvati kompajlirani sertifikat u crt formatu.

Kako crt format u Windows nije mnogo primenjiv, potrebno je konvertovati dobijent fajl u pfx format. To se postiže sledećom komandom:

openssl pkcs12 -export -out sertifikat.pfx -inkey sertifikat.key -in sertifikat.crt

gde je:

sertifikat.pfx - naziv pfx fajla u koji će sertifikat biti konvertovan.

Najbolji način da se napravi Windows RemoteApp kompatibilan sertifikat jeste upotreba PowerShell-a u Windows 10. Verzija je važna pošto veći deo opcija u prethodnim verzijama PS-a nije podržana.

Ako imamo W10 dovoljno je pokrenuti PS komandu

New-SelfSignedCertificate -Type Custom -Subject "CN=rap.leburickomerc.com" -KeyUsage DataEncipherment, KeyEncipherment, DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1") -CertStoreLocation "Cert:\CurrentUser\My" -NotBefore '2020-03-11' -NotAfter '2023-03-11'

Kako je pristup RD Web Acces i RD Gateway serverima upućen na kriptovane kanale neophodno je registrovati sertifikate na na nekoliko mesta u sistemu. Isti sertifikat važiće i za https stranicu za pristup sadržaju preko internet servera (https://moj.domen.rs/RDWeb/).

Sertifikati se unose u Deployment svojstva svih RDP servisa:

a postavke se vrše u okviru opcije Certificates

VAŽNA NAPOMENA ! Da bi sertifikat bio prihvaćen mora biti napravljen po zahtevu iz IIS-a ili RD Gateway servera. U principu, moguće je i ručno zadati request za ovo, ali ima mnogo parametara gde se može pogrešiti što rezultuje odbijanjem sertifikata.

Sertifikat se vezuje za port IIS-a opcijom binding u postavkama Default Web Site odeljka:

Ovde će biti reč o self signed sertifikatu, po principu “uradi sam”.

Alati: certlm (Manage computer certificates), IIS manager, Certification Authority rola. IIS i CA role se moraju prethodno instalirati.

Iako se zahtev za dobijanje sertifikata može zadati ručno, najlakše je (zbog mnošta parametara koje treba usaglasiti) izvesti zahtev iz IIS-a. To se radi iz aplikacije Server Certificates u okviru postavki samog IIS servera.

Jedino je važno je da se zahtevu dodeliCommon name = moj.domen.rs. Važno je zbog toga što će se pri pokretanju RDP-a na klijentskoj strani upoređivati ovo polje sa FQDN (adresa za pristup servisu), pa ako se ne slažu veza ne biva uspostavljena “iz sigurnosnih razloga”.

Još jedna postavka igra bitnu ulogu u formiranju buduće RDP prečice. To je parametar DefaultTSGateway koji treba da ukazuje na javnu adresu preko koje će klijenti pristupati servisu:

Odobravanje se vrši iz servisa Certificate Authority, role koji se dodaje pri instalaciji servera. Njegova uloga je da prati domenske sertifikate i odobrava/pravi nove.

Odobravanje se vrši opcijom Submit new request nakon čega se može odbrati req fajl dobijen na osnovu zahteva iz IIS-a.

Odobreni sertifikat se zatim prebacuje u certlm grupu Certificate Enrollment Requests odakle ga je potrebno exportovati u cer i pfx (sa privatnim ključem) falove. Pfx fajl se zatim importuje u Personal sertifikate (čime postaje vidljiv IIS-u). Fajl cer se potom uvozi u Truste Root Certification Authotrities kako bi IIS verovao Personal sertifikatu.

Pfx fajl se preko RD Deployment menadžera uvozi u 4 RD servisa iz gornjeg spiska.

Ovim je sve spremno za SSL pristup.

Jedan od težih kamenova spoticanja je upornost sistema da RDP prečicama dodeljuje lokalne putanje za pristup servisu (npr. umesto moj.domen.rs dobija se adresa ime.računara.local) što ih čini nedostupnim van LAN-a.

U RD Web Access serveru ovo jednostavno promeni jer je predviđeno rešenje upotreba RD Gateway servera. Nažalost to radi samo ako su RDP klijenti verzije 8.0 ili noviji.

Alternativno, moguće je pokrenuti skriptu u power shell prozoru koja ovo omogućava. Skripta se može skinuti odavde, a uputstvo za dozvolu pokretanja (ako je zabranjeno pokretati skripte, što je podrazumevana postavka Windows 2012) se nalazi ovde.