Симптомы
При попытке запуска на компьютере под управлением Windows Server 2008 R2 или Windows 7 следующую команду netsh :
Netsh http добавить sslcert ipport = certhash< IP-адрес и порт для привязки SSL > =< хеш сертификата > appid = slctlstorename< GUID владельца приложения > =< имя, в котором хранится список доверия Сертификатов хранилища > sslctlidentifier =< значение CTL >Примечание. Эта команда добавляет список доверия сертификатов (CTL) к привязке безопасного sockets layer (SSL).
Тем не менее операция не выполняется и появляется сообщение об ошибке, подобное приведенному ниже:
Сбой добавления сертификата SSL: 1312
Указанный сеанс не существует. Возможно, он уже был завершен.
Причина
Эта проблема возникает, так как строки Юникода в параметрах структуры неправильно усекаются при передаче этих строк для удаленного вызова процедуры (RPC). Таким образом происходит сбой операции проверки подлинности.
Решение
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Не существует предварительных условий.
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
Может потребоваться перезагрузить компьютер после установки данного исправления.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Сведения о файлах
Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Примечания к сведениям о файлах Windows 7 и Windows Server 2008 R2
Важно. Исправления для Windows Server 2008 R2 и Windows 7 включены в одни и те же пакеты. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Чтобы запросить пакет исправления, который применяется к одной или обеим ОС, установите исправление, описанное в разделе «Windows 7/Windows Server 2008 R2» страницы. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.
-
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах для Windows Server 2008 R2 и Windows 7». Файлы MUM и MANIFEST, а также связанные файлы каталога безопасности (CAT) чрезвычайно важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Для всех поддерживаемых 86-разрядных версий Windows 7
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Cng.sys |
6.1.7600.16385 |
369,568 |
14-Jul-2009 |
01:17 |
x86 |
Ksecdd.sys |
6.1.7600.20667 |
67,472 |
13-Mar-2010 |
07:16 |
x86 |
Ksecpkg.sys |
6.1.7600.20667 |
133,512 |
13-Mar-2010 |
07:16 |
x86 |
Lsasrv.dll |
6.1.7600.20667 |
1,037,312 |
13-Mar-2010 |
07:13 |
x86 |
Lsasrv.mof |
Неприменимо |
13,780 |
10-Jun-2009 |
21:33 |
Неприменимо |
Lsass.exe |
6.1.7600.16385 |
22,528 |
14-Jul-2009 |
01:14 |
x86 |
Secur32.dll |
6.1.7600.16385 |
22,016 |
14-Jul-2009 |
01:16 |
x86 |
Sspicli.dll |
6.1.7600.20667 |
100,352 |
13-Mar-2010 |
07:13 |
x86 |
Sspisrv.dll |
6.1.7600.20667 |
15,360 |
13-Mar-2010 |
07:13 |
x86 |
Для всех поддерживаемых 64-разрядных версий Windows 7 и Windows Server 2008 R2
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Cng.sys |
6.1.7600.16385 |
460,504 |
14-Jul-2009 |
01:43 |
x64 |
Ksecdd.sys |
6.1.7600.20667 |
95,624 |
13-Mar-2010 |
08:00 |
x64 |
Ksecpkg.sys |
6.1.7600.20667 |
152,968 |
13-Mar-2010 |
08:00 |
x64 |
Lsasrv.dll |
6.1.7600.20667 |
1,446,912 |
13-Mar-2010 |
07:57 |
x64 |
Lsasrv.mof |
Неприменимо |
13,780 |
10-Jun-2009 |
20:52 |
Неприменимо |
Lsass.exe |
6.1.7600.16385 |
31,232 |
14-Jul-2009 |
01:39 |
x64 |
Secur32.dll |
6.1.7600.16385 |
28,160 |
14-Jul-2009 |
01:41 |
x64 |
Sspicli.dll |
6.1.7600.20667 |
136 192 |
13-Mar-2010 |
07:57 |
x64 |
Sspisrv.dll |
6.1.7600.20667 |
28,672 |
13-Mar-2010 |
07:57 |
x64 |
Lsasrv.mof |
Неприменимо |
13,780 |
22-Jul-2009 |
23:19 |
Неприменимо |
Secur32.dll |
6.1.7600.20667 |
22,016 |
13-Mar-2010 |
07:13 |
x86 |
Sspicli.dll |
6.1.7600.20667 |
96,768 |
13-Mar-2010 |
07:11 |
x86 |
Для всех поддерживаемых версий Windows Server 2008 R2 для систем на базе процессоров IA-64
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
---|---|---|---|---|---|
Cng.sys |
6.1.7600.16385 |
787,736 |
14-Jul-2009 |
01:52 |
IA-64 |
Ksecdd.sys |
6.1.7600.20667 |
179,600 |
13-Mar-2010 |
06:42 |
IA-64 |
Ksecpkg.sys |
6.1.7600.20667 |
307,088 |
13-Mar-2010 |
06:42 |
IA-64 |
Lsasrv.dll |
6.1.7600.20667 |
2,654,720 |
13-Mar-2010 |
06:34 |
IA-64 |
Lsasrv.mof |
Неприменимо |
13,780 |
10-Jun-2009 |
20:57 |
Неприменимо |
Lsass.exe |
6.1.7600.16385 |
56,320 |
14-Jul-2009 |
01:44 |
IA-64 |
Secur32.dll |
6.1.7600.16385 |
48,640 |
14-Jul-2009 |
01:48 |
IA-64 |
Sspicli.dll |
6.1.7600.20667 |
275,456 |
13-Mar-2010 |
06:38 |
IA-64 |
Sspisrv.dll |
6.1.7600.20667 |
45,568 |
13-Mar-2010 |
06:38 |
IA-64 |
Lsasrv.mof |
Неприменимо |
13,780 |
22-Jul-2009 |
23:19 |
Неприменимо |
Secur32.dll |
6.1.7600.20667 |
22,016 |
13-Mar-2010 |
07:13 |
x86 |
Sspicli.dll |
6.1.7600.20667 |
96,768 |
13-Mar-2010 |
07:11 |
x86 |
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Дополнительные сведения
Дополнительные сведения о настройке порта с помощью SSL-сертификат, посетите следующий веб-узел корпорации Майкрософт:
Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт
Сведения о дополнительных файлах
Сведения о дополнительных файлах для Windows 7 и Windows Server 2008 R2
Дополнительные файлы для всех поддерживаемых 86-разрядных версий Windows 7
Имя файла |
Update.mum |
Версия файла |
Неприменимо |
Размер файла |
1,674 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
X86_1421ac8a9f6ef3ce8b937b0ae56209ae_31bf3856ad364e35_6.1.7600.20667_none_23708961b103e635.manifest |
Версия файла |
Неприменимо |
Размер файла |
691 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
X86_microsoft-windows-lsa_31bf3856ad364e35_6.1.7600.20667_none_a6c221e8d72a628b.manifest |
Версия файла |
Неприменимо |
Размер файла |
103,660 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
11:02 |
Платформа |
Неприменимо |
Дополнительные файлы для всех поддерживаемых 64-разрядных версий Windows 7 и Windows Server 2008 R2
Имя файла |
Amd64_c1f3ccb091321f5245e74fc410074621_31bf3856ad364e35_6.1.7600.20667_none_649488b89ab1f4e7.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,032 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Amd64_efb13a188cefafdfd852e77573ce5875_31bf3856ad364e35_6.1.7600.20667_none_664f738e7e9b11f8.manifest |
Версия файла |
Неприменимо |
Размер файла |
695 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Amd64_microsoft-windows-lsa_31bf3856ad364e35_6.1.7600.20667_none_02e0bd6c8f87d3c1.manifest |
Версия файла |
Неприменимо |
Размер файла |
103,664 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
11:05 |
Платформа |
Неприменимо |
Имя файла |
Update.mum |
Версия файла |
Неприменимо |
Размер файла |
1,906 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Wow64_microsoft-windows-lsa_31bf3856ad364e35_6.1.7600.20667_none_0d3567bec3e895bc.manifest |
Версия файла |
Неприменимо |
Размер файла |
86,382 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
07:37 |
Платформа |
Неприменимо |
Дополнительные файлы для всех поддерживаемых версий Windows Server 2008 R2 с архитектурой IA-64
Имя файла |
Ia64_aba017386f21d586120feaa3c20f5705_31bf3856ad364e35_6.1.7600.20667_none_3341405f4af61718.manifest |
Версия файла |
Неприменимо |
Размер файла |
1,030 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Ia64_microsoft-windows-lsa_31bf3856ad364e35_6.1.7600.20667_none_a6c3c5ded7286b87.manifest |
Версия файла |
Неприменимо |
Размер файла |
103,662 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Update.mum |
Версия файла |
Неприменимо |
Размер файла |
1,684 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
10:55 |
Платформа |
Неприменимо |
Имя файла |
Wow64_microsoft-windows-lsa_31bf3856ad364e35_6.1.7600.20667_none_0d3567bec3e895bc.manifest |
Версия файла |
Неприменимо |
Размер файла |
86,382 |
Дата (UTC) |
13-Mar-2010 |
Время (UTC) |
07:37 |
Платформа |
Неприменимо |
I had been dealing with this issue and I’m using a self-hosted WCF service. I just made the breakthrough:
I had a certificate in the personnel folder for the Machine store. It expired and my manager issued a new one. The new one failed for me with this error. I tried a lot of stuff from Google but in the end, resolved the issue using a completely different solution.
I installed both certificates- the expired one and the newer one. Then I used this command to get a list of them:
certutil -store My
I get this output (info is fake and other certificate are not listed):
================ Certificate 1 ================
Serial Number: 6d
Issuer: E=operations@voicetrust.com, 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: E=hgulzar@voicetrust.com, 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: E=operations@voicetrust.com, 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: E=hgulzar@voicetrust.com, 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
Now, everything seems OK but certificate 1 is expired and works if I try to bind it to a port whereas Certificate 2 fails with Error 1312.
The key difference that baffled me was the Unique container name property. It should be representing a physical key file on the hard drive in the %ProgramData%MicrosoftCryptoRSAMachineKeys
For Certificate 1, the file was there but for Certificate 2, there was no such file. After searching I found the file against Certificate 2 in the sub folder of %AppData%MicrosoftCrypto
folder. That’s user specific keys not Machine level keys. It’s amazing that the certificate is being imported into Computer store yet it always keeps the container key of User’s store.
I deleted the ’55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239′ file under the AppData folder and ran the repair command for my certificate 2 on the store:
certutil -repairstore My 2
This time, the Unique container name was reflecting a file in the proper folder under ‘%ProgramData%MicrosoftCrypto’ and everything started working.
Hope this is helpful to someone.
I’m trying to connect a SSL cert to my http listener application. I’m running on Windows Server 2008 SP2.
I’m using the netsh http command such as the following to do this.
add sslcert ipport=10.0.0.1:443 certhash=somelongcerthash appid={somelongappid}
When I use the command I get the following error message.
SSL Certificate add failed, Error: 1312
A specified logon session does not exist. It may already have been terminated.
I’m logged onto the server as a domain admin when I run the command.
I previously had this application setup to use SSL on a different port with the same cert, the application ran fine for a few weeks.
I was in the process of switching the application onto port 443 when this error started to occur.
As part of the switch I found the cert was also defined for a web site. I undefined the SSL and port binding for the web site. I reconnected to cert to the old Port and successfully test the application again, then deleted the binding using the «delete sslcert»
command and attempt to use the same «add sslcert» command with port 443 and got the failure. Now I can’t use the add sslcert command no matter what port I specify without getting the failure message.
Microsoft has a fix for this error message for Windows 7 and Windows Server 2008 R2, but not Windows Server 2008 SP2.
Googling around I see a number of other people that have run into this issue but don’t see any remedies that work for me.
—Mark
I’m building a C# console app that’ll:
[1.] Generate a self-signed certificate.
[2.] Add it to the Personal (Local Computer Store)
[3.] And finally assign that certificate to a port number on the machine with the netsh command.
So far, I got parts [1.] and [2.] working perfectly, but on [3.] I’m plagued with the useless and non-informal error message:
SSL Certificate add failed, Error: 1312 A specified logon session does
not exist. It may already have been terminated.
When I go look at Microsoft’s official page about this issue:
https://support.microsoft.com/en-us/kb/981506
It’s basically telling me that this is a Windows Operating System bug and that I should request a hotfix.
My Hack Solution To This Problem:
One way I was able to finally bypass this error, was by Opening IIS Home>Open «Server Certificates» Feature> And then Importing my .pfx certificate.
By importing the .pfx to IIS, I seemed to be able to get around the issue without trouble. I only needed to generate a .pfx by running both these two commands in order
1.) C:OpenSSL-Win32bin>openssl req -x509 -sha256 -nodes -days 365 -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=www.example.com" -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
2.) C:OpenSSL-Win32bin>openssl pkcs12 -export -out cert.pfx -inkey privateKey.key -in certificate.crt -passout pass:
So if I run those two commands to openssl right now, and import them via IIS to my Personal Local Computer certificate store, I’ll have no SSL Certificate add failed, Error: 1312
problem.
But if I add the newly generated certificate programatically to my Personal Local Computer certificate store, then I do get the Error:1312 problem.
Here’s my code:
using CERTENROLLLib;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography.X509Certificates;
using System.Text;
using System.Threading.Tasks;
using System.IO;
using System.Text;
using System.Security.Cryptography;
using System.Diagnostics;
namespace Generate_X509_Certificate
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Guid.NewGuid().ToString());
Console.ReadLine();
// Launch OpenSSL:
string cPath = @"C:OpenSSL-Win32bin";
string filename = Path.Combine(cPath, @"openssl.exe");
// Generate a .crt file
Console.WriteLine(@"Generating SSL Certificate...");
ProcessStartInfo startInfo = new ProcessStartInfo(@"C:OpenSSL-Win32binopenssl.exe", @"req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt -subj ""/C=US/ST=California/L=SanFrancisco/CN=SecurityEncryption""");
Process.Start(startInfo);
// Combine the .crt with the .key to form a more Windows friendly .pfx
Console.WriteLine(@"Combining Private Key With Certificate...");
Process proc2 = Process.Start(filename, "pkcs12 -export -out cert.pfx -inkey privateKey.key -in certificate.crt -passout pass:");
proc2.Close();
// Store our newly created .pfx file as a variable
X509Certificate2 cert = new X509Certificate2(Directory.GetCurrentDirectory()+@"cert.pfx");
// Add our .pfx file into the Personal Local Computer store:
var store = new X509Store(StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadWrite);
store.Add(cert);
store.Close();
// Finally, use netsh to assign this newly generated certificate to port 6613
string s1 = "netsh http add sslcert ipport=0.0.0.0:6613 certhash=" + cert.GetCertHashString() + " appid={" + Guid.NewGuid().ToString() + "}";
Process p1 = new Process();
p1.StartInfo.FileName = "netsh.exe";
p1.StartInfo.Arguments = s1;
p1.StartInfo.UseShellExecute = false;
p1.StartInfo.RedirectStandardOutput = true;
// 👎 this is where I get the error "SSL Certificate add failed, Error: 1312"
p1.Start();
}
}
}
Here’s the netsh command that works perfectly fine as long as I’m not executing it in this C# program:
netsh http add sslcert ipport=0.0.0.0:6613
certhash=8834efd403687b331363ce9e5657ba4ffba0075b
appid={e604f84f-e666-4ccf-af52-fdeca666b5e9}
The Confusing Part
So if you were to execute my openssl
commands verbatim from this thread, than import the .pfx
file generated by openssl into IIS and finally use the netssh
command as seen above with the proper certificate hash, than this entire thing works perfectly. But when you do what I just said automatically in the C# code above, I get the Error.
Another thing, the .pfx generated than imported into the store from this code will not work at all when you try to manually netsh
it through the command line.
Does anyone have any ideas?
Я создал WebService, используя WCF. Я занимаюсь самостоятельным хостингом, и я хочу включить HTTPS. Из моего понимания, чтобы это произошло, мне нужно создать сертификат и привязать к порту, который я хочу использовать.
Вот шаги, которые я сделал для этого:
- Создал сертификат на моей локальной машине, чтобы действовать в качестве корневого центра сертификации
- makecert -n «CN = My Root Certificate Authority» -r -sv RootCATest.pvk RootCATest.cer
- Открыл файл MMC.exe и импортировал сохраненный файл .cer в папку «Trusted Root CertificateCertificates»
- makecert -sk MyKeyName -iv RootCATest.pvk -n «CN = MyMachineName» -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
-
Создал сертификат временной службы из подписанного корневого центра сертификации
- makecert -sk MyKeyName -iv RootCATest.pvk -n «CN = MyMachineName» -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
-
Попробовал привязать сертификат к номеру порта (443 в этом случае)
- netsh http add sslcert ipport = 0.0.0.0: 443 certhash = 2c5ba85bcbca412a74fece02878a44b285c63981 appid = {646937c0-1042-4e81-a3b6-47d678d68ba9}
Результатом этапа 4 является следующая ошибка:
Ошибка сертификата SSL, ошибка 1312
Указанный сеанс входа в систему не существует. Возможно, оно уже завершено.
Кто-нибудь знает, почему я могу получить эту ошибку?
Ответ 1
У меня была такая же ошибка. В первый раз, когда Микель сказал, мне пришлось переместить сертификат в папку Сертификаты (локальный компьютер) → Личный → Сертификат. У меня была такая же ошибка, когда я импортировал тот же сертификат на другой компьютер. Причина заключалась в том, что я использовал certmgr.msc для импорта сертификата., В открывшемся окне отображается «Сертификаты — текущий пользователь». Сертификаты, импортированные с помощью этого окна, приводят к сбою netsh с ошибкой 1312. Обязательно используйте оснастку сертификатов в MMC для импорта сертификатов. В оснастке сертификатов с MMC отображается «Сертификаты (локальный компьютер)». Это позволяет выполнить netsh.
Ответ 2
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
У меня была такая же проблема, и я потратил пару дней, пытаясь понять, в чем причина.
Короче говоря: проблема в том, что вы установили сертификат на сервере winrm
, у которого нет ЧАСТНОГО КЛЮЧА.
Я проверил это несколько раз. Вы должны удалить свой сертификат и перестроить его, используя makecert
, например, как это описано здесь: http://blogs.technet.com/b/jhoward/archive/2005/02/02/365323.aspx
Вы можете легко проверить, имеет ли ваш сертификат закрытый ключ: mmc
— certificates
— local machine
— personal
. Посмотрите на значок сертификата — он ДОЛЖЕН иметь знак ключа на значке.
Ответ 3
Я имел дело с этой проблемой, и я использую самообслуживаемую службу WCF. Я только что сделал прорыв:
У меня был сертификат в папке с персоналом для магазина Machine. Это истекло, и мой менеджер выпустил новый. Новая ошибка для меня с этой ошибкой. Я много раз пробовал у Google, но, в конце концов, решил проблему, используя совершенно другое решение.
Я установил оба сертификата — истекший и новый. Затем я использовал эту команду, чтобы получить их список:
certutil -store My
Я получаю этот вывод (информация поддельна, а другой сертификат не указан):
================ 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
Теперь все выглядит нормально, но срок действия сертификата 1 и работает, если я пытаюсь связать его с портом, тогда как сертификат 2 выходит из строя с ошибкой 1312.
Ключевым отличием, которое меня озадачило, было свойство Уникальное имя контейнера. Он должен представлять физический файл ключа на жестком диске в %ProgramData%MicrosoftCryptoRSAMachineKeys
Для сертификата 1 файл был там, но для сертификата 2 такого файла не было. После поиска я нашел файл с сертификатом 2 в подпапке папки %AppData%MicrosoftCrypto
. Эти пользовательские ключи не являются клавишами уровня машины. Удивительно, что сертификат импортируется в хранилище компьютеров, но он всегда хранит ключ контейнера в магазине пользователя.
Я удалил файл ’55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239′ в папке AppData и выполнил команду восстановления для моего сертификата 2 в хранилище:
certutil -repairstore My 2
На этот раз имя уникального контейнера отобразило файл в соответствующей папке в разделе «% ProgramData%MicrosoftCrypto», и все началось.
Надеюсь, это кому-то поможет.
Ответ 4
Я купил официальный официальный сертификат Thawte, чтобы защитить веб-службу собственного хоста (консольного приложения) через определенный порт на нашем интернет-сервере.
Затем я получил сертификат Thawte и установил его с помощью mmc на нашем интернет-сервере (тогда сертификат был доступен для просмотра в разделе «Доверенные корневые центры сертификации» (с иконкой ключа на изображении, что показывает, что сертификат содержит закрытый ключ, что является обязательным чтобы иметь возможность привязывать его к порту btw).
Следующий шаг состоял в том, чтобы включить <port>
для https:
netsh http add urlacl url=https://+:<port>/ user=everyone
(что не было проблемой)
Следующим шагом было включить порт() для https:
netsh http add sslcert ipport=0.0.0.0:<port> certhash=<thumbprint to certificate> appid={<guid to application>}
Ошибка с сообщением об ошибке:
Не удалось добавить сертификат SSL, ошибка: 1312 Указанный сеанс входа в систему не существует. Возможно, оно уже завершено.
Затем я искал в Интернете и пробовал различные предлагаемые обходные пути (без успеха).
Решение для моего случая состояло в том, чтобы добавить certstorename = Root в команду netsh:
netsh http add sslcert ipport=0.0.0.0:<port *1)> certstorename=Root certhash=<thumbprint to certificate *2)> appid={<guid to application *3)>}
Примечания:
Если для команды net netsh применяется no certstorename, netsh принимает значение по умолчанию, то есть MY (что указывает на хранилище сертификатов: « Личное«, где самоподписанные сертификаты хранятся в обычном режиме).
Корень нацелен на хранилище сертификатов: «Доверенные корневые центры сертификации»
* 1): порт, вы хотите использовать соединение
* 2): вы можете извлечь отпечаток в сертификат, если вы откроете сертификат (в системе Windows просто дважды щелкните сертификат в проводнике) — выберите вкладку «Сведения» и нажмите «Отпечаток». Затем отображается «отпечаток» и может быть скопирован. Скопируйте Thumbprint и удалите все пробелы…
* 3): В качестве приложения вы можете использовать любой идентификатор в форме {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, поскольку APPID является только информативным.
С помощью команды «netsh http show sslcert» вы можете запросить связанные сертификаты на всей машине, и она увидит информативное, какое приложение связано с каким сертификатом (на самом деле это не очень полезно на практике b.t.w.)
В моем случае я взял (из VS сгенерированного) GUID в мое приложение веб-службы
Ответ 5
Я борюсь с ошибкой 1312 весь день, что исправлено для меня было импортировать сертификат в mmc как .p12 файл, а не в .crt. Если вы создаете его с помощью OpenSSL, то после создания .crt выполните:
pkcs12 -export -in server.crt -inkey server.key -name "Your Name" -out server.p12
Как описано. Когда вы перейдете на импорт в mmc, это будет вызванный файл «Personal Information Exchange» (и, видимо, будет работать и файл .pfx).
Я новичок в написании серверов и работе с SSL, и я понятия не имею, почему это работает, но я надеюсь, что это поможет.
Ответ 6
В моем случае проблема заключалась в том, что файл CER не имеет закрытого ключа.
Я подключил PK, используя эти команды 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
Работает для файлов CER/DER.
Ответ 7
Проблема была на этапе 4. Я использовал Thumbprint из корневого сертификата для значения в certhash. Чтобы решить эту проблему, мне пришлось вернуться в MMC и обновить папку сертификатов (локальный компьютер) → Personal → Certificate. Затем используйте «Отпечаток» из сертификата, который «выдан» Корневым центром сертификации.
Ответ 8
Существует несколько способов получения этой ошибки (см. выше для других ответов).
Другой способ получить эту конкретную ошибку — попытаться привязать сертификат к порту, когда сертификат не находится в соответствующем хранилище.
Убедитесь, что сертификат хранится в хранилище Root LocalMachine (вы можете использовать certutil или certmgr.exe из командной строки, чтобы сбрасывать его правильно).
обновленная грамматика:)
Ответ 9
У меня была та же проблема и я решил импортировать сертификат с помощью этой команды:
c:> certutil -importPFX certname.pfx
Теперь сертификат появляется с помощью этой команды:
c:> certutil -store my
перед этой командой сертификат не отображается
Ответ 10
Если:
- у вас не было IIS на вашем компьютере (работает с самодостаточным WCF, скажем) и
- вы сделали свой запрос сертификата на другой машине с помощью диспетчера IIS (потому что вы не понимали, что секретный ключ исходит от шифров, встроенных в запрос cert, а позже выпущенного
.pb7
)
то
- просто запустите установку
.pb7
на машине IIS, которую вы использовали для запроса сертификата (локальная машина/личная/сертификация — с использованием mmc); - экспортировать сертификат с этого компьютера, включая его закрытый ключ (назначить пароль); и
- установите его с помощью mmc на сервере WCF (локальный компьютер/персональный/сертификат — с помощью mmc).
Затем netsh
позволит вам привязываться к порту 443. Не более 1312 ошибок.
Ответ 11
Просто, чтобы выпустить еще один ответ на ринг, это проблема, которую я имел:
Хотя я импортировал свой сертификат в хранилище сертификатов (Local Computer)...
, я импортировал его в раздел Trusted Root Certification Authorities
. Мне нужно было импортировать его в раздел Personal
, иначе эта ошибка произошла.
Ответ 12
Это может показаться очевидным; однако, я думаю, что это может спасти кого-то время царапин на голове. Я импортировал файл с расширением .cer в папку личных сертификатов (для учетной записи персонального компьютера). Через некоторое время я понял, что мне нужно импортировать файл с расширением *.pfx. Исправлено это и вуаля! Проблема решена!
Ответ 13
Если кто-то еще сталкивается с этой проблемой, и ответы здесь явно не отвечают на нее, основная проблема заключается в том, что частный ключ необходимо импортировать. Если вы не помечаете сертификат как экспортируемый при его импорте, закрытый ключ не импортируется, и вы не можете его привязать. Если вы удалите его и повторно импортируете и пометите его как экспортируемую, то он будет работать.
Он также должен быть локальным хранилищем, как указывали другие.
Ответ 14
У меня была такая же проблема, хотя в моем .pfx файле был закрытый ключ. Добавление сертификата с консоли MMC было успешным, но добавление программного использования метода .Net X509Store.Add(X509Certificate2) не выполнялось каждый раз с ошибкой 1312. У сертификата даже был знак ключа на значке.
Через несколько дней finaly решил сделать новый сертификат с помощью makecert.exe, как это предлагается в сообщениях здесь. После этого все было хорошо. Ключ появился в% ProgramData%MicrosoftCryptoRSAMachineKeys. По какой-то причине мой предыдущий файл pfx не был совместим.
По моему опыту, пока ваш ключ, не появляющийся в% ProgramData%MicrosoftCryptoRSAMachineKeys , связывается с ‘netsh http add sslcert….’.
Ответ 15
Аргумент certstorename
должен быть строковым значением StoreName перечисления из пространства имен .net framework System.Security.Cryptography.X509Certificates
.
Ответ 16
Я работаю над этим часами и в основном читаю, что сказал @DoomerDGR8, но мое исправление было намного проще. Я побежал
C:Windowssystem32> certutil -store TRUSTEDPUBLISHER
Здесь перечислены несколько сертификатов, которые я установил, затем я запустил магазин восстановления в сертификате, с которым у меня возникла проблема с установкой netsh.
C:Windowssystem32> certutil -repairstore TRUSTEDPUBLISHER 6
Число 6 в конце представляет индекс вашего сертификата, найденный в магазине, надеюсь, что это поможет
Ответ 17
В моем случае при создании сертификата я выбрал другое имя, чем «Мой» для моего имени в магазине. По умолчанию используется значение MY. Поэтому, если у вас другое, добавьте certstorename = Ваше предоставленное имя хранилища в команду.
Ответ 18
У меня была такая же ошибка при создании самоподписанного сертификата с OpenSSL (BouncyCastle), я разрешил его с помощью этого сообщения:
Невозможно экспортировать сгенерированный сертификат с закрытым ключом в массив байтов в .net 4.0/4.5
Мне пришлось добавить:
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 rsa
rsaPrivate.ImportParameters(rsaPriv.ExportParameters(true));
// Set private key on our X509Certificate2
x509.PrivateKey = rsaPrivate;
Ответ 19
Итак, добавьте (еще) исправление/ситуацию.
У меня был код С#, который использовал BouncyCastle для создания самозаверяющих сертификатов.
<packages>
<package id="BouncyCastle" version="1.8.1" targetFramework="net45" />
Итак, мой код создал сертификаты и поместил их в правильные места в Cert-Store.
Используя подсказки здесь, моя установка On Service Service Bus 1.1 не срабатывала… и это привело меня сюда.
Я закончил УДАЛЕНИЕ обоих сертификатов, созданных моим кодом BouncyCastle (из хранилища сертификатов) и реимпортацией их (с закрытыми ключами)…. и все это сработало.
Я импортировал FIRST в
Сертификаты (локальный компьютер)/Персональные/сертификаты
затем я скопировал вставку (в mmc) в любые другие места (магазины), в которых я нуждался.
Мои «до» и «после» выглядели точно так же из моих глаз в MMC, НО это исправляло проблему. Наведите указатель мыши.
Ответ 20
У меня была еще одна ошибка. Я обновил сертификат expired для нашей службы WorkFolders из нашего центра сертификации, используя тот же секретный ключ. Затем я всегда получал сообщение об ошибке 1312. Даже если управление сертификатами показывает, что у меня есть закрытый ключ.
Я мог бы решить проблему только путем повторного выдачи нового сертификата (без опции продления). Затем это сработало с первой попытки.
Возможно, это поможет кому-то, кто также попробовал вариант продления.
Ответ 21
В моем случае у меня отсутствует секретный ключ сертификата .
- Remove From My Forums
-
Question
-
I am trying to get a self signed SSL cert bound to port 8080 for WCF unit testing on my Windows 2008 R2 development box.
I reserved the url without error:
netsh http add urlacl url=https://+:8080/ user=EVERYONE
Unfortunately, when I try to add the SSL binding for my certificate I get a wacky error.
«netsh http add sslcert ipport=0.0.0.0:8080 certhash=BE3102FAF81366C47B4E284D07E163128676DE77 appid={283647f3-ef12-4f46-8aeb-d59fc072dcda}»
«SSL Certificate add failed, Error: 1312
A specified logon session does not exist. It may already have been terminated.»
Note, previously I had bound a diff cert and decided to unbind it and go with a new self signed cert. The first cert seemed to bind without error.
Cert1 generated from these instructions:
http://blogs.msdn.com/b/james_osbornes_blog/archive/2010/12/10/selfhosting-a-wcf-service-over-https.aspx
Cert2 generated from these instructions:
http://msdn.microsoft.com/en-us/library/ff648498.aspx
Anyone else ever run into this?
Answers
-
For any poor soul that still encounters this issue, the 1312 error may be referring to the certificate store user. Your certificate has to come from the local MACHINE certificate store, not the current user certificate store (if using certmgr, do mmc->add/remove
snapin ->computer account (NOT the default that comes up when you run certmgr.msc!!!). Then get the cert from the personal area of the computer account). Of course, the certificate you select should be valid too.Yes this thread is old, but the issue still exists, and you should try this before deleting things or generating a bunch of certificates.
-
Marked as answer by
Tuesday, November 13, 2012 4:22 PM
-
Marked as answer by
-
No, but it worked for Cert1. I finally deleted all the netsh config, regenerated a new cert, and did the steps for #2. Worked fine this time around.
thanks
-
Marked as answer by
scott_m
Saturday, March 12, 2011 3:50 AM
-
Marked as answer by
В идеале это нужно было сделать сразу после генерации нового сертификата Вот здесь описано как создать сертификат
Но, я этого не сделал. И после перезагрузки сервера я 3 часа ломал голову почему у меня не работает почта. Но благо я нашел решение. для начала выполняем в PowerShell
netsh http show sslcert
Нам это окно выдаст список сертификатов что есть, выделите все и скопируйте в текстовый документ, это нам еще пригодится.
Дальше :
netsh http delete sslcert ipport=0.0.0.0:444
Этим мы удалили старый сертификат что был привязан к 444 порту. Теперь в идеале должюна была сработать команда:
netsh http add sslcert ipport=0.0.0.0:444 certhash=ХЕШ СУММА СЕРТИФИКАТА appid=»{4dc3e181-e1445554554155455}»
certhash= и appid= я брал с того текстового документа что мы создали. Но сейчас когда начал писать эту статью, я понял что нужно было указать эту хеш сумму и эппайди от нового сертификата, тогда бы эта команда сработала….
Но! Я писал хеш старого сертификата и еппайди старого сертификата и я получил ошибку:
Сбой добавления сертификата SSL. Ошибка: 1312
Указанный сеанс работы не существует. Возможно, он уже завершен.
________________
Тут то я и застрял.
Но решение было найдено
Заходим в Диспетчер IIS
открываем сайт
открываем порт 444 и выбираем новый сертификат что мы генерировали. Жмем ОК. Перегружаем IIS или сервер целиком… И вуаля) Я вас поздравляю!!!)
Я создал WebService с помощью WCF. Я занимаюсь самостоятельным хостингом и хочу включить HTTPS. Насколько я понимаю, для этого мне нужно создать сертификат и привязать его к порту, который я хочу использовать.
Вот шаги, которые я сделал, чтобы справиться с этим:
- Создал сертификат на моем локальном компьютере, чтобы действовать как корневой центр сертификации
- makecert -n «CN=Мой корневой центр сертификации» -r -sv RootCATest.pvk RootCATest.cer
- Открыл MMC.exe и импортировал сохраненный файл .cer в папку «Доверенный корневой сертификатСертификаты».
- makecert -sk MyKeyName -iv RootCATest.pvk -n «CN=MyMachineName» -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
-
Создан временный сертификат службы из подписанного корневого центра сертификации.
- makecert -sk MyKeyName -iv RootCATest.pvk -n «CN=MyMachineName» -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
-
Попытка привязать сертификат к номеру порта (в данном случае 443)
- netsh http add sslcert ipport=0.0.0.0:443 certhash=2c5ba85bcbca412a74fece02878a44b285c63981 appid={646937c0-1042-4e81-a3b6-47d678d68ba9}
Результатом шага 4 является следующая ошибка:
Не удалось добавить сертификат SSL, ошибка 1312
Указанный сеанс входа в систему не существует. Возможно, он уже был прекращен.
Кто-нибудь знает, почему я могу получить эту ошибку?
25 ответов
У меня была такая же ошибка. В первый раз, когда это произошло, как сказал Майкл, мне пришлось переместить сертификат в папку «Сертификаты (локальный компьютер)» -> «Личные» -> «Сертификат». У меня была такая же ошибка, когда я импортировал тот же сертификат на другой компьютер. Причина в том, что я использовал certmgr.msc для импорта сертификата. . Открывшееся окно показывает «Сертификаты — Текущий пользователь». Сертификаты, импортированные с помощью этого окна, приводят к сбою netsh с ошибкой 1312. Обязательно используйте оснастку сертификатов в MMC для импорта сертификатов. Оснастка сертификата из MMC показывает «Сертификаты (локальный компьютер)». Это позволяет выполнить netsh.
63
DiligentKarma
18 Апр 2013 в 22:02
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
Раньше у меня была точно такая же проблема, и я потратил пару дней, пытаясь понять, в чем причина.
Короче говоря: проблема в том, что вы установили сертификат на сервер winrm
, у которого нет ЧАСТНОГО КЛЮЧА.
Я проверял это несколько раз. Вы должны удалить свой сертификат и перестроить его, например, с помощью makecert
, как это прекрасно описано здесь: http://blogs.technet.com/b/jhoward/archive/2005/02/02/365323.aspx
Вы можете легко проверить, есть ли у вашего сертификата закрытый ключ, следующим образом: mmc
— certificates
— local machine
— personal
. Посмотрите на значок сертификата — он ДОЛЖЕН иметь знак ключа на значке.
51
Boeckm
20 Ноя 2014 в 16:26
Я купил официальный сертификат Thawte для защиты веб-службы, размещенной на собственном хосте (консольное приложение) через определенный порт на нашем интернет-сервере. Затем я получил сертификат Thawte и установил его с помощью mmc на нашем интернет-сервере (тогда сертификат можно было просмотреть в разделе «Доверенные корневые центры сертификации» (со значком ключа на изображении, что показывает, что сертификат содержит закрытый ключ, что является обязательным чтобы иметь возможность привязать его к порту кстати).
Следующим шагом было включение <port>
для https:
netsh http add urlacl url=https://+:<port>/ user=everyone
(что не было проблемой)
Следующим шагом было включение порта () для https:
netsh http add sslcert ipport=0.0.0.0:<port> certhash=<thumbprint to certificate> appid={<guid to application>}
Это не удалось с сообщением об ошибке:
Не удалось добавить SSL-сертификат, ошибка: 1312 Указанный сеанс входа не существует. Возможно, он уже был прекращен.
Затем я поискал в Интернете и попробовал различные предложенные обходные пути (без успеха).
Решение для моего случая состояло в том, чтобы добавить certstorename=Root в команду netsh:
netsh http add sslcert ipport=0.0.0.0:<port *1)> certstorename=Root certhash=<thumbprint to certificate *2)> appid={<guid to application *3)>}
Примечания:
Если к команде net netsh применено no certstorename, netsh использует по умолчанию значение MY (что нацелено на хранилище сертификатов: «Personal», где самоподписанные сертификаты хранятся нормально).
Корень нацелен на хранилище сертификатов: «Доверенные корневые центры сертификации».
*1): порт, который вы хотите использовать для подключения
*2): Вы можете извлечь отпечаток сертификата, если откроете сертификат (в системе Windows просто дважды щелкните сертификат в проводнике) — выберите вкладку «Подробности» и нажмите «Отпечаток». Затем отображается «отпечаток пальца», который можно скопировать. Скопируйте отпечаток и удалите все пробелы…
*3): В качестве appid вы можете использовать любой идентификатор в форме {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, так как APPID является только информативным. С помощью команды «netsh http show sslcert» вы можете запросить связанные сертификаты на всей машине, и вы увидите информацию о том, какой appid привязан к какому сертификату (на практике это не очень полезно, кстати). В моем случае я взял (из сгенерированного VS) GUID в свое приложение веб-службы.
30
FredyWenger
18 Янв 2017 в 16:20
Я имел дело с этой проблемой, и я использую собственную службу WCF. Я только что сделал прорыв:
У меня был сертификат в папке персонала для магазина Machine. Срок его действия истек, и мой менеджер выдал новый. Новый не удался для меня с этой ошибкой. Я пробовал много вещей от Google, но в конце концов решил проблему, используя совершенно другое решение.
Я установил оба сертификата — просроченный и новый. Затем я использовал эту команду, чтобы получить их список:
certutil -store My
Я получаю этот вывод (информация является поддельной, а другие сертификаты не указаны):
================ Certificate 1 ================
Serial Number: 6d
Issuer: E=operations@voicetrust.com, 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: E=hgulzar@voicetrust.com, 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: E=operations@voicetrust.com, 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: E=hgulzar@voicetrust.com, 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
Теперь все кажется в порядке, но срок действия сертификата 1 истек, и он работает, если я пытаюсь привязать его к порту, тогда как сертификат 2 завершается с ошибкой 1312.
Ключевым отличием, которое меня озадачило, было свойство Уникальное имя контейнера. Он должен представлять файл физического ключа на жестком диске в %ProgramData%MicrosoftCryptoRSAMachineKeys
Для сертификата 1 файл был, а для сертификата 2 такого файла не было. После поиска я нашел файл с сертификатом 2 в подпапке папки %AppData%MicrosoftCrypto
. Это пользовательские ключи, а не ключи уровня машины. Удивительно, что сертификат импортируется в хранилище компьютеров, но всегда сохраняет ключ контейнера хранилища пользователя.
Я удалил файл 55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239 из папки AppData и выполнил команду восстановления моего сертификата 2 в хранилище:
certutil -repairstore My 2
На этот раз уникальное имя контейнера отражало файл в соответствующей папке в папке «%ProgramData%MicrosoftCrypto», и все заработало.
Надеюсь, это кому-то поможет.
21
Hassan Gulzar
4 Ноя 2013 в 15:20
Я весь день боролся с ошибкой 1312, для меня это исправило импорт сертификата в mmc в виде файла .p12 вместо .crt. Если вы создаете его с помощью OpenSSL, то после создания .crt выполните:
pkcs12 -export -in server.crt -inkey server.key -name “Your Name” -out server.p12
Как описано. Когда вы собираетесь импортировать его в mmc, он будет называться файлом «Обмен личной информацией» (и, по-видимому, файл .pfx также будет работать).
Я новичок в написании серверов и работе с SSL, и я понятия не имею, почему это работает, но я надеюсь, что это поможет.
9
Braiam
4 Июн 2014 в 03:16
Проблема была на шаге 4. Я использовал отпечаток из корневого сертификата для значения в certhash. Чтобы решить эту проблему, мне пришлось вернуться в MMC и обновить папку «Сертификаты (локальный компьютер)» -> «Личные» -> «Сертификат». Затем используйте отпечаток сертификата, который «выдан» корневым центром сертификации.
6
Michael Wilson
26 Окт 2012 в 22:12
В моем случае проблема заключалась в том, что к файлу CER не был прикреплен закрытый ключ.
Я подключил PK, используя эти команды 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
Работает с файлами CER/DER.
6
Jacek
11 Июн 2014 в 15:10
У меня была такая же проблема, и я решил импортировать сертификат с помощью этой команды:
c:> certutil -importPFX certname.pfx
Теперь сертификат появляется с помощью этой команды:
c:> certutil -store my
Перед этой командой сертификат не появляется
5
user55993
26 Окт 2015 в 19:43
Есть несколько способов получить эту ошибку (другие ответы см. Выше).
Другой способ получить эту конкретную ошибку — попытаться привязать сертификат к порту, когда сертификат отсутствует в соответствующем хранилище.
Убедитесь, что сертификат хранится в корневом хранилище localMachine (вы можете использовать certutil или certmgr.exe из командной строки, чтобы правильно сбросить его).
Обновленная грамматика
2
GMLewisII
29 Янв 2015 в 22:01
Если:
- у вас не было IIS на вашем компьютере (скажем, вы работали с собственным WCF), и
- вы сделали запрос сертификата на другом компьютере с помощью диспетчера IIS (потому что вы не поняли, что закрытый ключ исходит из шифров, встроенных в запрос сертификата, а затем выданного
.pb7
)
Тогда:
- просто установите
.pb7
на машину IIS, которую вы использовали для запроса сертификата (локальная машина/личные/сертификаты — с использованием mmc); - экспортировать сертификат с этой машины, включая его закрытый ключ (назначить пароль); и
- установите его с помощью mmc на сервере WCF (локальный компьютер/персональный/сертификаты — с помощью mmc).
Затем netsh
позволит вам привязаться к порту 443. Больше никаких ошибок 1312.
1
Andrew
3 Апр 2015 в 22:33
Просто чтобы бросить еще один ответ на ринг, вот проблема, с которой я столкнулся:
Хотя я импортировал свой сертификат в хранилище сертификатов (Local Computer)...
, я импортировал его в раздел Trusted Root Certification Authorities
. Мне нужно было импортировать его в раздел Personal
, иначе возникала эта ошибка.
1
Jez
24 Фев 2016 в 19:12
Если кто-то еще столкнется с этой проблемой, и ответы здесь не дают четкого ответа, основная основная проблема заключается в том, что закрытый ключ необходимо импортировать. Если вы не пометите сертификат как экспортируемый при импорте, закрытый ключ не будет импортирован, и вы не сможете его привязать. Если вы удалите его и повторно импортируете и пометите как экспортируемый, то он будет работать.
Как указывали другие, это также должен быть локальный машинный магазин.
1
Kendall Bennett
28 Сен 2017 в 00:00
В моем случае у меня отсутствует закрытый ключ сертификата.
1
FabioLux
3 Дек 2018 в 20:12
ЕСЛИ вы импортировали сертификат с помощью .NET, необходимо использовать определенные флаги импорта:
/// <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();
}
Метод ImportCertificate
является частью пакета Woof.Security
, созданного мной.
-
https://github.com/HTD/Woof.Security
-
https://www.nuget.org/packages/Woof.Security/
1
Harry
18 Июл 2019 в 20:44
У меня была точно такая же проблема, хотя в моем файле .pfx был закрытый ключ. Добавление сертификата с помощью консоли MMC прошло успешно, но добавление программно с использованием метода .Net X509Store.Add(X509Certificate2) каждый раз завершалось неудачно с ошибкой 1312. Сертификат даже имел знак ключа на значке.
Через несколько дней, наконец, решил создать новый сертификат с помощью makecert.exe, как это предлагается в сообщениях здесь. После этого все было хорошо. Ключ появился в %ProgramData%MicrosoftCryptoRSAMachineKeys. По какой-то причине мой предыдущий файл pfx не был совместим.
По моему опыту, пока ваш ключ не отображается в %ProgramData%MicrosoftCryptoRSAMachineKeys, привязка с помощью «netsh http add sslcert ….» завершится ошибкой.
0
Vedran
29 Янв 2015 в 11:51
Аргумент certstorename
должен быть строковым значением StoreName из пространства имен .net framework System.Security.Cryptography.X509Certificates
.
0
mbrownnyc
9 Июн 2016 в 17:45
Я работал над этим часами и в основном прочитал то, что @DoomerDGR8 сказал выше, но мое решение было намного проще. я побежал
C:Windowssystem32> certutil -store TRUSTEDPUBLISHER
В нем перечислены несколько сертификатов, которые я установил, затем я запустил repair store для сертификата, который у меня возникла проблема при установке с помощью netsh.
C:Windowssystem32> certutil -repairstore TRUSTEDPUBLISHER 6
Число 6 в конце представляет собой индекс вашего сертификата, найденного в магазине, надеюсь, это поможет
0
Dai Bok
11 Июл 2016 в 19:09
В моем случае при создании сертификата я выбрал имя, отличное от My, для имени моего хранилища сертификатов. Имя по умолчанию — МОЙ. Поэтому, если у вас отличается, добавьте к команде certstorename=предоставленное вами имя магазина.
0
Milad
17 Янв 2017 в 10:28
У меня была такая же ошибка при создании самоподписанного сертификата с OpenSSL (BouncyCastle). Я решил ее с помощью этого поста: Невозможно экспортировать сгенерированный сертификат с закрытым ключом в массив байтов в .net 4.0/4.5
Пришлось добавить:
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;
0
Community
23 Май 2017 в 15:26
Итак, чтобы добавить (пока) исправление/ситуацию.
У меня был код C#, который использовал BouncyCastle для создания самозаверяющих сертификатов.
<packages>
<package id="BouncyCastle" version="1.8.1" targetFramework="net45" />
Итак, мой код создал сертификаты и поместил их в правильные места в Cert-Store.
Используя приведенные здесь подсказки, моя установка On Premise Service Bus 1.1 не удалась… и это привело меня сюда.
В итоге я УДАЛИЛ оба сертификата, созданные моим кодом BouncyCastle (из хранилища сертификатов), и повторно импортировал их (с закрытыми ключами)… и все это сработало. Я импортировал ПЕРВЫМ в
Сертификаты (локальный компьютер)/Личные/Сертификаты
Потом скопировал вставил (в ммс) в любые другие места (магазины) они мне были нужны.
Мое «до» и «после» выглядело точно так же с моих глаз в MMC, НО это решило проблему. Иди разберись.
0
granadaCoder
28 Апр 2017 в 22:37
У меня только что была еще одна ошибка. Я обновил сертификат с истекшим сроком действия для нашей службы WorkFolders из нашего ЦС, используя тот же закрытый ключ. Затем я всегда получал ошибку 1312. Даже если Управление сертификатами показывает, что у меня есть закрытый ключ.
Я смог решить проблему только путем перевыпуска нового сертификата (без опции продления). Тогда это сработало с первой попытки.
Может быть, это поможет кому-то, кто также пробовал вариант обновления.
0
clst
8 Май 2017 в 13:56
Для меня проблема была решена путем обеспечения того, чтобы хэш сертификата, который я использовал в своей командной строке, соответствовал сертификату, установленному на моем сервере:
Netsh http добавить sslcert ipport=0.0.0.0:8081 certhash=1061a577f0cc1c428186000dc84f02a7111ca1b2 appid={GUID}
0
shah
9 Июн 2020 в 18:14
С моей стороны предоставленные файлы были файлом P7B вместе с кучей файлов сертификатов. Застряв, я обратился за помощью к своему коллеге, и он подал мне идею импортировать сертификаты вместе с закрытым ключом через PFX.
Эта статья содержит мне инструкция конвертировать файл P7B в PFX. Подводя итог, вам просто нужно сделать следующее:
- Используйте openssl, чтобы сначала преобразовать файл P7B в PEM.
- Преобразуйте файл PEM в PFX.
Теперь вы можете импортировать файл PFX. Лучше прочитать статью, которую я указал выше, потому что в ней есть важная информация для заметок.
0
d.i.joe
28 Авг 2020 в 18:04
Это мое резюме всех исправлений в этой теме и того, как это сработало для меня:
- Найдите «Windows PowerShell», щелкните правой кнопкой мыши значок и выберите «Запуск от имени администратора».
- Найдите «Wordpad», щелкните правой кнопкой мыши значок и выберите «Запуск от имени администратора». (это сделано для того, чтобы вы могли копировать и вставлять между PowerShell и Wordpad.)
- В PowerShell запустите «netsh HTTP show sslcert».
- Из отображаемой информации скопируйте «Хэш сертификата», «Идентификатор приложения» и «Имя хранилища сертификатов». (Вам понадобится все это через мгновение.)
- (Если вам нужно) найдите файл *.cer или *.crt и экспортируйте его как файл *.pfx.
- В Powershell перейдите в папку вашего файла *.pfx.
- Теперь запустите «certutil -importPFX .pfx».
- Затем запустите «certutil -store my», чтобы отобразить установленные сертификаты.
- Теперь, используя информацию из шага № 4, запустите этот «netsh http add sslcert ipport = 0.0.0.0: 8000 certstorename = certhash = appid =» (мне пришлось поместить их в этом порядке, с моим именем хранилища сертификатов и одинарными кавычками вокруг идентификатор приложения.)
- Убедитесь, что сертификат SSL был добавлен, снова запустив «netsh HTTP show sslcert».
0
Adam
24 Фев 2021 в 01:51
Это может показаться очевидным; тем не менее, я думаю, что это может избавить кого-то от головной боли. Я импортировал файл с расширением .cer в папку «Личные сертификаты» (для учетной записи «Персональный компьютер»). Через некоторое время я понял, что вместо этого мне нужно импортировать файл с расширением *.pfx. Исправил это и вуаля! Проблема решена!
4
Amadeus Sánchez
9 Янв 2017 в 20:13