Requisiti dei certificati per SQL Server

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 Transport Layer Security (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 Crittografare le connessioni a SQL Server importando un certificato.

• 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 di AT_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).

• Il denominazione alternativa del soggetto deve includere tutti i nomi che i client possono utilizzare per connettersi a un'istanza di SQL Server.

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.

Gruppo di disponibilità AlwaysOn

Se l'istanza di SQL Server fa parte di un gruppo di disponibilità Always On, è possibile usare uno dei metodi seguenti per creare il certificato:

• Metodo 1: utilizzare un certificato su tutte le repliche del gruppo di disponibilità. Il nome comune è arbitrario, quindi può essere qualsiasi valore segnaposto. Il nome host, il nome di dominio completo di tutte le repliche di SQL Server nel gruppo di disponibilità, e i nomi del listener del gruppo di disponibilità devono essere inclusi nel Nome Alternativo del Soggetto del certificato. Se al gruppo di disponibilità vengono aggiunte repliche aggiuntive dopo la generazione del certificato originale, il certificato deve essere rigenerato con i nomi di tutte le repliche e reimportato in ogni replica. Il certificato deve anche essere importato nell'archivio certificati in tutti i client che si connettono alla replica del gruppo di disponibilità o al listener del gruppo di disponibilità, a meno che il certificato non sia firmato da un'Autorità di Certificazione (CA) pubblica o ufficiale. Se non si includono le repliche del gruppo di disponibilità e i nomi del listener nel certificato, è necessario includere uno dei valori del Nome Alternativo del Soggetto nei valori HostNameInCertificate o il percorso al certificato nei valori ServerCertificate della stringa di connessione quando ci si connette al gruppo di disponibilità. La specifica dei nomi nel certificato è l'approccio consigliato.

  Di seguito è riportato un esempio delle proprietà che definiscono un certificato configurato correttamente per un gruppo di disponibilità con due server denominati test1.<your company>.com e test2.<your company>.come un listener del gruppo di disponibilità denominato aglistener.<your company>.com:

  CN = <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name = aglistener.<your company>.com 
  DNS Name = test1.<your company>.com
  DNS Name = test2.<your company>.com
  DNS Name = aglistener
  DNS Name = test1
  DNS Name = test2
  

• Metodo 2: usare un certificato separato per ogni replica del gruppo di disponibilità. L'aggiunta di repliche a un gruppo di disponibilità dopo la generazione di un certificato è più semplice quando si usano certificati separati perché è sufficiente generare un certificato per la nuova replica, anziché modificare tutti i certificati in tutte le repliche esistenti. Il nome comune è arbitrario, quindi può essere qualsiasi valore segnaposto. Il nome host e il nome di dominio completo della rispettiva istanza di SQL Server e i nomi del listener del gruppo di disponibilità devono essere inclusi nel nome alternativo soggetto del certificato per ogni rispettiva replica. Importare ogni certificato nella rispettiva replica e, a meno che il certificato non sia firmato da un'autorità di certificazione (CA) pubblica o ufficiale, importaretutti i certificati in tutti gli archivi certificati in tutti i client che si connettono alle repliche o al listener del gruppo di disponibilità.

  Di seguito sono riportati esempi delle proprietà che definiscono certificati configurati correttamente per un gruppo di disponibilità con due istanze denominate test1.<your company>.com e test2.<your company>.come un listener del gruppo di disponibilità denominato aglistener.<your company>.com:

  Certificato su test1:

  CN= <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name= test1.<your company>.com 
  DNS Name= aglistener.<your company>.com
  DNS Name= aglistener
  DNS Name= test1
  

  Certificato per test2:

  CN= <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name= test2.<your company>.com 
  DNS Name= aglistener.<your company>.com 
  DNS Name= aglistener
  DNS Name= test2 
  

Istanza del cluster di failover

Se SQL Server è configurato come istanza del cluster di failover, è necessario installare il certificato del server associato al nome host o al nome DNS completo (FQDN) del server virtuale su tutti i nodi del cluster di failover. e i certificati devono essere configurati su 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 e test2.<your company>.come si dispone di un server virtuale denominato virtsql, è necessario installare un certificato per virtsql.<your company>.com in entrambi i nodi.

Importare il certificato nel cluster di failover nella sequenza documentata in Configurare il motore di database di SQL Server per la crittografia delle connessioni.

Di seguito è riportato un esempio delle proprietà che definiscono un certificato configurato correttamente per un'istanza del cluster di failover:

CN = virtsql.<your company>.com
DNS Name = virtsql.<your company>.com
DNS Name = virtsql

Per altre informazioni sui cluster SQL, vedere Prima di installare il clustering di failover.

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.

Importare un certificato con un nome diverso nel nome host

Attualmente, è possibile importare un certificato usando Gestione configurazione SQL Server solo se il nome soggetto del certificato corrisponde al nome host del computer.

Se si vuole usare un certificato con un nome soggetto diverso, seguire questa procedura:

1. Importare il certificato nell'archivio certificati del computer locale usando snap-in Certificati.

2. In Gestione configurazione SQL Server, espandere Configurazione di rete di SQL Server, fare clic destro sull'istanza di SQL Server e quindi scegliere Proprietà per aprire la finestra di dialogo Protocolli per <instance_name> - Proprietà.

3. Nella scheda Certificato selezionare il certificato importato nell'archivio certificati dall'elenco a discesa Certificato :

   

L'importazione di un certificato con un nome diverso nel nome host genera il messaggio di errore seguente:

The selected certificate name does not match FQDN of this hostname. This property is required by SQL Server
Certificate name: random-name
Computer name: sqlserver.___domain.com

Certificati scaduti

SQL Server controlla solo la validità dei certificati al momento della configurazione. Ad esempio, non è possibile usare Gestione configurazione SQL Server 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.

Passo successivo

• Configurare il motore di database di SQL Server per crittografare le connessioni importando un certificato.

Contenuto correlato

• Supporto di TLS 1.3
• Configurare TLS 1.3