10 10/10/2026 9 min

Quando SQL Server mostra un certificato scaduto

Il caso tipico non è “SQL Server non parte”, ma una connessione che fallisce perché il motore o il client insiste su un certificato TLS non più valido. In ambiente Microsoft questo capita spesso dopo un rinnovo dimenticato, una sostituzione del certificato lato sistema operativo non propagata alla configurazione di SQL Server, oppure quando un listener, un gateway o un driver client è stato impostato per trust server certificate in modo troppo permissivo e qualcuno ha poi irrigidito la validazione.

Il punto da chiarire subito è quale certificato è davvero scaduto: quello usato da SQL Server per il canale cifrato, quello presentato da un endpoint intermedio, oppure un certificato client in scenari di autenticazione mutua. La diagnosi cambia molto, ma la verifica iniziale è la stessa: capire quale layer sta fallendo, osservare il messaggio esatto e intervenire con la modifica minima reversibile.

Dove guardare per primo

Se il problema è davvero lato SQL Server, il motore registra spesso un errore di startup o di negoziazione TLS nei log del servizio. Il file da controllare è tipicamente il log errori di SQL Server, insieme al Visualizzatore eventi di Windows. Il punto utile non è leggere tutto, ma cercare righe che citano certificate, expired, TLS, SSPI o Schannel.

Una verifica rapida lato sistema operativo è controllare i certificati presenti nello store di macchina e confrontarne scadenza, uso previsto e thumbprint. Se il certificato non è più valido, ma SQL Server continua a puntarci, hai trovato la causa più probabile.

Verifica rapida dello stato del servizio

Dal server SQL, apri PowerShell come amministratore e verifica lo stato del servizio e i log recenti:

Get-Service -Name MSSQLSERVER
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.Message -match 'certificate|TLS|Schannel|expired' } | Select-Object TimeCreated, Id, ProviderName, Message

Se l’istanza è nominata, sostituisci MSSQLSERVER con il nome del servizio, ad esempio MSSQL$NOMEISTANZA. L’atteso è un servizio Running e nessun evento recente che indichi fallimento nella validazione del certificato. Se trovi eventi Schannel o errori di binding TLS, la pista è concreta.

Identificare il certificato usato da SQL Server

SQL Server non usa automaticamente “il certificato più nuovo” nello store. Usa il certificato configurato nell’SQL Server Configuration Manager oppure, in assenza di una scelta esplicita, un certificato che soddisfi i requisiti di nome, scopo e chiave privata. Per questo un certificato rinnovato può esistere nello store e non essere comunque in uso.

Apri SQL Server Configuration Manager, vai in SQL Server Network Configuration, poi in Protocols for <istanza> e controlla la scheda del certificato. Se il certificato è selezionato lì, annota il thumbprint e confrontalo con lo store locale. Se non è selezionato, SQL Server può stare usando un certificato diverso da quello che pensi, oppure nessun certificato valido per il canale cifrato.

Per vedere i certificati locali con PowerShell e la data di scadenza:

Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, NotAfter, Thumbprint, EnhancedKeyUsageList |
Sort-Object NotAfter

Il controllo minimo è semplice: il certificato che SQL Server usa deve avere data NotAfter futura, chiave privata presente e scopo adatto all’autenticazione server. Se il certificato è scaduto, il problema è confermato. Se non è scaduto, passa alla verifica di binding e trust chain.

Cause più probabili, in ordine pratico

In questo tipo di incidente le cause ricorrenti sono poche e abbastanza prevedibili. Le più frequenti sono tre.

  1. Certificato scaduto ma ancora selezionato in SQL Server Configuration Manager.
  2. Certificato valido ma non compatibile con SQL Server: manca la chiave privata, EKU errato, nome soggetto non coerente, store sbagliato.
  3. Catena di fiducia rotta o incompleta, quindi il certificato è valido ma non viene considerato affidabile da server o client.

La falsificazione rapida di queste ipotesi richiede pochi minuti. Se cambiando temporaneamente il certificato selezionato con uno sicuramente valido il servizio riparte, la causa era il binding. Se il certificato è valido ma i client continuano a rifiutarlo, il problema è nella chain o nella configurazione del client. Se nessun certificato risulta selezionabile, il problema è nello store o nei permessi della chiave privata.

Verifiche immediate lato client

Dal lato client, il sintomo più comune è un errore di handshake o di validazione del certificato, spesso mascherato come problema di connessione generico. È utile provare una connessione con un client che mostri meglio l’errore, ad esempio sqlcmd, oppure da SSMS con opzioni esplicite sul cifrato.

Un test base con sqlcmd può evidenziare subito se il problema è di validazione TLS:

sqlcmd -S tcp:SERVER\ISTANZA -Q "SELECT @@VERSION" -N -C

Qui -N forza la cifratura e -C indica di fidarsi del certificato del server. Se con -C la connessione funziona ma senza fallisce, il certificato o la chain non sono considerati affidabili dal client. Questo non risolve il problema, ma conferma il layer.

Se invece la connessione fallisce anche con trust forzato, il problema potrebbe essere più basso: servizio non in ascolto, firewall, nome istanza errato, endpoint sbagliato o problema Schannel sul server.

Soluzione consigliata passo-passo

La correzione più sicura è sostituire il certificato scaduto con uno nuovo, verificare la catena e riavviare solo l’istanza interessata. Evita di cambiare più variabili insieme: prima fai funzionare il servizio con il minimo intervento, poi sistemi la parte strutturale.

  1. Prepara un certificato valido con nome corretto per il server, chiave privata esportabile se serve migrazione, EKU “Server Authentication” e chain completa. Se il certificato arriva da una CA interna, assicurati che la CA radice e le intermedie siano distribuite correttamente.
  2. Conferma la presenza della chiave privata nello store di macchina. In MMC, il certificato deve mostrare il simbolo della chiave. Se manca, SQL Server non lo userà correttamente.
  3. Apri SQL Server Configuration Manager e seleziona il nuovo certificato nella scheda del protocollo della singola istanza. Non farlo dal certificato store a mano se puoi evitarlo: Configuration Manager è il punto giusto per il binding dell’istanza.
  4. Controlla il flag “Force Encryption”. Se è abilitato e il client non è pronto, potresti avere un impatto più ampio del previsto. Lascialo attivo solo se il certificato è corretto e la chain è affidabile.
  5. Riavvia solo il servizio dell’istanza, non l’intero server, salvo necessità. Il blast radius deve restare limitato all’istanza SQL coinvolta.

Se preferisci una verifica via PowerShell sul certificato prima del cambio, puoi controllare scadenza e uso:

Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.Subject -like '*NOME-SERVER*' } |
Select-Object Subject, NotAfter, Thumbprint, HasPrivateKey

Il valore HasPrivateKey deve essere True. Se è False, quel certificato non è adatto al binding di SQL Server anche se la data di scadenza è futura.

Se devi installare un nuovo certificato da file PFX, fai attenzione ai permessi della chiave privata. Dopo l’import, SQL Server deve poter leggere la chiave. In ambienti hardenizzati il servizio gira con account dedicati e non sempre eredita i permessi giusti. La correzione tipica è assegnare il diritto di lettura al service account sulla chiave privata, non abbassare i controlli globali del sistema.

Snippet operativo per import con PowerShell

Se hai un PFX e devi solo portarlo nello store macchina, la procedura base è questa:

Import-PfxCertificate -FilePath C:\temp\sqlserver.pfx -CertStoreLocation Cert:\LocalMachine\My

Dopo l’import, verifica subito NotAfter, Thumbprint e HasPrivateKey. Non fermarti all’import riuscito: un certificato importato non è automaticamente un certificato utilizzabile da SQL Server.

Quando il certificato non è il vero problema

Ci sono casi in cui il messaggio parla di certificato scaduto, ma il guasto reale è altrove. Succede soprattutto quando la data del server è sballata, la catena di trust è corrotta oppure il client sta usando un driver vecchio che negozia male TLS 1.2 o superiore.

Per escludere l’orologio, confronta data e ora del server con una fonte affidabile:

w32tm /query /status

Se l’orologio di sistema è avanti o indietro di giorni, un certificato apparentemente valido può risultare scaduto o non ancora valido. Questa è una verifica semplice ma spesso trascurata. Se trovi drift, correggi prima la sincronizzazione temporale e poi rivaluta il certificato.

Per la chain, controlla che la CA radice e le intermedie siano presenti nei rispettivi store. Se il certificato server è nuovo ma il client non si fida della CA, la connessione fallirà comunque. In ambienti enterprise è normale che il certificato sia tecnicamente corretto ma non distribuito in modo coerente su tutte le macchine client.

Verifiche finali dopo la correzione

Dopo il riavvio del servizio, non limitarti a vedere che il processo è “Running”. Fai tre controlli minimi:

  1. Il log di SQL Server non deve mostrare errori TLS o di certificato all’avvio.
  2. La connessione da un client reale deve riuscire senza usare eccezioni temporanee come -C o trust forzato, salvo scelta consapevole e documentata.
  3. La data di scadenza del certificato selezionato deve essere futura e coerente con il piano di rinnovo.

Un controllo utile è aprire una sessione e verificare che la connessione sia cifrata. Puoi interrogare la sessione corrente con una query che espone informazioni di connessione, oppure usare strumenti di diagnostica del lato client. L’obiettivo è vedere che il canale TLS sia effettivamente attivo e non solo “accettato per tolleranza”.

Se hai applicato un certificato nuovo e tutto funziona, documenta il thumbprint, il subject, la data di scadenza e il percorso di rinnovo. Questo evita il classico incidente ripetuto a distanza di mesi, quando il certificato è di nuovo in scadenza ma nessuno ricorda dove sia stato configurato.

Rollback sicuro se qualcosa va storto

Il rollback deve essere immediato e limitato. Se il nuovo certificato introduce errori, torna al certificato precedente ancora valido, oppure rimuovi temporaneamente il binding e ripristina la configurazione nota funzionante. Non cancellare il vecchio certificato finché il nuovo non è stabilmente in uso e verificato dai client.

Se hai modificato solo il binding in Configuration Manager, il rollback consiste nel rimettere il thumbprint precedente e riavviare il servizio dell’istanza. Se hai toccato permessi sulla chiave privata, conserva una nota precisa delle ACL precedenti per ripristinarle senza tentativi casuali.

Assunzione operativa: l’istanza SQL è in produzione e ogni modifica va trattata come potenzialmente impattante per gli utenti fino a verifica completata.

Checklist rapida da usare in campo

Se devi chiudere l’incidente velocemente, questa sequenza copre il 90% dei casi:

  1. Controlla log SQL Server e Event Viewer per errori TLS o certificato.
  2. Verifica scadenza, thumbprint e HasPrivateKey nel store macchina.
  3. Conferma il binding nel SQL Server Configuration Manager.
  4. Rinnova o sostituisci il certificato con uno valido e coerente con il nome server.
  5. Riavvia solo l’istanza interessata.
  6. Testa la connessione da un client reale senza bypass di trust.

Se uno di questi punti non è verificabile, il gap va chiuso prima di andare oltre: senza log, senza thumbprint o senza accesso al Configuration Manager stai lavorando per ipotesi, non per evidenza.