Работа с клиентскими сертификатами для сайта ASP.NET MVC на IIS 6 - PullRequest
4 голосов
/ 23 сентября 2008

Желая реализовать аутентификацию по сертификатам клиента У меня возникли некоторые проблемы.

Первые факты

Весь сайт использует SSL. Я использую IIS 6 (в Windows Server 2003) и настроил сайт для принятия клиентских сертификатов, не требуя их. Однако большинство браузеров реализованы таким образом, что они запрашивают сертификат у пользователя только тогда, когда это строго необходимо. Из-за этого модель аутентификации не очень полезна.

Мои предложения

Моей первой идеей было установить свойство HttpResponse.Status, но для этого нужно, чтобы символы перед первым пробелом были целыми числами. Полезный статус для получения браузером для отправки сертификата клиента - 403.7 Client certificate required, поэтому это не будет работать (если вы не можете перезаписать его).

Я также подумал, что я просто настрою IIS для запроса клиентских сертификатов для определенных путей, но это, конечно, работает только с физическими файлами, а не с маршрутизацией.

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

Разъяснения

Я проверил реакцию браузера как Internet Explorer, Firefox и Chrome (я использую Chrome в качестве основного браузера и Firefox в качестве дополнительного). Ни один из браузеров не запрашивает сертификат клиента, если я - в IIS - не настроил его как требуется.

Код статуса HTTP 403.7, насколько я понимаю, разрешен, поскольку RFC 2616 определяет код состояния только как первые три цифры. Поскольку IIS 6 возвращает 403.7, когда требуется сертификат клиента, я подумал, что отправка его приведет к тому, что IIS перейдет в специальный режим, который вызовет требование.

Полагаю, сейчас проблема в том, как настроить IIS для запроса сертификата по виртуальному пути, а не по физическому.

1 Ответ

3 голосов
/ 23 сентября 2008

Нет разницы в сообщении CertificateRequest, отправляемом сервером, когда сертификат просто запрашивается, а не требуется. Сервер делает один и тот же запрос в обоих случаях и просто завершает рукопожатие, когда клиент не может предоставить требуемый сертификат. Таким образом, если ваш браузер игнорирует «запросы», он также должен игнорировать «требования».

Проверьте следующее:

  • Ваш браузер настроен на игнорирование все запросы на сертификат, никогда отправить один?
  • Ваш браузер настроен на использование выданный сертификат без запроса Пользователь? (Другими словами, откуда вы знаете, что браузер не отправляет сертификат?)
  • Ваш сервер действительно запрашивает сертификат

Я тестирую этот последний случай с помощью инструмента OpenSSL (также доступного в Cygwin ):

openssl s_client -connect server.y.com:443 -msg

После того, как сервер отправит свое сообщение Certificate, он вставит метод CertificateRequest, который отсутствует, если он не запрашивает аутентификацию клиента. Вывод s_client выглядит так:

<<< TLS 1.0 Handshake [length 0008], CertificateRequest
    0d 00 00 04 01 01 00 00

Я не уверен, как это работает, если сервер использует аутентификацию клиента только по определенным путям, потому что первоначальное рукопожатие SSL завершено до того, как клиент передаст HTTP-запрос. В этот момент было бы разумно, чтобы сервер запросил новое рукопожатие, но я никогда не проверял, какие серверы поддерживают это.

Вы можете подделать HTTP-запрос вручную через s_client, введя:

GET /your/path/here HTTP/1.1[Enter]
Host: server.y.com:443[Enter]
[Enter]

Если вы вообще никогда не видите сообщение CertificateRequest, ваш сервер настроен неправильно.

Указание ограничений безопасности на основе структуры каталогов является довольно распространенным явлением и может фактически упростить администрирование безопасности. Не расстраивайтесь, если это поможет вам.

403.7 не является кодом статуса HTTP. Это какая-то Microsoft, которая "обнимает, расширяет и тушит" уловку? В любом случае, это не похоже на правильное направление, поскольку это проблема транспортного уровня, а не проблемы прикладного уровня.

...