Avviso di sicurezza RDP a seguito dell'aggiornamento Windows Aprile 2026

Con l'aggiornamento Windows, documentato da Microsoft il 14 aprile 2026, l'apertura dei file `.rdp` è diventata più restrittiva. Al primo utilizzo compare un messaggio informativo sui rischi di phishing legati ai file RDP; successivamente, ad ogni apertura, viene mostrato un nuovo dialogo di sicurezza che indica il computer remoto e le risorse locali richieste, come clipboard, dischi, dispositivi o componenti di autenticazione, lasciandole disabilitate, di default, finché l'utente non le abilita esplicitamente. Se il file non è firmato digitalmente, compare anche l'indicazione di publisher sconosciuto.

Si tratta di una misura sensata dal punto di vista della sicurezza, ma in alcuni contesti può risultare fastidiosa o rallentare l'operatività quotidiana.

Come risolvere?

Non basta più "accettare il rischio" come in passato. Per presentare un publisher verificabile ed evitare il classico "Unknown publisher", la strada corretta è firmare digitalmente i file `.rdp` con un certificato trusted (dai client). Microsoft consiglia la procedura tramite rdpsign.

Un passo indietro

Se serve una soluzione rapida e temporanea, è possibile disabilitare il nuovo comportamento del client intervenendo sul registro di Windows. Da PowerShell, con diritti di amministratore:

---

set-itemproperty 'HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client' RedirectionWarningDialogVersion 1

---

L'equivalente `.reg` è:

---

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\Client]
"RedirectionWarningDialogVersion"=dword:00000001

---

In entrambi i casi si tratta di un rimedio temporaneo, utile magari come hotfix, non della soluzione migliore nel medio periodo.

Firmare file .rdp in una piccola LAN (senza complicazioni inutili)

Se si utilizzano file `.rdp` in una piccola rete (2-3 PC), una PKI completa o una CA pubblica sono spesso eccessive. In questi casi si può adottare un approccio molto più semplice: creare un certificato self-signed su un PC, esportarne la parte pubblica ed installarla come attendibile sugli altri computer.

Creare il certificato

Su uno dei PC, da PowerShell eseguito come amministratore:

---

$cert = New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=RDP Signing" -CertStoreLocation "Cert:\CurrentUser\My"

---

Il certificato viene salvato nello store personale dell'utente corrente. La chiave privata resta su questa macchina.

 

Esportare il certificato

---

Export-Certificate -Cert $cert -FilePath "C:\temp\rdp-signing.cer"

---

A questo punto si può copiare  `rdp-signing.cer` sugli altri computer.

Rendere attendibile il certificato

Su tutti i PC, incluso quello che firma, il certificato va installato nello store del Computer locale e copiato in due contenitori: Trusted Root Certification Authorities.

Lo si può fare con doppio click sul file `.cer` e procedura guidata, oppure da riga di comando:

---

certutil -addstore "Root" rdp-signing.cer
certutil -addstore "TrustedPublisher" rdp-signing.cer

---

Questo passaggio è fondamentale: senza attendibilità lato client, la firma non elimina l'avviso sul publisher.

Firmare i file `.rdp`

Sul PC che possiede il certificato con chiave privata si usa rdpsign.exe:

---

rdpsign /sha256 <thumbprint> file.rdp

---

Il thumbprint si ricava, sul PC che firma, con:

---

$cert.Thumbprint

---

Il thumbprint serve solo sul PC che firma. Sugli altri computer non serve per firmare nulla: lì viene installato solo il certificato pubblico, usato per verificare la firma. In altre parole, i client controllano l'identità del publisher e l'integrità del file, ma non hanno accesso alla chiave privata.

Verifica finale

Sul PC "client" aprire `certlm.msc` e controllare che il certificato sia presente in: Trusted Root e Trusted Publishers.

Per scenari più ampi bisogna ricorrere ad una PKI interna (es. Active Directory Certificate Services) oppure ad un certificato pubblico.

Verificare ed aggiornare i certificati Secure Boot in Windows

L'avvio protetto (Secure Boot) è una funzionalità UEFI per garantire che il sistema operativo venga avviato solo utilizzando bootloader e componenti firmati / considerati affidabili. Alla base di questo meccanismo c'è un insieme di certificati e chiavi memorizzati nel firmware UEFI e, in parte, gestiti anche da Windows.

In alcune situazioni, ad esempio dopo aggiornamenti di sicurezza critici, cambi di hardware o problemi di compatibilità con driver, può essere utile verificare lo stato dei certificati secure boot e, se necessario, forzarne l'aggiornamento via linea di comando.

 

Attenzione alla scadenza dei certificati Secure Boot

Microsoft ha annunciato che i certificati originali usati per Secure Boot (come quelli del 2011) inizieranno a scadere a partire da giugno 2026. Se un sistema non dispone dei certificati aggiornati, non potrà più ricevere aggiornamenti di sicurezza o fidarsi di firme future. Per questo motivo è importante verificare non solo che l'avvio protetto sia abilitato, ma anche che i certificati correnti siano aggiornati e correttamente installati.

 

Prerequisiti

Prima di procedere, bisogna assicurarsi che:

• il sistema utilizzi UEFI (non BIOS legacy);
• l'avvio protetto sia abilitato nel firmware;
• i comandi vengano eseguiti come Amministratore;
• Windows sia Windows 10 o Windows 11.

in caso contrario... non c'è bisogno di far niente. 

Se invece siamo costretti a lavorare... iniziamo con PowerShell e:

Confirm-SecureBootUEFI

i possibili risultati sono:

• True → l'avvio protetto è attivo;
• False → l'avvio protetto è disattivato;
• Errore → il sistema non usa UEFI (olé).

Questo comando non verifica i certificati in dettaglio, ma è un prerequisito fondamentale.

Uno strumento di sistema che verifica parzialmente lo stato dei database correlati all'avvio protetto è `msinfo32`. Una volta avviato bisogna controllare le voci:

• "Modalità BIOS", deve essere UEFI;
• "Stato avvio protetto", Attivo.

Verificare lo stato dell'aggiornamento dei certificati Microsoft

Microsoft distribuisce aggiornamenti ai database secure boot (in particolare dbx, la lista di revoca) tramite Windows Update. Per verificare se il sistema ha applicato gli aggiornamenti più recenti, possiamo ricorrere a PowerShell:

Get-HotFix | Where-Object {$_.Description -like "*Security*"}

Gli aggiornamenti secure boot più rilevanti (come quelli legati alle vulnerabilità dei bootloader) vengono spesso distribuiti come aggiornamenti di sicurezza cumulativi, quindi non sono sempre immediatamente riconoscibili (!) come riguardanti l'avvia protetto.
Questo significa che non esiste un KB "magico" da cercare. L'aggiornamento dei certificati avviene come parte del normale ciclo di patch di sicurezza di Windows.

Forzare l'aggiornamento dei certificati Secure Boot

Il metodo consigliato e supportato rest Windows Update. È la strada più sicura. Dalla riga di comando:

wuauclt /detectnow
wuauclt /updatenow

Sulle versioni più recenti di Windows, è preferibile:

usoclient StartScan
usoclient StartDownload
usoclient StartInstall

Dopo l'installazione, riavviare il sistema: gli aggiornamenti ai database UEFI vengono applicati solo durante il boot.

Verificare eventuali errori legati a Secure Boot

Se si sospettano problemi con certificati o revoche, si può controllare il registro eventi (eventvwr.msc) in particolare visualizzando:

Registri applicazioni e servizi
└── Microsoft
    └── Windows
        └── Secure-Boot

Errori o avvisi in questa sezione possono indicare bootloader bloccati, firme non valide o conferme dell'avvenuto aggiornamento del database `dbx`.

La scadenza dei certificati, cosa controllare davvero

Windows non fornisce un comando diretto per elencare i certificati UEFI con data di scadenza, perché questi risiedono nel firmware. Tuttavia è possibile verificare se il sistema è già pronto per i nuovi certificati tramite controlli indiretti.

Un primo indizio utile è la versione del boot manager (`bootmgfw.efi`), che viene aggiornata solo se il sistema è pronto ad usare i nuovi certificati:

Get-Item "C:\Windows\Boot\EFI\bootmgfw.efi" | Select-Object VersionInfo

Bisogna osservare `ProductVersion`, `FileVersion` e `Data di compilazione`.

Versioni aggiornate tramite patch di sicurezza dal 2023 in poi indicano che il sistema è compatibile con i certificati più recenti.

Microsoft sta distribuendo gli aggiornamenti in più fasi, proprio per evitare sistemi non avviabili. Un sistema che non riceve più aggiornamenti o è fermo a build molto vecchie rappresenta un segnale critico.

Un ultimo dettaglio pratico: gli aggiornamenti al secure boot possono richiedere la chiave BitLocker al riavvio. È normale e previsto (cambia la "catena di fiducia" del boot). Prima di procedere assicurarsi sempre di avere la chiave di ripristino BitLocker disponibile.

Domande frequenti su https, SSL e certificati digitali

HTTPS - Cos'è e perché ha assunto una maggiore importanza?

I certificati digitali SSL sono protocolli con la funzione di cifrare i dati che vengono scambiati fra il sito ed i visitatori, impedendo così ad occhi indiscreti di carpire informazioni.

Perché attivare un certificato SSL?

Sebbene i certificati digitali garantiscano un maggior livello di protezione, credibilità e controllo, salvo situazioni specifiche (banche, ecommerce…), fino ad oggi la loro adozione avveniva, di fatto, per questione di immagine. A partire da fine luglio 2018 Google Chrome ha cominciato a visualizzare i siti privi di certificati SSL come non sicuri:

Le prossime versioni di Chrome evidenzieranno ulteriormente la situazione:

Mentre per i siti con certificato digitale si avrà:

Questo cambiamento indurrà i visitatori a diffidare dei siti privi di certificati digitali. Oltretutto lo stesso motore di ricerca di Google verrà modificato introducendo penalizzazioni per i siti non sicuri.

Cosa fare?

Il mancato adeguamento potrebbe comportare importanti conseguenze circa il posizionamento su Google. Sarebbe opportuno installare, entro il 2018 un certificato digitale sul proprio sito per non perdere competitività rispetto alla concorrenza.

Quanto costa?

Esistono svariate tipologie di certificati digitali, da quelli gratuiti, a quelli a pagamento con prezzi variabili fra i 30 ed i 260 euro. La tipologia migliore va valutata caso per caso.

Se decido di installare un certificato SSL devo informare i clienti / cambiare indirizzo

No l'operazione è trasparente per gli utenti. Sia collegandosi all'indirizzo www.miosito.it che a http://www.miosito.it si viene automaticamente reindirizzati a https://www.miosito.it.