SQL Server ne démarre plus avec SSL activé

SQL Server supporte, au moins depuis la version 2005, les connexions sécurisés en utilisant SSL.
En suivant la procédure décrite par Microsoft, ça se fait relativement bien… mais les règles semblent avoir changées avec la version 2008 R2.

En effet, à partir de cette version, une étape supplémentaire est requise afin d’autoriser et de s’assurer que l’utilisateur qui exécute le service puisse accéder à la clé privée associée au certificat. Dans le cas contraire, SQL Server balance plusieurs erreurs abscons dont la première a pour EventID 26014 avec pour seules explications que le certificat spécifié n’existe pas et pourtant, il est bien là !

Revoyons les étapes nécessaires pour activer SSL sur une instance SQL Server :

  1. Installer le certificat de sécurité sur la machine qui exécute SQL Server en utilisant la MMC gérant les certificats. Le certificat DEVRA bien entendu être au format PFX pour qu’il puisse être importé dans un magasin de certificats géré par Windows.
    • il est important de noter que le certificat DOIT ÊTRE accessible par l’utilisateur qui exécute SQL Server, donc on ne peut pas utiliser par exemple le magasin de certificat du compte administrateur (à moins que ce soit lui qui exécute SQL Server, auquel cas c’est complètement débile d’un point de vue sécurité). Le certificat peut donc être installé ou bien dans le magasin de la machine locale, ou bien dans le magasin du compte utilisateur. J’ai testé avec le magasin de la machine locale, mais ça devrait aussi fonctionner avec le magasin du compte utilisateur SQL Server. A noter que sous Windows Server 2003, je recommande l’utilisation du magasin de la machine locale pour faciliter la manipulation à l’étape suivante.
    • c’est là que les choses changent : il faut vérifier que l’utilisateur SQL Server peut lire la clé privée, ce qui ne semble plus être le cas par défaut. Pour se faire, ou bien on dispose de Windows Server 2008 R2 et cela se fait directement dans la MMC, ou bien on tourne encore sous Windows Server 2003 et il faut faire appel à un outil nommé winhttpcrtcfg disponible dans le Ressource Kit de Windows Server 2003. La commande à taper ressemblera à winhttpcrtcfg -g -c LOCAL_MACHINE\My -s « le.sujet.du.certificat.kveer.com » -a utilisateur_sql_server et on pourra le vérifier avec la commande winhttpcrtcfg -l -c LOCAL_MACHINE\MY -s « le.sujet.du.certificat.kveer.com »
  2. Reconfigurer SQL Server grâce au SQL Server Configuration Manager
    • je ne détaillerai pas cette étape car elle n’a pas changé, et consiste en une dizaine de clics dans le SQL Server Configuration Manager. Se référer aux liens dans la section Source pour la procédure étape par étape.

Voir aussi

Associer un utilisateur de base de données à une connexion SQL Server

Lorsqu’on fait des imports d’un serveur SQL Server à l’autre et que l’on utilise l’authentification en mode SQL, il peut arriver que des connexions SQL soient refusées. En réalité, le lien entre une connexion SQL Server et un utilisateur de base de données n’existe plus.

La méthode barbare auquel on pourrait penser au premier abord pour remédier à ce problème est alors de supprimer l’utilisateur de la base de données pour le recréer, mais si cet utilisateur a des droits particuliers, tous ces droits sautent et il faut les réattribuer.

Microsoft fournit une fonctionnalité permettant de modifier les mappages entre utilisateurs de base de données et connexions SQL Server, très utile dans ce cas précis.

Exemple d’utilisation : exec sp_change_users_login ‘Update_one’, ‘username’, ‘loginname’
username  est un utilisateur de base de données et loginname  une connexion SQL Server.

Cette méthode semble dépréciée par Microsoft, mais est toujours utile pour une utilisation exceptionnelle.

Voir aussi