Partager via


Exigences de certificat pour SQL Server

Cet article décrit les exigences de certificat pour SQL Server et comment vérifier si un certificat répond à ces exigences.

Exigences de certificat pour le chiffrement SQL Server

Pour utiliser le protocole TLS (Transport Layer Security) pour le chiffrement SQL Server, vous devez approvisionner un certificat (l’un des trois types numériques) qui répond aux conditions suivantes :

  • Le certificat doit se trouver dans le magasin de certificats de l’ordinateur local ou dans le magasin de certificats de compte de service SQL Server. Utilisez le magasin de certificats d’ordinateur local pour éviter de reconfigurer les certificats lorsque le compte de démarrage SQL Server change.

  • Le compte de service SQL Server doit disposer de l’autorisation nécessaire pour accéder au certificat TLS. Pour plus d’informations, consultez Encrypter les connexions à SQL Server en important un certificat.

  • L'heure système actuelle doit être après la valeur de la propriété Valid from et avant la valeur de la propriété Valid to du certificat. Pour plus d’informations, consultez Certificats expirés.

    Remarque

    Le certificat doit être destiné à une authentification serveur. Cela nécessite la propriété Utilisation améliorée de la clé du certificat pour spécifier l’authentification du serveur (1.3.6.1.5.5.7.3.1).

  • Le certificat doit être créé à l’aide de l’option KeySpec de AT_KEYEXCHANGE. Cela nécessite un certificat qui utilise un fournisseur de stockage de chiffrement hérité pour stocker la clé privée. En règle générale, la propriété d’utilisation de clé du certificat (KEY_USAGE) inclut également le chiffrement de clé (CERT_KEY_ENCIPHERMENT_KEY_USAGE) et une signature numérique (CERT_DIGITAL_SIGNATURE_KEY_USAGE).

  • Le Subject Alternative Name doit inclure tous les noms que vos clients peuvent utiliser pour se connecter à une instance SQL Server.

Le client doit être en mesure de vérifier la propriété du certificat employé par le serveur. Si le client dispose du certificat de clé publique de l'autorité de certification qui a signé le certificat de serveur, aucune configuration supplémentaire n'est requise. Microsoft Windows inclut les certificats de clé publique de nombreuses autorités de certification. Si le certificat de serveur a été signé par une autorité de certification publique ou privée pour laquelle le client n'a pas le certificat de clé publique, vous devez installer le certificat de clé publique de l'autorité de certification qui a signé le certificat de serveur sur chaque client qui va se connecter à SQL Server.

Importante

SQL Server ne démarre pas si un certificat existe dans le magasin d'ordinateurs, mais répond uniquement à certaines exigences de la liste ci-dessus et s'il est configuré manuellement pour une utilisation par SQL Server Configuration Manager ou par le biais d'entrées de Registre. Sélectionnez un autre certificat qui répond à toutes les exigences ou supprimez le certificat d’être utilisé par SQL Server jusqu’à ce que vous puissiez provisionner celui qui répond aux exigences ou utiliser un certificat auto-généré, comme indiqué dans SQL Server certificats auto-signés générés.

Groupe de disponibilité Always On

Si votre instance de SQL Server fait partie d’un groupe de disponibilité Always On availability group, vous pouvez utiliser l’une des méthodes suivantes pour créer votre certificat :

  • Méthode 1 : Utilisez un certificat sur toutes les répliques du groupe de disponibilité. Le nom commun est arbitraire. Il peut donc s’agir de n’importe quelle valeur d’espace réservé. Le nom d’hôte et le nom de domaine complet de tous les réplicas SQL Server dans le groupe de disponibilité, et les noms de l’écouteur du groupe de disponibilité, doivent être inclus dans le Subject Alternative Name du certificat. Si d’autres réplicas sont ajoutés au groupe de disponibilité après la génération du certificat d’origine, le certificat doit être régénéré avec les noms de tous les réplicas et réimporté dans chaque réplica. Le certificat doit également être importé dans le magasin de certificats sur tous les clients qui se connectent soit au réplica du groupe de disponibilité, soit à l'écouteur du groupe de disponibilité, sauf si le certificat est signé par une autorité de certification publique ou officielle. Si vous n'incluez pas les réplicas de groupe de disponibilité et les noms d'écouteurs dans le certificat, vous devez inclure l'une des valeurs du Nom alternatif du sujet dans le HostNameInCertificate ou le chemin d'accès au certificat parmi les valeurs ServerCertificate de la chaîne de connexion lors de la connexion au groupe de disponibilité. La spécification de noms dans le certificat est l’approche recommandée.

    Voici un exemple de propriétés qui définissent un certificat configuré correctement pour un groupe de disponibilité avec deux serveurs nommés test1.<your company>.com et test2.<your company>.comun écouteur de groupe de disponibilité nommé 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
    
  • Méthode 2 : Utilisez un certificat distinct pour chaque réplica du groupe de disponibilité. L’ajout de réplicas à un groupe de disponibilité après la génération d’un certificat est plus facile lors de l’utilisation de certificats distincts, car vous devez uniquement générer un certificat pour le nouveau réplica, au lieu de modifier tous les certificats sur tous les réplicas existants. Le nom commun est arbitraire. Il peut donc s’agir de n’importe quelle valeur d’espace réservé. Le nom d'hôte et le nom de domaine complet de l'instance SQL Server correspondante, ainsi que les noms des écouteurs du groupe de disponibilité, doivent être inclus dans le Nom alternatif du sujet du certificat pour chaque réplique respective. Importez chaque certificat dans son réplica respectif et, sauf si le certificat est signé par une autorité de certification publique ou officielle, importeztous les certificats dans tous les stores de certificats sur tous les clients qui se connectent aux réplicas ou à l’écouteur de groupe de disponibilité.

    Voici des exemples de propriétés qui définissent des certificats correctement configurés pour un groupe de disponibilité avec deux instances nommées test1.<your company>.com et test2.<your company>.comun écouteur de groupe de disponibilité nommé aglistener.<your company>.com:

    Certificat pour 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
    

    Certificat dans 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 
    

Instance de cluster de basculement

Si SQL Server est configuré en tant qu’instance de cluster failover, vous devez installer le certificat de serveur avec le nom d’hôte ou le nom DNS complet (FQDN) du serveur virtuel sur tous les nœuds du cluster de basculement. et les certificats doivent être installés sur tous les nœuds du cluster de basculement. Par exemple, si vous avez un cluster à deux nœuds, avec des nœuds nommés test1.<your company>.com et test2.<your company>.comque vous disposez d’un serveur virtuel nommé virtsql, vous devez installer un certificat pour virtsql.<your company>.com les deux nœuds.

Importez le certificat dans le cluster de basculement dans l'ordre documenté dans Configure SQL Server Database Engine pour chiffrer les connexions.

Voici un exemple des propriétés qui définissent un certificat configuré correctement pour une instance de cluster de basculement :

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

Pour plus d’informations sur les clusters SQL, consultez Avant l’installation du clustering de basculement.

Vérifier si un certificat répond aux exigences

Dans SQL Server 2019 (15.x) et versions ultérieures, SQL Server Configuration Manager valide automatiquement toutes les exigences de certificat pendant la phase de configuration elle-même. Si SQL Server démarre correctement après avoir configuré un certificat, il est judicieux d'indiquer que SQL Server pouvez utiliser ce certificat. Toutefois, certaines applications clientes peuvent encore avoir d’autres exigences pour les certificats qui peuvent être utilisés pour le chiffrement, et vous pouvez rencontrer différentes erreurs en fonction de l’application utilisée. Dans ce scénario, vous devez consulter la documentation de support de l’application cliente pour plus d’informations sur le sujet.

Vérifier KeySpec et Key Usage

L’exigence KeySpec (AT_KEYEXCHANGE) est une cause courante des échecs de configuration de certificat. Utilisez les méthodes suivantes pour vérifier que votre certificat répond à cette exigence.

Utiliser certutil

Exécutez certutil avec l’option -v pour afficher les propriétés de certificat détaillées, notamment KeySpec et Key Usage:

certutil -v -store My "<certificate_thumbprint>"

Dans la sortie, recherchez les valeurs suivantes :

KeySpec = 1 -- AT_KEYEXCHANGE
Key Usage = Key Encipherment, Digital Signature (a0)
Enhanced Key Usage:
    Server Authentication (1.3.6.1.5.5.7.3.1)

Si KeySpec = 2 (AT_SIGNATURE), le certificat ne peut pas être utilisé pour le chiffrement SQL Server.

Utiliser PowerShell

Exécutez les commandes PowerShell suivantes pour rechercher KeySpec des certificats dans le magasin d’ordinateurs local :

Get-ChildItem Cert:\LocalMachine\My | ForEach-Object {
    $cert = $_
    $key = $cert.PrivateKey
    [PSCustomObject]@{
        Subject   = $cert.Subject
        Thumbprint = $cert.Thumbprint
        KeySpec   = if ($key) { $key.CspKeyContainerInfo.KeyNumber } else { 'No private key' }
        NotAfter  = $cert.NotAfter
    }
} | Format-Table -AutoSize

Vérifiez que KeySpec affiche Exchange (correspondant à AT_KEYEXCHANGE). S’il s’affiche Signature, demandez un nouveau certificat avec le paramètre correct KeySpec .

Créer un certificat à l’aide d’AD CS

Si votre organisation utilise Active Directory Certificate Services (AD CS) en tant qu’autorité de certification interne, créez un certificat qui répond aux exigences SQL Server en procédant comme suit :

  1. Ouvrez le composant logiciel enfichable MMC Certificates pour l’ordinateur local (certlm.msc).
  2. Développez Personnel, cliquez avec le bouton droit sur Certificats, puis sélectionnez Toutes les tâches>Demander un nouveau certificat.
  3. Sélectionnez Active Directory Stratégie d’inscription puis Next.
  4. Choisissez un modèle de certificat qui prend en charge l’authentification du serveur. Un serveur web ou un modèle personnalisé configuré pour l’authentification du serveur répond généralement aux exigences. Vérifiez auprès de votre administrateur d’autorité de certification que le modèle utilise un fournisseur de services de chiffrement (CSP) hérité avec KeySpec = AT_KEYEXCHANGE, et non un fournisseur de stockage de clés (KSP).
  5. Dans la page Propriétés du certificat :
    • Définissez le Common Name (CN) sur le nom d’hôte ou le nom de domaine complet de votre instance de SQL Server.
    • Sous l’onglet Autre nom de l’objet , ajoutez des entrées DNS pour tous les noms d’hôte que les clients utilisent pour se connecter (nom d’hôte, nom de domaine complet et alias).
  6. Terminez l'assistant d'inscription et vérifiez que le nouveau certificat apparaît dans personnels>Certificats.
  7. Vérifiez le KeySpec en utilisant certutil ou PowerShell, comme décrit dans Vérifier KeySpec et l’utilisation de clé.

Importante

Les certificats créés avec un fournisseur de stockage de clés (KSP), tel que le Microsoft Software Key Storage Provider, utilisent KeySpec = 0 et ne sont pas compatibles avec SQL Server. Lors de la création de votre modèle de certificat dans AD CS, sélectionnez un fournisseur de services de chiffrement hérité comme Microsoft RSA SChannel Cryptographic Provider pour vous assurer KeySpec = AT_KEYEXCHANGE.

Vous pouvez utiliser l’une des méthodes suivantes pour vérifier la validité du certificat à utiliser avec SQL Server :

  • outil sqlcheck : sqlcheck est un outil en ligne de commande qui examine les paramètres de compte d’ordinateur et de service actuels et génère un rapport de texte dans la fenêtre console qui est utile pour résoudre diverses erreurs de connexion. La sortie contient les informations suivantes concernant les certificats :

    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.
    

    Pour plus d’informations sur les fonctionnalités de l’outil et pour obtenir des instructions de téléchargement, consultez Bienvenue dans le wiki CSS_SQL_Networking_Tools.

  • Outil certutil : certutil.exe est un programme en ligne de commande, installé dans le cadre des services de certificats. Vous pouvez utiliser certutil.exe pour extraire et afficher des informations de certificat. Utilisez l’option -v pour obtenir des informations détaillées. Pour plus d'informations, consultez certutil.

  • Composant logiciel enfichable Certificats : vous pouvez aussi utiliser la fenêtre Composant logiciel enfichable Certificats pour voir plus d’informations sur les certificats dans les différents magasins de certificats sur l’ordinateur. Mais cet outil n’affiche KeySpec pas d’informations. Pour plus d’informations sur la façon d’afficher les certificats avec le composant logiciel enfichable MMC, consultez Guide pratique pour afficher les certificats avec le composant logiciel enfichable MMC.

Importer un certificat avec un nom différent dans le nom d’hôte

Actuellement, vous ne pouvez importer qu’un certificat à l’aide de l’SQL Server Configuration Manager si le nom d’objet du certificat correspond au nom d’hôte de l’ordinateur.

Si vous souhaitez utiliser un certificat avec un autre nom d’objet, procédez comme suit :

  1. Importez le certificat dans le magasin de certificats de l’ordinateur local à l’aide du composant logiciel enfichable Certificats.

  2. Dans SQL Server Configuration Manager, développez SQL Server Network Configuration, cliquez avec le bouton droit sur l’instance de SQL Server, puis choisissez Propriétés pour ouvrir la boîte de dialogue Propriétés des Protocoles de l'instance <instance_name>.

  3. Sous l’onglet Certificat , sélectionnez le certificat que vous avez importé dans le magasin de certificats dans la liste déroulante Certificats :

    Screenshot de l’onglet certificat de la boîte de dialogue propriétés dans SQL Server Configuration Manager.

L’importation d’un certificat avec un autre nom dans le nom d’hôte entraîne le message d’erreur suivant :

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

Certificats expirés

SQL Server vérifie uniquement la validité des certificats au moment de la configuration. Par exemple, vous ne pouvez pas utiliser SQL Server Configuration Manager sur SQL Server 2019 (15.x) et versions ultérieures pour approvisionner un certificat expiré. SQL Server continue à s'exécuter sans problème si le certificat expire après son approvisionnement. Toutefois, certaines applications clientes comme Power BI vérifient la validité du certificat sur chaque connexion et déclenchent une erreur si l’instance de SQL Server est configurée pour utiliser un certificat expiré pour le chiffrement. Nous vous recommandons de ne pas utiliser de certificat expiré pour SQL Server chiffrement.

Étape suivante