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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

• Сертификатом и, в конечном итоге, отзывом управляет CA
• Сертификат действителен для каждой проверяющей стороны общественности CA, например, Verisign
• MostCA s предлагают стандартизированные способы создания сертификата