Использовать самозаверяющий сертификат без установки в хранилище сертификатов

У меня есть файл самоподписанного сертификата (.cer) от третьей стороны. Я хотел бы использовать этот сертификат в коде для подключения к их веб-службе (через HTTPS), не устанавливая его в моем хранилище сертификатов в Windows. В частности, это сделано для того, чтобы всем остальным разработчикам в команде не пришлось устанавливать этот сертификат локально, чтобы подключение работало для них.

Есть ли способ сделать это в коде? Он может использовать либо старомодный клиентский код веб-службы (с помощью wsdl.exe или VS Add Web Reference), либо клиентский код WCF (с использованием svcutil.exe или VS Add Service Reference) — мы не определились, по какому пути мы хотим идти. пока что.

Я пытался:

proxy.ClientCertificates.Add(X509Certificate.CreateFromCertFile(@"d:\temp\mycert.cer"));

со старым кодом веб-сервиса, не повезло - он все равно не работает с Could not establish trust relationship for the SSL/TLS secure channel., пока я не установлю сертификат в хранилище сертификатов. То же самое для:

<identity>
  <certificate encodedValue="the base64 encoded contents of the file" />
</identity>

в конечной точке в app.config, используя технологию клиента WCF.

Спасибо


.net certificate wcf-client web-services self-signed
person Joe Enos    schedule 06.06.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Причина, по которой вам нужен сертификат, — HTTPS. Веб-служба защищена транспортной безопасностью (HTTPS) с сертификатом, которому ваша система не доверяет. Чтобы доверять сертификату, общий подход заключается в установке сертификата в хранилище сертификатов. Это все не функция .NET - это функция Windows, не входящая в сферу ответственности .NET.

Чтобы доверять произвольному SSL-сертификату, .NET предлагает метод обратного вызова, в котором вы можете сделать свой собственный код, используемый для проверки сертификата: ServicePointManager.ServerCertificateValidationCallback. Если вы просто вернете true из обратного вызова, вы будете доверять каждому сертификату, но это только для разработки и тестирования! После развертывания в рабочей среде приложение должно использовать сертификат из хранилища сертификатов или использовать специальную проверку, определенную в обратном вызове (не рекомендуется).

person Ladislav Mrnka    schedule 07.06.2011
comment
Спасибо. В итоге я пошел по пути принятия всех сертификатов в dev. К счастью, в производственной среде сертификат не является самоподписанным, поэтому у нас не будет этой проблемы. Я надеялся избежать этого маршрута, просто чувствую себя неправильно, даже если это просто разработка, но я думаю, нам придется с этим смириться. - person Joe Enos; 11.06.2011

arrow_upward
1
arrow_downward

.NET не может/не будет обрабатывать комбинацию сертификат+ключ (которая вам нужна в данном случае) из файла с открытым текстом. Я не нашел способа его построить; он совершенно не будет читать открытый текстовый ключ для сертификата.

Однако он будет работать с контейнером P12/PFX, даже если у контейнера нет пароля. Вы даже можете сохранить это как закодированную строку и воссоздать ее с помощью этого конструктора: http://msdn.microsoft.com/en-us/library/ms148418.aspx

person Joe    schedule 06.06.2011
comment
Я могу ошибаться, но поскольку файл .cer не содержит закрытого ключа, я не думаю, что смогу создать контейнер PFX. Можно ли сделать это без закрытого ключа? - person Joe Enos; 07.06.2011
comment
Проверьте - иногда вы будете видеть и сертификат, и закрытый ключ в одном файле, как два отдельных раздела. .NET не может с этим справиться, но он подходит для таких вещей, как OpenSSL. Но без закрытого ключа вы не можете использовать его в качестве клиентского сертификата. - person Joe; 07.06.2011