Requisiti certificato per SQL Server

  • Articolo

Questo articolo descrive i requisiti dei certificati per SQL Server e come verificare se un certificato soddisfa questi requisiti.

Requisiti certificato per crittografia di SQL Server

Per l'uso dell’archiviazione thread-local 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 essere presente nell'archivio certificati del computer locale oppure nell'archivio certificati dell’account del servizio SQL Server. È consigliabile usare l'archivio certificati del computer locale perché in questo modo si evita di riconfigurare i certificati con le modifiche dell'account di avvio di SQL Server.

  • L'account del servizio SQL Server deve avere l'autorizzazione necessaria per accedere al certificato TSL. Per ulteriori 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à Valido da e antecedente al valore della proprietà Valido fino a del certificato. Per altre informazioni, vedere Certificati scaduti.

    Nota

    Il certificato deve essere destinato all'autenticazione del server. Per questa operazione è necessario impostare la proprietà Utilizzo chiavi avanzato del certificato su Autenticazione server (1.3.6.1.5.5.7.3.1).

  • Il certificato deve essere creato utilizzando l'opzione KeySpec di AT_KEYEXCHANGE. Ciò 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 a chiave (CERT_KEY_ENCIPHERMENT_KEY_USAGE) e una firma digitale (CERT_DIGITAL_SIGNATURE_KEY_USAGE).

  • La proprietà Soggetto del certificato deve specificare che il nome comune (CN, Common Name) corrisponde al nome host oppure al nome di dominio completo (FQDN, Fully Qualified Domain Name) del server. Quando si usa il nome host, nel certificato deve essere specificato il suffisso DNS. Se SQL Server è in esecuzione in un cluster di failover, è necessario che il nome comune corrisponda al nome host oppure al nome di dominio completo del server virtuale e che sia stato eseguito il provisioning dei certificati in tutti i nodi del cluster di failover. Ad esempio, con un cluster costituito da due nodi, denominati rispettivamente test1.*<your company>*.com e test2.*<your company>*.com, e un server virtuale denominato virtsql, è necessario installare un certificato per virtsql.*<your company>*.com in entrambi i nodi. Per altre informazioni sui cluster SQL, vedere Operazioni preliminari all'installazione del 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 del soggetto del certificato. Per altre informazioni, vedere Listener e certificati TLS/SSL. Per altre informazioni su Always On di SQL, vedere Connessione a un listener di un gruppo di disponibilità Always On.

  • Il nome alternativo del soggetto deve includere tutti i nomi che i client potrebbero usare per connettersi a un'istanza di SQL Server. Se si usano gruppi di disponibilità, il nome alternativo del soggetto deve includere il NetBIOS e il nome di dominio completo (FQDN) del localhost e i listener creati.

Il client deve essere in grado di verificare la proprietà del certificato utilizzato dal server. Se il client dispone del certificato chiave pubblica dell'autorità di certificazione che ha firmato il certificato del server, non sono necessarie ulteriori operazioni di configurazione. In Microsoft Windows sono inclusi i certificati a chiave pubblica di numerose Autorità di certificazione. Se il certificato del server è stato firmato da un'Autorità di certificazione pubblica o privata per la quale il client non dispone del certificato a chiave pubblica, è necessario installare il certificato a chiave pubblica dell'Autorità di certificazione che ha firmato il certificato del server su ciascun client che si connetterà 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 effettuare il provisioning di un certificato che soddisfi i requisiti o usare un certificato autogenerato come descritto in Certificati autofirmati generati daSQL 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 dei certificati 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 è un’utilità da riga di comando che esamina le impostazioni correnti dell'account del computer e del servizio e produrrà 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 sul download, vedere Benvenuti nel wiki di CSS_SQL_Networking_Tools.

  • Strumento certutil: certutil.exe è un programma da 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 altre informazioni sui certificati in vari archivi certificati nel computer. Questo strumento, però, non mostra informazioni KeySpec. Per altre informazioni su come visualizzare i certificati con lo snap-in MMC, vedere Procedura: Visualizzare i certificati con lo snap-in MMC.

Ulteriori 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.

Contenuto correlato