MSSQL avec SSL: Le nom principal de cible est incorrect

Je l'ai configuré avec succès SSL sur Microsoft SQL Server 2012 Express Edition pour l'application de chiffrement de réseau externe connexions à la base de données qui sont faites par le biais d'Internet. Pour des raisons de performances pour les clients internes sur le réseau, je ne veux pas forcer l'utilisation de SSL et de laisser aux clients le choix de l'utiliser ou non. J'ai mis Force de Chiffrement à Pas avec les étapes suivantes:

Gestionnaire De Configuration Sql Server
Configuration Du Réseau Sql Server
Protocoles (MYSQLSERVERNAME)
Clic droit: Propriétés
Drapeaux onglet.

Lorsque j'essaie d'établir une connexion chiffrée avec Microsoft Sql Server Management Studio vérification Chiffrer la connexion option sur Options > Propriétés de la Connexion j'obtiens l'erreur suivante.

Une connexion a été établie avec succès avec le serveur, mais une erreur s'est produite pendant le processus de connexion. (fournisseur: Fournisseur de certificats SSL, erreur: 0 - Le nom principal de cible est incorrect). (Microsoft SQL Server, message d'Erreur: -2146893022)

Ce qui est frappant, c'est que si je sélectionne Force de Chiffrement comme Oui sur Gestionnaire de Configuration Sql Server et je ne sélectionnez Chiffrer la connexion sur Microsoft Sql Server Management Studio, je peux me connecter à la base de données. Si j'exécute la requête:

select * from sys.dm_exec_connections

En fait la colonne encrypt_option est VRAI.

De génération du certificat avec Openssl et c'est l'information:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
        Validity
            Not Before: Jun  9 15:53:18 2016 GMT
            Not After : Jun  9 15:53:18 2018 GMT
        Subject: C=US, ST=State, L=Location, O=Testing, OU=Development, CN=JOSEPH-ASUS
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                DB:7F:58:DC:F7:D9:90:2A:DF:0E:31:84:5C:49:68:E7:61:97:D8:41
            X509v3 Authority Key Identifier: 
                keyid:C9:5C:79:34:E0:83:B2:C7:26:21:90:17:6A:86:88:84:95:19:88:EA

            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Alternative Name: 
                DNS:alternatename1, DNS:alternatename2, IP Address:192.168.1.100, IP Address:192.191.1.101, IP Address:192.168.1.103
    Signature Algorithm: sha256WithRSAEncryption
         ...

L'actuel système d'exploitation est Windows 10 à la Maison.

Ce que je suis absent?

J'ai ce problème aussi bien. Situation similaire. Certificat créé dans OpenSSL (peut-être à tort). Différences: SQL Server 2014 Developer edition, Windows 7.
D'ailleurs la différence entre les "la force de cryptage' sur le serveur et la force de cryptage "sur le client et" chiffrer la connexion " dans SSMS sont décrites ici: social.msdn.microsoft.com/Forums/sqlserver/en-US/...

OriginalL'auteur Joseph | 2016-06-09

sql-server ssl

5

J'ai reçu ce message d'erreur lorsque je faisais quelque chose de similaire. J'ai également créé un certificat d'OpenSSL et importé dans SQL Server. J'ai aussi utilisé SQL Server Management Studio pour tenter de vérifier que le côté client copie du certificat a été nécessaire. Quand j'ai fait ce que j'ai obtenu l'erreur décrite ci-dessus.

La solution était tout simplement que dans la fenêtre connecter je n'étais pas à l'aide de la CN qui figure sur le certificat:

À la place de 127.0.0.1 (ou ce que vous avez là) mettre le CN du certificat et cette connexion devrait fonctionner.

reconnaissant pour votre temps, faites-vous m'en suggérer l'utilisation de l'adresse IP au lieu du Nom Commun?, parce que j'ai mis l'IP autre sur le certificat.
Ce que vous voulez est pour le CN du certificat pour correspondre à l'adresse que vous utilisez pour vous connecter au serveur. Vous pouvez le faire en modifiant le certificat, en changeant l'adresse de connexion, ou les deux.
Il est intéressant pour moi, le nom commun (CN) n'est pas le nom du serveur j'ai besoin d'utiliser. Mais à la place le nom de domaine pleinement qualifié (FQDN) qui était dans les autres Noms de l'Objet de l'attribut.

OriginalL'auteur Meadowlark Bradsher
2

Le certificat généré avec OpenSSL fonctionner correctement. Dans mon cas, le problème a été les droits du compte sous lequel s'exécute MSSQL sur le certificat, j'ai résolu ce problème avec le suivez les étapes:
- Ouvrir Gestionnaire de Configuration SQL Server.
- Recherchez le compte qui est utilisé pour exécuter l'instance MSSQL (Journal Sur sur l'onglet instance MSSQL Propriétés).
- Ouvrir MMC Console et ajouter Certificats (ordinateur Local) un composant logiciel enfichable.
- Recherche le magasin de certificats, cliquez-droit sur le certificat et sélectionnez Toutes les Tâches -> Gérer les Clés Privées....
- Définir la Autorisations sur le même compte en vertu de laquelle MSSSQL s'exécute.
Cela a été mon cas, l'installation de SQL 2016 Entreprise avec la valeur par défaut "MSSQLSERVER", qui est un "compte virtuel". Dans mon cas, j'ai dû ajouter le compte "NT SERVICE\MSSQLSERVER" en tapant (Windows ne trouve pas ça si vous recherchez). Voici une longue discussion détaillée sur les autorisations de compte pour SQL. docs.microsoft.com/en-us/sql/database-engine/configure-windows/...

OriginalL'auteur Joseph
0

J'ai eu le même problème et l'ai résolu en ajoutant TrustServerCertificate=True; à la chaîne de connexion.

Qui n'est généralement pas considéré comme sûr pour faire de la production.

OriginalL'auteur SatheeshN
0

J'ai eu cette erreur lorsque vous essayez de vous connecter via sqlcmd à un serveur qui exige l'authentification intégrée de windows (option -E) mais accidentellement utilisé Azure Active Directory Authentification (option -G). La sélection de la bonne drapeaux fixe pour moi. Notez que c'est l'équivalent d', y compris Trusted_Connection=True dans la chaîne de connexion.

OriginalL'auteur Jthorpe

Vous devez vous connecter pour publier un commentaire.