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

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

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

  • Какие (расширенные) значения использования ключа требуются для сертификата сервера? В моем тестовом сертификате я получил Digital Signature, Non Repudiation, Key Encipherment и продлен TLS Web Server Authentication - Я что-то пропустил? Все ли это требуется?
  • Тот же вопрос о клиентских сертификатах: какие ключевые ключи требуются? Мои тестовые сертификаты имеют Digital Signature, Key Encipherment, Data Encipherment и продлен TLS Web Client Authentication - Я что-то пропустил? Все ли это требуется?
  • Существуют ли другие специальные функции, которые должен иметь сертификат клиента?
  • Сертификат сервера должен иметь свое имя в списке SAN в качестве записи DNS (или IP, если доступ осуществляется по IP-адресу, верно?). Но как насчет поля CN субъекта с его отличительным именем? должна ли она иметь какую-то конкретную форму? Должно быть пустым? Можно непубличные адреса, как, например, mytestenv.mycompany.lan использоваться в качестве SAN? В настоящее время в моем сертификате тестового сервера у меня есть только набор Subject CN и нет записи SAN DNS, и я считаю, что мне нужно добавить его, я прав?
  • Существуют ли какие-либо действия (кроме добавления сертификата CA в доверенные CA в браузере или магазине Windows), которые необходимо предпринять, чтобы браузеры не отображали предупреждение о безопасности на всю страницу о незащищенности сайта? Я думаю, что могу жить без "зеленой блокировки" или с некоторым предупреждением в адресной строке или чем-то еще, но, например, Chrome отображает полную ошибку безопасности страницы и не показывает веб-страницу, пока я не настрою исключение безопасности для сервера. Как я могу предотвратить это? Может ли пропущенный SAN быть причиной? IE и Firefox отображают страницу.
  • Влияет ли что-либо, например, DV/OV/EV, прозрачность сертификатов, "HTTPS апокалипсис", поступающее для браузеров, или что-то еще, на мои (и, возможно, клиентские) настройки каким-либо образом? Нужно ли мне позаботиться об этом?

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

Источник

1 ответ

Решение

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

Для TLS вам потребуется шифрование ключей и цифровая подпись, а также расширенное использование соответствующей аутентификации веб-сервера / клиента TLS. Non Repudation не используется. Соглашение о ключе теоретически может быть использовано для ECDH, в отличие от ECDHE. См. /questions/203046/fajlovaya-sistema-dlya-vneshnego-diska-kotoryij-budet-podklyuchatsya-tolko-k-lin/203078#203078

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

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

Смотрите: блог Скотта Хельме

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

От: https://groups.google.com/a/chromium.org/forum/

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

САН с местными именами

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

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

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

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

CAA записи. Государственные центры сертификации должны проверять это при выдаче сертификатов. Смотрите https://scotthelme.co.uk/certificate-authority-authorization/

Дальнейшие ссылки:

Источник
Другие вопросы по тегам