2016-10-14 8 views
0

У меня есть служба ASP.NET MVC3, работающая в IIS 7.5 с .NET Framework 4.5, где я хочу обеспечить доступ к одному из подпапок с помощью сертификат клиента. Для этого подпути я обработал контроллер с метят специально сформированного атрибута, который будет доступ к сертификату запроса клиентаНе удается аутентифицировать вызов службы ASP.NET MVC3 с самоподписанным сертификатом клиента

public class CheckCertAttribute : ActionFilterAttribute 
{ 
    public override void OnActionExecuting(
     ActionExecutingContext filterContext) 
    { 
     filterContext.HttpContext.Response.Headers.Add(
      "CheckCertAttribute", "entered"); 
     var cert = filterContext.HttpContext.Request.ClientCertificate; 
     // check the cert here, optionally return HTTP 403 
    } 
} 

Первоначально OnActionExecuting() настоящее время вызывается, но Certificate является недействительным. Оказывается, мне нужно включить SslNegotiateCert в web.config:

<location path="PathOfInterest"> 
<system.webServer> 
    <security> 
    <access sslFlags="SslNegotiateCert"/> 
    </security> 
</system.webServer> 
</location> 

После того, как я делаю это клиент всегда получает HTTP 403 и атрибут больше не вызывается.

Клиентский сертификат самоподписан и экспортирован как .pfx (с закрытым ключом), поэтому я предполагаю, что проблема заключается в том, что, когда он прибывает на сервер, сервер ему не нравится и отказывается принять его и передать через. Сторона клиента использует HttpWebRequest:

var cert = new X509Certificate2(pathToPfx, password); 
var request = (HttpWebRequest)WebRequest.Create("https://my.company.com/PathOfInterest"); 
request.ClientCertificates.Add(cert); 
request.GetResponse(); 

Я уже использовал этот подход раньше, и она работала. Первый случай заключался в том, что клиентский сертификат не был самоподписанным, но был подписан промежуточным сертификатом, который, в свою очередь, был подписан некоторым доверенным корневым полномочным органом - в этом случае моя служба, настроенная очень точно, получит ее просто отлично. Второй случай заключался в использовании самозаверяющего клиентского сертификата для вызова Azure Management Service, но в этом случае я понятия не имею, как настроена серверная сторона.

Поэтому я пришел к выводу, что это самоподписанный характер сертификата, который делает его «неработоспособным». У меня есть что-то дополнительное - возможно, добавьте что-то в файл web.config или добавьте сертификат в хранилище сертификатов на стороне сервера. Я просто понятия не имею, что это должно быть.

Как настроить эту настройку?

ответ

0

IIS пытается «согласовать» взаимно доверенное соединение с клиентом, и поскольку сертификат клиента самоподписан, он отказывается доверять ему.

Ваши варианты:

  1. Использовать сертификат, выданный известным центром сертификации. Это будет работать, но вам придется переиздавать сертификат каждый год или около того.
  2. Запустите свою собственную инфраструктуру ЦС, добавьте свой корневой сертификат ЦС в хранилище сертификатов «доверенный корневой каталог» сервисных машин и выдайте сертификат, подписанный с этим корнем (вероятно, через промежуточные сертификаты).
  3. Добавьте самозаверяющий сертификат в «доверенный корень» сервисных машин. This may induce subtle yet serious security risks. Я лично против этого варианта, потому что он чувствует себя очень небезопасным.
  4. Переключитесь на другую схему аутентификации, которая не использует клиентские сертификаты.

 Смежные вопросы

  • Нет связанных вопросов^_^