L'ajout de certificat SSL a échoué lors de la liaison au port
J'ai créé un WebService en utilisant WCF. Je fais l'auto-hébergement et je veux activer HTTPS. D'après ce que j'ai compris pour cela, je dois créer un certificat et établir une liaison avec le port que je veux utiliser.
Voici les étapes que j'ai effectuées pour gérer ceci:
- Création d'un certificat sur mon ordinateur local pour agir en tant qu'autorité de certification racine
- makecert -n "CN = Mon autorité de certification racine" -r -sv RootCATest.pvk RootCATest.cer
- Ouvrez MMC.exe et importez le fichier .cer enregistré dans le dossier "Trusted Root Certificate\Certificates \.".
- makecert -sk MyKeyName -iv RootCATest.pvk -n "CN = MyMachineName" -ic RootCATest.cer -sr localmachine -ss mon -sky échange -pe MyMachineName.cer
Création d'un certificat de service temporaire à partir de l'autorité de certification racine signée
- makecert -sk MyKeyName -iv RootCATest.pvk -n "CN = MyMachineName" -ic RootCATest.cer -sr localmachine -ss mon -sky échange -pe MyMachineName.cer
Essayé de lier le certificat au numéro de port (443 dans ce cas)
- netsh http add sslcert ipport = 0.0.0.0: 443 certhash = 2c5ba85bcbca412a74fece02878a44b285c63981 appid = {646937c0-1042-4e81-a3b6-47d678d68ba9}
Le résultat de l'étape 4 est l'erreur suivante:
Echec de l'ajout du certificat SSL, erreur 1312
Une session d'ouverture de session spécifiée n'existe pas. Il est peut-être déjà terminé.
Quelqu'un at-il une idée pourquoi je pourrais obtenir cette erreur?
J'ai eu la même erreur. La première fois que cela s'est produit, comme l'a dit Micheal, j'ai dû déplacer le certificat sous Certificats (ordinateur local) -> Personnel -> Dossier de certificat. J'ai eu la même erreur lorsque j'ai importé le même certificat sur une autre machine. La raison était que j'utilisais certmgr.msc pour importer le certificat. . La fenêtre ouverte affiche donc “Certificats - Utilisateur actuel”. Les certificats importés à l'aide de cette fenêtre entraînent l'échec de netsh avec l'erreur 1312. Veillez à utiliser le composant logiciel enfichable certificat dans MMC pour importer les certificats. Le composant logiciel enfichable Certificat de MMC affiche «Certificats (ordinateur local)». Cela permet à l'exécution netsh de naviguer.
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
J'avais le même problème et j'ai passé quelques jours à essayer de comprendre pourquoi.
Pour résumer, le problème est que vous avez installé le certificat sur le serveur winrm qui n’a pas de clé privée.
J'ai vérifié cela plusieurs fois. Vous devez supprimer votre certificat et le reconstruire en utilisant, par exemple, makecert, comme cela est parfaitement décrit ici: http://blogs.technet.com/b/jhoward/archive/2005/02/02/365323.aspx
Vous pouvez facilement vérifier si votre certificat a une clé privée comme suit: mmc - certificates - local machine - personal. Regardez l'icône du certificat - il DOIT avoir le signe de la clé sur l'icône.
Je m'occupais de ce problème et j'utilise un service WCF auto-hébergé. Je viens de faire la percée:
J'avais un certificat dans le dossier personnel du magasin Machine. Il a expiré et mon responsable en a publié un nouveau. Le nouveau a échoué pour moi avec cette erreur. J'ai essayé beaucoup de choses sur Google, mais j'ai finalement résolu le problème en utilisant une solution complètement différente.
J'ai installé les deux certificats, l'un expiré et le plus récent. Ensuite, j'ai utilisé cette commande pour en obtenir une liste:
certutil -store My
Je reçois cette sortie (info est faux et autre certificat ne sont pas répertoriés):
================ Certificate 1 ================
Serial Number: 6d
Issuer: [email protected], CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
NotBefore: 03-Jan-2013 3:33 PM
NotAfter: 03-Mar-2013 3:33 PM
Subject: [email protected], CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 98 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
Key Container = {E5BC0912-7808-4B89-B457-31946DE5990E}
Unique container name: dfedfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed
================ Certificate 2 ================
Serial Number: 6d
Issuer: [email protected], CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
NotBefore: 03-Nov-2013 3:33 PM
NotAfter: 03-Dec-2013 3:33 PM
Subject: [email protected], CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 30 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
Key Container = {E5BC0912-7808-4B89-B457-31946DE5960E}
*Unique container name:* 55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed
Maintenant, tout semble aller pour le mieux, mais le certificat 1 a expiré et fonctionne si j'essaie de le lier à un port alors que le certificat 2 échoue avec l'erreur 1312.
La différence principale qui m'a déconcerté était le Nom du conteneur unique property. Il devrait représenter un fichier de clé physique sur le disque dur dans le %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\
Pour le certificat 1, le fichier existait, mais pour le certificat 2, ce fichier n'existait pas. Après avoir cherché, j'ai trouvé le fichier contre le Certificat 2 dans le sous-dossier du dossier %AppData%\Microsoft\Crypto\. Ce sont des clés spécifiques à l'utilisateur et non des clés de niveau machine. Il est étonnant que le certificat soit importé dans le magasin d'informatique, mais qu'il conserve toujours la clé de conteneur du magasin de l'utilisateur.
J'ai supprimé le fichier '55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239' du dossier AppData et j'ai exécuté la commande de réparation de mon certificat 2 dans le magasin:
certutil -repairstore My 2
Cette fois, le nom du conteneur unique reflétait un fichier dans le dossier approprié sous '% ProgramData%\Microsoft\Crypto \' et tout a commencé à fonctionner.
J'espère que cela est utile à quelqu'un.
J'ai acheté un certificat officiel Thawte pour sécuriser un service Web auto-hébergé (application console) sur un port spécifique de notre serveur Internet ..__ J'ai ensuite reçu le certificat Thawte et je l'ai installé avec mmc sur notre serveur Internet. (le certificat était alors visible sous «Autorités de certification racines de confiance» (avec l'icône de clé sur l'image, ce qui montre que le certificat contient une clé privée ce qui est obligatoire pour pouvoir le lier à un port d'ailleurs).
La prochaine étape consistait à activer le <port> pour https:
netsh http add urlacl url=https://+:<port>/ user=everyone
(ce qui n'était pas un problème)
La prochaine étape consistait à activer le port () pour https:
netsh http add sslcert ipport=0.0.0.0:<port> certhash=<thumbprint to certificate> appid={<guid to application>}
Cela a échoué avec le message d'erreur:
Echec de l'ajout du certificat SSL, Erreur: 1312 Une session d'ouverture de session spécifiée n'existe pas. Il peut être déjà terminé.
J’ai ensuite cherché sur Internet et essayé diverses solutions de contournement suggérées (sans succès).
La solution pour mon cas consistait à ajouter certstorename = Root à la commande netsh:
netsh http add sslcert ipport=0.0.0.0:<port *1)> certstorename=Root certhash=<thumbprint to certificate *2)> appid={<guid to application *3)>}
Remarques:
Si no certstorename est appliqué à la commande net netsh, netsh prend la valeur par défaut, ce qui est MY (ce qui cible le magasin de certificats: " Personnel " où auto-signé les certificats sont stockés normalement).
Root cible le magasin de certificats: „Autorités de certification racines de confiance“
* 1): Le port, vous souhaitez utiliser la connexion
* 2): Vous pouvez extraire l'empreinte numérique du certificat si vous ouvrez le certificat (sur un système Windows, double-cliquez simplement sur le certificat dans l'explorateur) - sélectionnez l'onglet "Détails" et cliquez sur "Empreinte numérique". L'empreinte numérique est ensuite affichée et peut être copiée. Copiez l'empreinte numérique et supprimez tous les espaces ...
* 3): Comme appid, vous pouvez utiliser n'importe quel ID sous la forme {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} car l’APPID n’est qu’informatif. La commande «netsh http show sslcert» permet d’interroger les certificats liés sur la machine entière et le verra voir informatif, lequel appid est lié à quel certificat (pas vraiment utile dans la pratique d'ailleurs) Dans mon cas, j'ai pris le GUID généré (par VS généré) à mon application de service web
Je me suis battu contre l'erreur 1312 toute la journée. Ce qui a été résolu pour moi, c'est d'importer le certificat au format mmc au format .p12 au lieu d'un fichier .crt. Si vous le créez avec OpenSSL, une fois le fichier .crt créé, procédez comme suit:
pkcs12 -export -in server.crt -inkey server.key -name “Your Name” -out server.p12
Comme décrit . Lorsque vous allez l'importer dans mmc, ce sera un fichier appelé "échange d'informations personnelles" (et apparemment, un fichier .pfx fonctionnerait également).
Je suis nouveau dans l'écriture de serveurs et dans l'utilisation de SSL et je ne sais pas pourquoi cela fonctionne, mais j'espère que cela aidera.
Dans mon cas, le problème était que le fichier CER n'avait pas de clé privée attachée.
J'ai attaché PK à l'aide de ces commandes OpenSSL:
openssl x509 -in server.der -inform DER -out server.pem -outform PEM
openssl pkcs12 -export -in server.pem -inkey serverkey.pem -out server.p12
Fonctionne pour les fichiers CER/DER.
Le problème se trouvait à l'étape 4. J'utilisais l'empreinte numérique du certificat racine pour la valeur de certhash. Pour résoudre ce problème, je devais revenir à la MMC et actualiser le dossier Certificats (ordinateur local) -> Personnel -> Certificat. Utilisez ensuite l'empreinte numérique du certificat qui est "délivré par" l'autorité de certification racine.
Cela peut sembler évident. Cependant, je pense que cela peut faire économiser un peu de temps à quelqu'un qui se gratte la tête. J'avais importé un fichier avec l'extension .cer sous mon dossier Certificats personnels (pour le compte Ordinateur personnel). Après un moment, j'ai réalisé que je devais importer le fichier avec l'extension * .pfx à la place. Corrigé ça et voilà! Problème résolu!
J'ai eu le même problème et résolu d'importer le certificat en utilisant cette commande:
c:> certutil -importPFX certname.pfx
Maintenant, le certificat apparaît en utilisant cette commande:
c:> certutil -store my
avant que cette commande le certificat n'apparaisse pas
Il existe plusieurs façons de recevoir cette erreur (voir ci-dessus pour d'autres réponses).
Une autre façon de recevoir cette erreur spécifique consiste à tenter de lier un certificat à un port lorsque le certificat ne se trouve pas dans le magasin approprié.
Vérifiez que le certificat est stocké dans le magasin racine LocalMachine (vous pouvez utiliser certutil ou certmgr.exe à partir de la ligne de commande pour le vider correctement).
grammaire mise à jour :)
Si:
- vous n'avez pas IIS sur votre machine (fonctionnant avec une WCF auto-hébergée, par exemple), et
- vous avez fait votre demande de certification sur une autre machine à l'aide de IIS Manager (car vous ne compreniez pas que la clé privée provient de chiffrements incorporés dans la demande de certification - et plus tard du
.pb7émis)
puis:
- allez simplement installer le
.pb7sur la machine IIS que vous avez utilisée pour faire la demande de certification (ordinateur local/personnel/certificats - en utilisant mmc); - exporter le certificat de cette machine, y compris sa clé privée (attribuer un mot de passe); et
- installez-le à l'aide de mmc sur le serveur WCF (ordinateur local/personnel/certificats - à l'aide de mmc).
Ensuite, netsh vous permettra de vous connecter au port 443. Pas plus d'erreurs 1312.
Juste pour jeter encore une autre réponse sur le ring, voici le problème que j'ai eu:
Bien que j'aie importé mon certificat dans le magasin de certificats (Local Computer)\..., je l'avais importé dans la section Trusted Root Certification Authorities. Je devais l'importer dans la section Personal, sinon cette erreur se produirait.
J'ai eu la même erreur lorsque j'ai créé un certificat auto-signé avec OpenSSL (BouncyCastle). Je l'ai résolu avec l'aide de ce message: Impossible d'exporter le certificat généré avec une clé privée vers un tableau d'octets dans .net 4.0/4.5
Je devais ajouter:
RsaPrivateKeyStructure rsa = RsaPrivateKeyStructure.GetInstance(seq); //new RsaPrivateKeyStructure(seq);
RsaPrivateCrtKeyParameters rsaparams = new RsaPrivateCrtKeyParameters(
rsa.Modulus, rsa.PublicExponent, rsa.PrivateExponent, rsa.Prime1, rsa.Prime2, rsa.Exponent1, rsa.Exponent2, rsa.Coefficient);
var rsaPriv = DotNetUtilities.ToRSA(rsaparams);
var cspParams = new CspParameters
{
KeyContainerName = Guid.NewGuid().ToString(),
KeyNumber = (int)KeyNumber.Exchange,
Flags = CspProviderFlags.UseMachineKeyStore
};
var rsaPrivate = new RSACryptoServiceProvider(cspParams);**
// Import private key from BouncyCastle's rsa
rsaPrivate.ImportParameters(rsaPriv.ExportParameters(true));
// Set private key on our X509Certificate2
x509.PrivateKey = rsaPrivate;
SI vous avez importé le certificat à l'aide de .NET, vous devez utiliser des indicateurs d'importation spécifiques:
/// <summary>
/// Imports X.509 certificate from file to certificate store.
/// </summary>
/// <param name="fileName">Certificate file.</param>
/// <param name="password">Password.</param>
/// <param name="storeName">Store name.</param>
/// <param name="storeLocation">Store location.</param>
public static void ImportCertificate(string fileName, string password, StoreName storeName, StoreLocation storeLocation) {
var keyStorageFlags =
X509KeyStorageFlags.PersistKeySet
| (storeLocation == StoreLocation.LocalMachine ? X509KeyStorageFlags.MachineKeySet : X509KeyStorageFlags.UserKeySet);
var cert = new X509Certificate2(fileName, password, keyStorageFlags);
var store = new X509Store(storeName, storeLocation);
store.Open(OpenFlags.MaxAllowed);
store.Add(cert);
store.Close();
}
La méthode ImportCertificate fait partie du package Woof.Security créé par moi.
J'ai eu exactement le même problème même si mon fichier .pfx avait une clé privée. L'ajout du certificat avec la console MMC a abouti, mais l'ajout par programme à l'aide de la méthode .Net X509Store.Add (X509Certificate2) a échoué à chaque fois avec l'erreur 1312. Le certificat comportait même un signe de clé sur l'icône.
Après plusieurs jours, nous avons finalement décidé de créer un nouveau certificat en utilisant makecert.exe, comme suggéré dans les publications. Après cela, tout allait bien. La clé est apparue dans% ProgramData%\Microsoft\Crypto\RSA\MachineKeys. Pour une raison quelconque, mon fichier pfx antérieur n'était pas compatible.
D'après mon expérience, tant que votre clé n'apparaît pas dans% ProgramData%\Microsoft\Crypto\RSA\MachineKeys \, la liaison avec 'netsh http add sslcert ....' échouera.
Donc, pour ajouter (encore) fixer/situation.
J'avais un code C # qui utilisait BouncyCastle pour créer des certificats auto-signés.
<packages>
<package id="BouncyCastle" version="1.8.1" targetFramework="net45" />
Ainsi, mon code a créé les certificats ET les a placés aux emplacements appropriés dans le Cert-Store.
En utilisant les astuces ici, mon installation de On Premise Service Bus 1.1 échouait ... et cela m’a amené ici.
J'ai fini par supprimer les deux certificats créés par mon code BouncyCastle (à partir du magasin de certificats) et les réimporter (avec des clés privées) ... et tout cela a fonctionné ..__
Certificats (ordinateur local)/Personnel/Certificats
alors j'ai copié collé (dans le mmc) à n'importe quel autres endroits (magasins) j'en avais besoin.
Mon "avant" et "après" avaient exactement la même apparence de mes yeux dans MMC, MAIS cela réglait le problème. Allez comprendre.
Cela fait des heures que je travaille sur ce sujet et j'ai lu ce que @ DoomerDGR8 a dit plus haut, mais ma solution était beaucoup plus simple. Iran
C:\Windows\system32> certutil -store TRUSTEDPUBLISHER
Cette liste énumère plusieurs certificats que j'ai installés, puis j'ai exécuté repair store sur le certificat indiquant que j'avais un problème d'installation avec netsh.
C:\Windows\system32> certutil -repairstore TRUSTEDPUBLISHER 6
Le nombre 6 à la fin représente l'index de votre certificat, trouvé dans le magasin, espérons que cela vous aidera
Dans mon cas, il me manque le certificat clé privée.
Dans mon cas, lors de la création du certificat, j'ai choisi un nom différent de My pour mon nom Cert Store. Le nom par défaut est MY. Donc, si le vôtre est différent, ajoutez certstorename =Votre nom de magasin fourni à la commande.
L'argument certstorename doit être la valeur de chaîne du StoreName enumeration de l'espace de noms du framework .net System.Security.Cryptography.X509Certificates.
Je viens d'avoir encore une autre erreur. J'ai renouvelé un certificat expiré pour notre service WorkFolders auprès de notre autorité de certification utilisant la même clé privée. Ensuite, j'ai toujours l'erreur 1312. Même si la gestion des certificats indique que j'ai une clé privée.
Je ne pouvais résoudre le problème qu'en réémettant un nouveau certificat (sans l'option de renouvellement). Ensuite, cela a fonctionné du premier coup.
Cela aidera peut-être quelqu'un qui a également essayé l'option de renouvellement.