Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive i requisiti dei certificati per SQL Server e come verificare se un certificato soddisfa questi requisiti.
Requisiti dei certificati per la crittografia di SQL Server
Per l'uso di TLS per la crittografia di SQL Server, è necessario effettuare il provisioning di un certificato (uno dei tre tipi digitali) che soddisfi le condizioni seguenti:
Il certificato deve trovarsi nell'archivio certificati del computer locale o nell'archivio certificati dell'account del servizio SQL Server. È consigliabile usare l'archivio certificati del computer locale perché evita di riconfigurare i certificati con le modifiche dell'account di avvio di SQL Server.
L'account del servizio SQL Server deve disporre dell'autorizzazione necessaria per accedere al certificato TLS. Per altre informazioni, vedere Configurare il motore di database di SQL Server per la crittografia delle connessioni.
L'ora di sistema corrente deve essere successiva al valore della proprietà Valid from e prima del valore della proprietà Valid to del certificato. Per altre informazioni, vedere Certificati scaduti.
Annotazioni
Il certificato deve essere destinato all'autenticazione del server. È necessaria la proprietà Utilizzo chiavi avanzato del certificato per specificare l'autenticazione server (1.3.6.1.5.5.7.3.1).
Il certificato deve essere creato usando l'opzione
KeySpec
diAT_KEYEXCHANGE
. Questo richiede un certificato che usa un provider di archiviazione di crittografia legacy per archiviare la chiave privata. In genere, la proprietà di utilizzo della chiave del certificato (KEY_USAGE) include anche la crittografia della chiave (CERT_KEY_ENCIPHERMENT_KEY_USAGE
) e una firma digitale (CERT_DIGITAL_SIGNATURE_KEY_USAGE
).La proprietà Subject del certificato deve indicare che il nome comune (CN) è uguale al nome host o al nome di dominio completo (FQDN) del computer server. Quando si usa il nome host, il suffisso DNS deve essere specificato nel certificato. Se SQL Server è in esecuzione in un cluster di failover, il nome comune deve corrispondere al nome host o al nome di dominio completo del server virtuale e deve essere effettuato il provisioning dei certificati in tutti i nodi del cluster di failover. Ad esempio, se si dispone di un cluster a due nodi, con nodi denominati
test1.*<your company>*.com
etest2.*<your company>*.com
e si dispone di un server virtuale denominato virtsql, è necessario installare un certificato pervirtsql.*<your company>*.com
in entrambi i nodi. Per altre informazioni sui cluster SQL, vedere Prima di installare il clustering di failover.Quando ci si connette a un listener del gruppo di disponibilità, i certificati di cui viene effettuato il provisioning per ogni nodo del server partecipante nel cluster di failover devono avere anche un elenco di tutti i listener del gruppo di disponibilità impostati nel nome alternativo soggetto del certificato. Per altre informazioni, vedere Listener e certificati TLS/SSL. Per altre informazioni su SQL AlwaysOn, vedere Connettersi a un listener del gruppo di disponibilità AlwaysOn.
Il nome alternativo soggetto deve includere tutti i nomi che i client potrebbero usare per connettersi a un'istanza di SQL Server. Se si usano i Gruppi di Disponibilità, il nome alternativo del soggetto dovrebbe includere il NetBIOS e il nome di dominio completo (FQDN) del localhost e dei listener creati.
Il client deve essere in grado di verificare la proprietà del certificato usato dal server. Se il client ha il certificato di chiave pubblica dell'autorità di certificazione che ha firmato il certificato del server, non sono necessarie altre configurazioni. Microsoft Windows include i certificati di chiave pubblica di molte autorità di certificazione. Se il certificato del server è stato firmato da un'autorità di certificazione pubblica o privata per cui il client non dispone del certificato di chiave pubblica, è necessario installare il certificato di chiave pubblica dell'autorità di certificazione che ha firmato il certificato del server in ogni client che si connette a SQL Server.
Importante
SQL Server non verrà avviato se esiste un certificato nell'archivio computer, ma soddisfa solo alcuni requisiti nell'elenco precedente e se è configurato manualmente per l'uso da Gestione configurazione SQL Server o tramite voci del Registro di sistema. Selezionare un altro certificato che soddisfi tutti i requisiti o rimuovere il certificato da usare da SQL Server fino a quando non è possibile effettuarne il provisioning che soddisfi i requisiti o usare un certificato autogenerato come descritto in CERTIFICATI autofirmati generati da SQL Server.
Controllare se un certificato soddisfa i requisiti
In SQL Server 2019 (15.x) e versioni successive, Gestione configurazione SQL Server convalida automaticamente tutti i requisiti del certificato durante la fase di configurazione stessa. Se SQL Server viene avviato correttamente dopo la configurazione di un certificato, è consigliabile indicare che SQL Server può usare tale certificato. Tuttavia, alcune applicazioni client potrebbero avere ancora altri requisiti per i certificati che possono essere usati per la crittografia e potrebbero verificarsi errori diversi a seconda dell'applicazione in uso. In questo scenario, è necessario controllare la documentazione del supporto dell'applicazione client per altre informazioni sull'argomento.
È possibile usare uno dei metodi seguenti per verificare la validità del certificato da usare con SQL Server:
strumento sqlcheck:
sqlcheck
è uno strumento da riga di comando che esamina le impostazioni correnti dell'account del computer e del servizio e genera un report di testo nella finestra della console utile per la risoluzione di vari errori di connessione. L'output contiene le informazioni seguenti relative ai certificati:Details for SQL Server Instance: This Certificate row in this section provides more details regarding the certificate being used by SQL Server (Self-generated, hard-coded thumbprint value, etc.). Certificates in the Local Computer MY Store: This section shows detailed information regarding all the certificates found in the computer certificate store.
Per altre informazioni sulle funzionalità dello strumento e per le istruzioni di download, vedere Benvenuti nel wiki di CSS_SQL_Networking_Tools.
Strumento certutil:
certutil.exe
è un programma a riga di comando, installato come parte di Servizi certificati. È possibile usare certutil.exe per eseguire il dump e visualizzare le informazioni sul certificato. Usare l'opzione-v
per ottenere informazioni dettagliate. Per altre informazioni, vedere certutil.Snap-in certificati: È anche possibile usare la finestra Snap-in certificati per visualizzare ulteriori informazioni sui certificati in vari archivi di certificati nel computer. Ma questo strumento non mostra
KeySpec
informazioni. Per altre informazioni su come visualizzare i certificati con lo snap-in MMC, vedere Procedura: Visualizzare i certificati con lo snap-in MMC.
Altre informazioni
Certificati scaduti
SQL Server controlla solo la validità dei certificati al momento della configurazione. Ad esempio, non è possibile usare Configuration Manager in SQL Server 2019 (15.x) e versioni successive per effettuare il provisioning di un certificato scaduto. SQL Server continua a essere eseguito senza problemi se il certificato scade dopo che è già stato effettuato il provisioning. Tuttavia, alcune applicazioni client come Power BI controllano la validità del certificato in ogni connessione e generano un errore se l'istanza di SQL Server è configurata per l'uso di un certificato scaduto per la crittografia. È consigliabile non usare un certificato scaduto per la crittografia di SQL Server.