Vous consultez une page technique concernant le logiciel de gestion Mercator. Celle-ci contient des informations spécifiques destinées aux professionnels de Mercator. Souhaitez-vous être redirigés vers des informations plus générales ?


   Ne plus poser cette question

Crypter les échanges entre Mercator et le serveur SQL : méthode "client side"

0000002683     -      26/01/2017

Si les communications entre Mercator (le client) et le serveur SQL ne passent pas exclusivement soit par un réseau local privé soit par un VPN, alors il est impératif de les crypter à l'aide d'un certificat SSL. L'avantage de la méthode "client side" est qu'elle permet de choisir librement quels sont les postes et les applications dont les communications devront être sécurisées. Typiquement, les postes fixes dans le réseau local de l'entreprise ou ceux qui communiquent via un tunnel sécurisé ne devront pas recevoir ce paramétrage. Etant donné cette souplesse, cette méthode est préférée à la méthode "server-side".


A plusieurs reprises dans ce tutoriel, la console de gestion de certificats sera utilisée. Pour cela, il conviendra chaque fois d'effectuer ces différentes étapes :

  • exécuter MMC.exe
  • dans le menu fichier, choisir "Ajouter/supprimer un composant logiciel enfichable" (Add/Remove Snap-in)
  • ajouter "Certificats"
  • choisir "Un compte d'ordinateur" (Local computer)
  • cliquer sur "Terminer" et ensuite "OK"


Etape n°1 : déterminer le FQDN du serveur SQL

La première étape consiste en la détermination du FQDN (fully qualified domain name) du serveur SQL. En effet, le nom commun (CN) du certificat qui va être utilisé doit obligatoirement être identique à ce FQDN. Cette valeur peut être obtenue via cette requête SQL :

DECLARE @Domain NVARCHAR(100)
EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE', 'SYSTEM\CurrentControlSet\services\Tcpip\Parameters', N'Domain',@Domain OUTPUT
SELECT Cast(SERVERPROPERTY('MachineName') as nvarchar) + '.' + @Domain AS FQDN

Dans ce tutoriel, il s'agira de "exemple.domain.local".


Etape n°2 : localiser le certificat qui va être envoyé par le serveur au client pour effectuer le cryptage

Sur le serveur hébergeant SQL Server, ouvrez la console de gestion de certificats tel qu'indiqué ci-dessus. Localisez le magasin suivant :

Dans ce répertoire, doit apparaître un certificat dont l'objet (subject) est égal au FQDN 

Il faut ensuite identifier le certificat d'autorité  (CA = certificate authority) duquel dépend le certificat.

Il est possible que ce certificat CA se trouve sur ce même serveur ou sur un autre serveur, par exemple le contrôleur de domaine.

Que faire si aucun certificat n'est disponible sur le serveur SQL ?


Etape n°3 : exporter le certificat CA

Sur le serveur hébergeant le certificat CA, ouvrez la console de gestion de certificats tel qu'indiqué ci-dessus. Le certificat se trouve certainement dans le magasin "Personnel". Localisez ce certificat CA. Via le menu contextuel, exportez le certificat. Dans l'assistant d'export, acceptez toutes les valeurs par défaut. Il ne faut pas exporter la clé privée.

L'assistant va produire un fichier au format CER contenant le certificat CA (clé publique).

Notez au passage la date d'expiration de ce certificat. Au-delà de cette date, il faudra recommencer le processus à partir de l'étape n°3.


Etape n°4 : configuration du poste client

Il faut d'abord installer le certificat CA en tant qu'autorité de certification racines de confiance. Cette opération est nécessaire pour que le certificat qui sera utilisé par SQL Server soit reconnu comme un certificat valide. Si cette étape n'est pas effectuée correctement, l'erreur suivante sera visible dans l'observateur d’événements (système) : Le certificat reçu du serveur distant a été émis par une autorité de certification non approuvée. En conséquence, aucune des données contenues dans le certificat ne peut être validée. Échec de la demande de connexion TLS.

Pour cela, sur le poste client, il faut ouvrir la console de gestion de certificats et localiser le magasin "Autorité de certification racines de confiance" (Trusted Root Certification Authorities).Via le menu contextuel sur celui-ci, il convient d'importer le fichier CER créé à l'étape précédente.

Note : l'étape n°3 et cette première partie de l'étape n°4 peuvent être ignorées si le certificat CA existe déjà sur le poste client.

Ensuite, il faut s'assurer que le serveur SQL soit bien atteignable via son FQDN. Le cas échéant, il est nécessaire d'effectuer une modification dans la DNS du domaine ou d'adapter le fichier C:\Windows\System32\drivers\etc\hosts en y ajoutant une ligne contenant :

  • adresse IP sur serveur SQL
  • tab
  • FQDN

Vérifiez que la commande ping exemple.domain.local fonctionne et atteint bien le serveur SQL.

Dans le fichier mercator.connection de ce Mercator, il faut adapter la valeur de SqlServer en spécifiant le FQDN.

SqlServer = exemple.domain.local

Il faut aussi ajouter cette ligne :

Complement = encrypt=true

Ensuite, démarrez Mercator et vérifiez que le cryptage SSL est bien activé dans "Outils / Informations Utilisateurs"

session_ssl


Remarques :

  • Ce tutoriel montre comment utiliser des certificats "privés" pour crypter les communications avec SQL Server. D'autres méthodes existent, dont par exemple l’utilisation de certificats commerciaux émis par des sociétés reconnues en tant que CA. Ceci dépasse le cadre de cette documentation.
  • Le fait de crypter les données permet d'empêcher que les données soient interceptées lors de leur transit et utilisées à des fins malveillantes. Cela n'assure en rien la protection du serveur SQL, dont le port (tcp 1433) doit être rigoureusement protégé par un firewall correctement configuré.
  • La configuration SSL des échanges avec SQL Server crypté ne doit jamais être effectuée à la fois "server side" et "client side".
  • En cas d'erreur avec les certificats, certains tutoriels trouvés sur Internet vont suggérer de mettre cette ligne en tant que Complement dans le fichier Mercator.connection : Encrypt=True;TrustServerCertificate=True. Nous ne pouvons que décourager cette pratique puisque dans ce cas, n'importe quel certificat peut être utilisé.
  • La technique illustrée ici n'est pas spécifique à Mercator. Dès lors, les questions éventuelles relatives à cette mise en place sortent du cadre du support Mercator.

Que faire si aucun certificat n'est disponible sur le serveur SQL ?

1) Sur votre serveur contrôleur de domaine, il faut, si nécessaire, ajouter le rôle : Services de certificats Active Directory. Ensuite, dans le gestionnaire du serveur, il faut cliquer sur AD CS

et effectuer la configuration suggérée dans le message d'avertissement apparaissant en jaune.

Lors de cette configuration, Windows Server va proposer de créer une clé privée et le certificat CA. Déterminez une date d'expiration suffisamment lointaine afin de ne pas devoir répéter les étapes 3 et suivantes trop prochainement.

Note : Active Directory effectue une propagation automatique des certificats racines. Dès lors, après redémarrage, chacun des postes et serveurs inscrits dans le domaine devraient disposer de ce certificat. Cela rend donc non nécessaire l'étape n°3 et le premier point de l'étape n°4. (Cette propagation n'est pas nécessairement immédiate. Elle peut être effectuée après plusieurs heures)

2) Sur le serveur hébergeant SQL serveur, démarrez la console de gestion des certificats. Localisez le magasin personnel et, via le menu contextuel, exécutez "Demander un nouveau certificat".

  • choisissez "Stratégie d’inscription à Active Directory"
  • cliquez sur "Ordinateur"
  • étendez "Détails" et cliquez sur "Propriétés"
  • indiquez le FQDN dans le nom convivial et la description
  • dans "Objet", ajoutez "Nom commun" avec comme valeur le FQDN

Une fois le certificat obtenu, vous pouvez reprendre l'étape n°2.