Creare un certificato di identificazione SQL Server per ConfigMgr

Il punto critico: il certificato deve servire ConfigMgr, non solo SQL Server

Quando si parla di creare un certificato di identificazione SQL Server per ConfigMgr, l’errore più comune è pensare al certificato come a un requisito generico di TLS per SQL Server. In realtà, il problema è più stretto: il certificato deve essere compatibile con il modo in cui Configuration Manager si autentica, valida il nome del server e stabilisce la fiducia verso l’istanza SQL che ospita il database del site. Se il certificato è tecnicamente valido ma non è allineato al nome usato da ConfigMgr, al provider corretto o alla catena di trust, il risultato è quasi sempre un sito che parte male, un setup che si blocca o warning che poi diventano incidenti veri quando si passa in produzione.

Il punto da fissare subito è questo: SQL Server non “usa un certificato” in modo astratto. Lo presenta durante il handshake TLS, e ConfigMgr lo accetta solo se il Subject o, meglio, il SAN corrisponde al nome con cui il server viene raggiunto, se la CA è attendibile e se il servizio SQL è configurato in modo coerente. Se stai lavorando su un ambiente con listener, alias DNS, VIP o istanze nominate, il certificato va progettato su quel nome, non sul solo hostname fisico.

Quando serve davvero in ConfigMgr

In pratica, questo certificato entra in gioco in tre scenari ricorrenti. Primo: SQL Server è remoto rispetto al site server e vuoi cifrare il traffico tra componente applicativa e database. Secondo: stai facendo hardening e vuoi evitare l’uso di certificati self-signed o di TrustServerCertificate, che sposta il problema sotto il tappeto. Terzo: hai già una PKI interna e vuoi uniformare la postura TLS di tutti i componenti infrastrutturali, compreso il backend SQL usato da ConfigMgr.

Se invece stai cercando di risolvere un errore del setup di ConfigMgr o una connessione SQL che fallisce dopo un cambio di certificato, la diagnosi va fatta partendo da nome, catena e binding del servizio, non dal wizard della console. Il certificato può essere perfetto e comunque sbagliato per quel contesto.

Requisiti pratici del certificato

Per evitare ambiguità, il certificato destinato a SQL Server per ConfigMgr deve rispettare alcuni requisiti operativi. Il primo è il nome: il CN da solo non basta più come garanzia pratica, quindi usa il SAN con il nome FQDN effettivo che ConfigMgr usa per raggiungere SQL Server. Se l’istanza è raggiunta con un alias, inserisci l’alias nel SAN. Se usi un listener Always On, inserisci il listener. Il nome “giusto” è quello che compare nel connection string reale, non quello che ti sembra più elegante in Active Directory.

Il secondo requisito è la catena di trust. La CA che firma il certificato deve essere attendibile dal server ConfigMgr e, se necessario, anche dai client o dai server che interagiscono con quel flusso. In ambienti enterprise questo di solito significa CA interna, root distribuita via GPO o tramite meccanismi di enrollment centralizzati. Un certificato corretto ma firmato da una CA che il server non conosce produce errori che sembrano di SQL, ma sono di trust.

Il terzo requisito è l’uso corretto di Key Usage e Enhanced Key Usage. Per SQL Server il certificato deve essere idoneo all’autenticazione server, quindi deve includere l’EKU per Server Authentication. Se il template della CA è stato copiato male, o se il certificato è stato emesso con attributi non coerenti, SQL Server potrebbe non proporlo come certificato valido nel Configuration Manager di SQL Server.

Disegno corretto: nome, SAN e istanza

Qui conviene essere molto concreti. Supponiamo che il database di ConfigMgr sia su un server chiamato SQLCM01, raggiunto come sqlcm01.contoso.local. Il certificato dovrebbe includere quel FQDN nel SAN. Se esiste anche un alias applicativo, per esempio cm-sql.contoso.local, va inserito anch’esso. Se usi un’istanza nominata come SQLCM01\CM01, il nome del certificato non cambia per l’istanza: il punto di validazione TLS è l’host, non la parte dopo il backslash. Quello che cambia è la connessione dell’applicazione e il modo in cui il client risolve il target.

Se il certificato è emesso solo per il nome corto del server, il problema arriva appena qualcuno usa il FQDN. Se invece viene emesso per il FQDN ma ConfigMgr si connette tramite alias, il problema è identico. Per questo la fase di design va fatta sul connection path reale, non sul naming teorico dell’infrastruttura.

Creazione del template nella CA

In un ambiente Microsoft con CA interna, il modo più pulito è partire da un template dedicato, non riusare un template generico. Il template deve consentire l’emissione a favore dell’account computer o del servizio previsto, in base a come gestisci l’auto-enrollment o la richiesta manuale. La scelta concreta dipende dal processo di operations, ma il criterio resta lo stesso: il template deve produrre un certificato con EKU da server authentication, chiave privata esportabile solo se davvero necessaria e lunghezza chiave coerente con gli standard interni.

Se vuoi verificare rapidamente la presenza del template e la sua pubblicazione, puoi controllare la console della Certification Authority oppure usare gli strumenti di Windows. Un esempio utile per verificare i certificati presenti sul server è:

certutil -template

Il comando non crea nulla da solo, ma aiuta a capire se il template esiste e se è stato reso disponibile. Se il template non compare, il problema non è SQL Server ma la CA. In quel caso il fix è lato pubblicazione del template, non lato ConfigMgr.

Richiesta ed emissione del certificato

La richiesta può essere fatta dalla console MMC dei certificati, tramite enrollment automatico o con file INF e certreq. Per ambienti controllati, la richiesta manuale con INF è spesso la strada più trasparente perché esplicita Subject, SAN, provider e lunghezza chiave. È anche più facile da auditare, e in caso di troubleshooting puoi riprodurre esattamente la richiesta senza dipendere dallo stato della GUI.

Un esempio minimale di richiesta via file INF può essere questo:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=sqlcm01.contoso.local"
KeySpec = 1
KeyLength = 2048
Exportable = FALSE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10
KeyUsage = 0xa0

[Extensions]
2.5.29.17 = "{text}dns=sqlcm01.contoso.local&dns=cm-sql.contoso.local"

Questo è un esempio, non un modello universale. Se la tua CA richiede un provider diverso, se usi CNG invece del provider legacy, o se hai policy aziendali più restrittive, devi adeguare i parametri. L’aspetto importante è che il SAN sia esplicito e che il certificato sia emesso per il server corretto.

Dopo la richiesta, verifica l’emissione con:

certreq -submit request.inf issued.cer

Se usi la console della CA, la verifica equivalente è la presenza della richiesta nello stato “Issued” e il download del certificato con la catena completa. Se il certificato non viene emesso, guarda prima i log della CA e i criteri del template, non SQL Server.

Importazione nel server SQL e binding del certificato

Una volta ottenuto il certificato, va installato nel repository certificati del computer locale del server SQL, nella store Personal dell’account macchina. Questo è il punto che molti saltano: se il certificato finisce nello store sbagliato, SQL Server non lo vede. Dopo l’importazione, apri la console di SQL Server Configuration Manager, vai nelle proprietà dell’istanza e seleziona il certificato nella scheda relativa a Protocols o Certificate, a seconda della versione. Poi abilita Force Encryption solo se il tuo scenario lo richiede davvero.

Qui c’è un dettaglio operativo importante: dopo aver associato il certificato, SQL Server va riavviato. Senza riavvio, il binding può non essere applicato. Il controllo di verifica non è “la console sembra a posto”, ma il fatto che il servizio riparta senza errori e che il certificato venga effettivamente presentato durante la negoziazione TLS.

Per un controllo rapido lato server puoi usare PowerShell o certutil per verificare la presenza della chiave privata e la store corretta. Un esempio utile è:

certutil -store my

Se il certificato compare ma non ha la chiave privata, non è utilizzabile per SQL Server. In quel caso il problema è nell’importazione o nel formato di esportazione del certificato.

Verifiche lato SQL Server: il certificato è davvero in uso?

Il controllo più utile non è teorico ma pratico: devi capire se SQL Server ha caricato il certificato al boot e se la connessione sta davvero usando TLS. Un primo indizio arriva dal log di SQL Server, che in genere registra informazioni sul certificato selezionato o su eventuali errori di validazione all’avvio del servizio. Il path esatto cambia con la versione, ma il file è tipicamente il ERRORLOG dell’istanza.

Se vuoi vedere rapidamente se il protocollo TLS è attivo, puoi interrogare la sessione da un client autorizzato. Un esempio di query diagnostica è:

SELECT session_id, encrypt_option, auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Se encrypt_option è TRUE, la sessione sta usando cifratura. Questo non prova da solo che il certificato sia quello corretto, ma ti dice che il canale è protetto. Per verificare il certificato specifico, serve correlare il log di SQL Server, il nome presentato e la catena di trust. Se il client si collega ma il nome non combacia, potresti avere cifratura attiva con validazione incompleta, che è il tipo di configurazione che poi crea sorprese nei cambi di manutenzione.

Configurazione ConfigMgr: dove si rompe di solito

Con ConfigMgr, i punti deboli sono sempre simili. Il primo è il nome del server SQL nella configurazione del site. Se il server è stato registrato con un nome diverso da quello del certificato, la connessione TLS fallisce o degrada verso un comportamento non desiderato. Il secondo è la fiducia verso la CA. Se il site server non conosce la root, il certificato viene visto come non valido anche se il server SQL lo presenta correttamente. Il terzo è la presenza di alias, load balancer o routing che cambiano il nome effettivo osservato dal client.

Quando ConfigMgr mostra errori di connessione al database, il debug utile è molto più semplice se separi tre test. Primo: connessione diretta al SQL server con lo stesso nome usato dall’applicazione. Secondo: verifica del certificato presentato. Terzo: conferma che il server che ospita ConfigMgr si fidi della CA. Se uno di questi tre test fallisce, il problema è già localizzato senza bisogno di toccare il database.

Checklist di troubleshooting in ordine di probabilità

Se il certificato è stato creato ma ConfigMgr continua a dare errori, la sequenza più efficiente è questa.

1. Verifica il nome usato dalla connessione reale: FQDN, alias o listener. Falsifica il problema in meno di 5 minuti confrontando il connection string o la configurazione del site con il SAN del certificato.
2. Verifica la catena di trust sul server ConfigMgr e sul server SQL. Se la root o la intermediate non sono presenti nello store corretto, il certificato non sarà considerato affidabile.
3. Verifica che il certificato abbia chiave privata e che SQL Server lo abbia effettivamente caricato dopo il riavvio del servizio.

Questa sequenza evita il classico errore operativo: passare ore a rigenerare il certificato quando in realtà il problema è un alias DNS o una CA non distribuita. In ambienti grandi, il costo del falso positivo è alto perché coinvolge più team e allunga il fermo applicativo.

Un esempio realistico: FQDN, alias e listener

Immagina una topologia con SQL Server su SQLPRD02, ma ConfigMgr si connette a cmdb.contoso.local, un alias DNS che punta al server. Se emetti il certificato solo per SQLPRD02.contoso.local, la connessione tramite alias può fallire la validazione del nome. La soluzione corretta è includere nel SAN sia il nome fisico sia l’alias applicativo. Se in futuro il backend viene spostato dietro un listener o un cluster, il certificato va riallineato al nuovo endpoint, non lasciato “com’era prima” perché tanto il server funziona ancora localmente.

Questo tipo di scenario è frequente nelle migrazioni. Il certificato viene creato correttamente per il server originario, poi l’infrastruttura cambia e nessuno aggiorna il SAN. Il risultato non è sempre un down immediato: a volte il sistema continua a funzionare finché non scade il certificato, fino a quando un riavvio o un aggiornamento rompe la catena. È per questo che il disegno del certificato deve seguire il nome di servizio, non il nome hardware.

Hardening e sicurezza: cosa non lasciare in sospeso

Dal punto di vista della sicurezza, il certificato per SQL Server in ConfigMgr è uno dei pochi punti in cui puoi migliorare davvero la postura senza impattare l’operatività. La regola pratica è semplice: niente chiavi riutilizzate a caso, niente certificati self-signed in produzione, niente eccezioni permanenti con trust manuale sul client. Usa una CA controllata, limita l’esposizione del servizio SQL alle reti necessarie e verifica che il servizio SQL non sia raggiungibile da segmenti che non devono parlare con il database.

Se il certificato è esportabile, fallo solo quando il processo lo richiede davvero. In un contesto di server database, la chiave privata dovrebbe restare il più possibile non esportabile. Se devi distribuire la stessa identità su più nodi per un cluster o per un listener, il modello va progettato prima, non improvvisato dopo. Se il certificato viene compromesso, la risposta corretta è revocare e re-emitere, non riutilizzare una chiave che ha già perso il suo valore fiduciario.

Verifica finale prima di mettere in esercizio

Prima di considerare chiuso il lavoro, fai sempre questi controlli. Primo: il certificato appare nello store del computer locale con chiave privata. Secondo: il SAN contiene il nome con cui ConfigMgr raggiunge SQL Server. Terzo: la CA è fidata dal server ConfigMgr. Quarto: SQL Server è stato riavviato e il log non mostra errori di binding del certificato. Quinto: una sessione reale mostra encrypt_option = TRUE e non ci sono warning di nome o trust nei log applicativi.

Se uno di questi punti fallisce, non forzare il passaggio in produzione. La correzione minima reversibile è quasi sempre una di queste: rigenerare il certificato con SAN corretto, distribuire la CA mancante, oppure riallineare il nome usato da ConfigMgr. Il rollback, in caso di problema dopo il binding, è tornare al certificato precedente e riavviare il servizio SQL, sempre che la vecchia configurazione sia stata conservata e sia ancora valida.

Procedura sintetica da usare in campo

1. Decidi il nome reale dell’endpoint SQL usato da ConfigMgr: FQDN, alias o listener.
2. Emetti un certificato server authentication con SAN coerente e CA attendibile.
3. Importa il certificato nello store Local Computer\Personal sul server SQL.
4. Associalo in SQL Server Configuration Manager e riavvia il servizio.
5. Verifica il log SQL e una connessione con cifratura attiva.
6. Se necessario, distribuisci la root/intermediate CA al server ConfigMgr prima del cutover.

Assunzione operativa: l’ambiente usa una PKI Microsoft o comunque una CA compatibile con l’emissione di certificati server authentication e ConfigMgr si connette a SQL Server tramite un nome risolvibile e stabile.