Взаимная аутентификация - настройка, поток, проверка

Я реализую взаимную аутентификацию между одним клиентским приложением (CLIENT) и моим приложением Spring Boot 2 (SERVER). Я понимаю, что шаги должны быть следующими:

  • Сервер создает хранилище ключей и хранилище доверенных сертификатов. Хранилище ключей, используемое для хранения сертификатов сервера и закрытого ключа. Склад доверенных сертификатов, используемый для хранения других учетных данных (сертификатов от центра сертификации (ЦС) или сертификатов доверенных клиентов).

  • Для сервера создается CSR, который затем передается в CA. CA генерирует подписанный сертификат из CSR. Он установлен в хранилище ключей сервера.

  • Клиент (у которого есть собственное хранилище ключей и хранилище доверенных сертификатов) предоставляет свой открытый ключ серверу. Затем он устанавливается в хранилище доверенных сертификатов сервера.

Когда от клиента к серверу отправляется https-запрос:

  1. Клиент делает запрос на доступ к защищенному ресурсу.
  2. Сервер отвечает своим публичным сертификатом.
  3. Клиент проверяет этот сертификат (смотрит в хранилище доверенных сертификатов и проверяет, подписан ли он доверенным центром сертификации).
  4. Клиент представляет свой публичный сертификат серверу.
  5. Затем сервер проверяет сертификат по своему хранилищу доверенных сертификатов.
  6. Предполагая, что проверка прошла успешно, клиенту предоставлен доступ к защищенному ресурсу.

Итак, у меня есть несколько вещей, которые меня немного смущают ...

  • Правильны ли в общих чертах описанные выше шаги?
  • Как сервер проверяет сертификат клиента? (Я думаю, что он просматривает хранилище доверенных сертификатов для этого сертификата, но не уверен, что на самом деле происходит после этого).
  • Я видел примеры установки сертификата CA в хранилище доверенных сертификатов сервера вместо фактического общедоступного сертификата клиента ~ есть ли вариант использования, когда это следует или не следует делать? Для моего варианта использования мне был предоставлен подписанный сертификат от клиента (третьей стороны). ЦС, подписавший этот сертификат, отличается от ЦС, подписавшего сертификат сервера.
  • Действительно ли этот процесс аутентифицирует клиента, то есть этот клиент теперь может иметь доступ к защищенным ресурсам сервера, но другой клиент, который может представить другой сертификат, не будет иметь доступа? (например, более безопасный метод предоставления имени пользователя и пароля)
  • При чем тут проверка общего имени (CN)? Я отмечаю, что в Spring Boot X.509 вы можете получить имя пользователя из CN, а затем использовать его для поиска соответствующих сведений о пользователе в службе сведений о пользователях.
  • Если сертификат клиента по каким-либо причинам скомпрометирован, можно ли просто удалить его из хранилища доверенных сертификатов сервера?
  • Есть ли преимущество в моем сценарии использования доверенного центра сертификации, например. verisign для создания клиентского сертификата вместо самоподписанного? т.е. сертификат передается мне напрямую от доверенной третьей стороны, а затем устанавливается.

person Hurricane    schedule 14.10.2018    source источник


Ответы (1)


Что касается вашего первого вопроса, да, изложенные вами шаги верны! Вот общий mutualSSL поток с графическим обзором: (источник)

  1. Клиент запрашивает доступ к защищенному ресурсу.
  2. Сервер представляет свой сертификат клиенту.
  3. Клиент проверяет сертификат сервера.
  4. В случае успеха клиент отправляет свой сертификат на сервер.
  5. Сервер проверяет учетные данные клиента.
  6. В случае успеха сервер предоставляет доступ к защищенному ресурсу, запрошенному клиентом.

взаимный поток SSL

Ваш второй вопрос (Как сервер проверяет сертификат клиента?): Сервер проверяет сертификат клиента с помощью подписи. Подпись обычно представляет собой хеш-значение, построенное на основе полного сертификата. Хеш-значение подписано закрытым ключом соответствующего CA (центра сертификации). Сервер проверяет подпись сертификата клиента с помощью открытого сертификата CA.

Ваш третий вопрос (Склад доверенных сертификатов серверов, содержащий открытый ключ / сертификат клиента или соответствующий сертификат ЦС?): если вы используете, например, самозаверяющие сертификаты, вам, вероятно, придется импортировать открытый ключ / сертификат клиента непосредственно в хранилище доверенных сертификатов серверов. Если ваш клиент использует CA подписанный сертификат, для вашего сервера целесообразно хранить только CA открытый ключ / сертификат, поскольку он используется для проверки сертификата клиента.

Ваш четвертый вопрос (Действительно ли этот процесс аутентифицирует клиента): Да! Как видно из ответа на второй вопрос, сертификат проверяется проверкой подписи. Подпись - это хэш над полным сертификатом. Стандартный X.509 содержит информацию для идентификации темы. Проверяя подпись, субъект аутентифицируется. Стандартный X.509 сертификат, помимо прочего, содержит, например, эта информация: Имя субъекта, Информация об открытом ключе субъекта, Алгоритм открытого ключа, Уникальный идентификатор эмитента (необязательно), ...

Ваш пятый вопрос (Где происходит проверка CN?): проверка CN (общее имя) выполняется во время проверки сертификата. CN определяет действительное имя хоста для текущего сертификата. Он ограничен одной записью. В качестве расширения было введено SAN (альтернативное имя субъекта). Сертификат может содержать более одного SAN. Запись CNSAN) является частью сертификата и проверяется с помощью проверки подписи сертификата.

Ваш шестой вопрос (Если сертификат клиента скомпрометирован по каким-либо причинам, можно ли это решить, просто удалив его из хранилища доверенных сертификатов сервера?): Поэтому CAs используют так называемый _ 15_. Если вы используете, например, самозаверяющие сертификаты, также можно просто удалить скомпрометированную запись сертификата из хранилища доверенных сертификатов серверов.

Ваш седьмой вопрос (Есть ли преимущество в моем сценарии использования доверенного центра сертификации, например, verisign для создания клиентского сертификата по сравнению с самозаверяющим сертификатом?): существует несколько преимуществ использования CA подписанного сертификата вместо самоподписанного.

  • Сертификатом и, в конечном итоге, отзывом управляет CA
  • Сертификат действителен для каждой доверяющей стороны общественности CA, например Verisign
  • Большинство общедоступных CAs предлагают стандартизированные способы создания сертификата.
person git-flo    schedule 21.10.2018
comment
@ git-flow Спасибо за ваш ответ, я очень признателен. Что касается проверки CA (вопрос 2), CA предположительно должен быть специфичным для этого сервера. то есть клиент поднимает csr, а сервер подписывает его своим CA? На вопрос 2, как работает проверка, когда ЦС не используется, т.е. сертификат клиента устанавливается непосредственно в хранилище доверенных сертификатов сервера? - person Hurricane; 30.10.2018
comment
CA обычно принимается сервером и клиентом. Если у клиента нет сертификата, подписанного CA, сервер должен иметь открытый сертификат клиента в своем хранилище доверенных сертификатов. Таким образом, сервер может проверять запросы клиентов. - person git-flo; 31.10.2018