Назад | Перейти на главную страницу

Взаимная SSL-аутентификация и требования к сертификатам

Для наших внутренних тестов мне нужно настроить взаимную проверку подлинности SSL между нашим сервером IIS (на нем размещены два приложения: веб-интерфейс ASP.NET и веб-сервис) и клиентами (доступ к серверу двумя возможными способами: веб-интерфейс с браузером и веб-сервис с клиентом, созданным с помощью WinForms). Когда тесты будут завершены и результаты оценены, мне нужно будет дать несколько указаний нашему клиенту, как установить и настроить его в своей среде - закрытой корпоративной среде, доступной по непубличным URL-адресам через VPN.

Я хорошо знаком с PKI, ключами и сертификатами в целом, просто у меня нет большого опыта работы с PKI в контексте HTTPS. С помощью некоторых доступных инструментов, в основном XCA, мне удалось создать свой корневой сертификат CA, сертификат сервера и несколько клиентских сертификатов; Я установил их в IIS и в клиентских магазинах, и все работает нормально, но есть некоторые проблемы и вопросы:

Если возможно, меня будут интересовать как общие замечания, так и требования конкретных серверов (особенно IIS) и браузеров (в инфраструктуре заказчика это будут в основном IE 11+ и Edge).

Использование ключа

Для TLS вам потребуется шифрование ключей и цифровая подпись, а также соответствующее расширенное использование TLS-аутентификации веб-сервера / клиента. Non Repudation не используется. Ключевое соглашение теоретически может использоваться для ECDH, а не для ECDHE. Видеть https://security.stackexchange.com/a/24107

Прозрачность сертификата.

Google продвигает это своим значительным влиянием. Одна важная вещь, которую следует учитывать при отправке сертификатов в журналы прозрачности, заключается в том, что они фактически являются публикацией доменных имен (или подстановочных знаков). Я заметил запросы к веб-серверу сразу после получения сертификата letsencrypt, и теоретически это может быть даже до фактической установки вашего ssl-сертификата, потому что журнал прозрачности имеет предварительную публикацию.

Видеть: Блог Скотта Хельма

Апрельское обновление Chrome:

Из: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/wHILiYf31DE

С января 2015 года Chrome требует, чтобы сертификаты расширенной проверки (EV) были совместимы с CT, чтобы получить статус EV. В апреле 2018 года это требование будет распространено на все недавно выпущенные общедоступные доверенные сертификаты - DV, OV и EV - и сертификаты, не соответствующие этой политике, не будут признаваться надежными при оценке Chrome. Сертификаты, выпущенные из локально доверенных или корпоративных центров сертификации, которые добавляются пользователями или администраторами, не подпадают под это требование.

SAN с местными названиями

Насколько мне известно, проблем нет. Хотя .local - особенно неприятный TLD, потому что он используется с многоадресным DNS.

Другие требования

Для любой зрелой системы необходимы серверы CRL и OCSP. Некоторые подпроцессы могут быть даже более требовательными, чем сам браузер. Возьмем, к примеру, плагин Java в IE11. Если веб-приложение или апплет имеет недоступный сервер CRL или OCSP в иерархии, фрейм браузера может оставаться полностью пустым в течение нескольких минут. Также, если веб-сервер Apache использует сшивание OCSP, тогда серверу OCSP лучше отвечать, когда сам веб-сервер вызывает, иначе, к сожалению, с Apache все клиенты будут отображать ошибки, пока сервер снова не сшивает ответы.

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

Записи CAA. Общедоступные центры сертификации должны проверять это при выдаче сертификатов. Видеть https://scotthelme.co.uk/certificate-authority-authorization/

Дополнительные ссылки: