Взаимная аутентификация - настройка, поток, проверка
Я реализую взаимную аутентификацию между одним клиентским приложением (CLIENT) и моим приложением Spring Boot 2 (SERVER). Я понимаю, что шаги должны быть следующими:
Сервер генерирует хранилище ключей и магазин доверия. хранилище ключей используется для хранения сертификатов сервера и закрытого ключа. магазин доверия используется для хранения других учетных данных (сертификатов от центра сертификации (CA) или сертификатов доверенных клиентов).
Для сервера создается CSR, который затем передается в CA. CA генерирует подписанный сертификат из CSR. Он установлен в хранилище ключей сервера.
- Клиент (у которого есть собственное хранилище ключей и хранилище доверенных сертификатов) предоставляет свой открытый ключ серверу. Затем он устанавливается в хранилище доверенных сертификатов сервера.
Когда от клиента к серверу отправляется https-запрос:
- Клиент делает запрос на доступ к защищенному ресурсу.
- Сервер отвечает своим публичным сертификатом.
- Клиент проверяет этот сертификат (смотрит в хранилище доверенных сертификатов и проверяет, подписан ли он доверенным центром сертификации).
- Клиент представляет свой публичный сертификат серверу.
- Затем сервер проверяет сертификат по своему хранилищу доверенных сертификатов.
- Предполагая, что проверка прошла успешно, клиенту предоставлен доступ к защищенному ресурсу.
Так что у меня есть несколько вещей, которые меня немного смущают ...
- Правильны ли в общих чертах описанные выше шаги?
- Как сервер проверяет сертификат клиента? (Я думаю, что он просматривает хранилище доверенных сертификатов для этого сертификата, но не уверен, что на самом деле происходит после этого).
- Я видел примеры установки сертификата CA в хранилище доверенных сертификатов сервера вместо фактического общедоступного сертификата клиента ~ есть ли вариант использования, когда это следует или не следует делать? Для моего варианта использования мне был предоставлен подписанный сертификат от клиента (третьей стороны). ЦС, подписавший этот сертификат, отличается от ЦС, подписавшего сертификат сервера.
- Действительно ли этот процесс аутентифицирует клиента, то есть этот клиент теперь может иметь доступ к защищенным ресурсам сервера, но другой клиент, который может представить другой сертификат, не будет иметь доступа? (например, более безопасный метод предоставления имени пользователя и пароля)
- При чем тут проверка общего имени (CN)? Я отмечаю, что в Spring Boot X.509 вы можете получить имя пользователя из CN, а затем использовать его для поиска соответствующих сведений о пользователе в службе сведений о пользователях.
- Если сертификат клиента по каким-либо причинам скомпрометирован, можно ли просто удалить его из хранилища доверенных сертификатов сервера?
- Есть ли преимущество в моем сценарии использования доверенного центра сертификации, например. verisign для создания клиентского сертификата вместо самоподписанного? т.е. сертификат передается мне напрямую от доверенной третьей стороны, а затем устанавливается.
Ответы 1
Что касается вашего вопроса первый, да, ваши изложенные шаги верны! Вот общий поток mutualSSL с графическим обзором: (источник)
- A client requests access to a protected resource.
- The server presents its certificate to the client.
- The client verifies the server’s certificate.
- If successful, the client sends its certificate to the server.
- The server verifies the client’s credentials.
- If successful, the server grants access to the protected resource requested by the client.
Ваш вопрос второй (Как сервер проверяет сертификат клиента?):
Сервер проверяет сертификат клиента с помощью подписи. Подпись обычно представляет собой хэш-значение, построенное на основе полного сертификата. Хэш-значение подписано закрытым ключом соответствующего CA (центра сертификации). Сервер проверяет подпись сертификата клиента с помощью открытого сертификата CA.
Ваш вопрос в третьих (Серверы доверенного хранилища, содержащие открытый ключ / сертификат клиента или соответствующий сертификат CA?):
Если вы используете, например, самозаверяющие сертификаты, вам, вероятно, придется импортировать открытый ключ / сертификат клиента непосредственно в хранилище доверенных сертификатов сервера. Если ваш клиент использует подписанный сертификат CA, для вашего сервера целесообразно хранить только открытый ключ / сертификат CA, поскольку он используется для проверки сертификата клиента.
Ваш вопрос четвертый (Действительно ли этот процесс аутентифицирует клиента?): Да! Как видно из ответа на второй вопрос, сертификат проверяется проверкой подписи. Подпись - это хэш над полным сертификатом. Стандартный X.509 содержит информацию для идентификации субъекта. Проверяя подпись, субъект аутентифицируется. Стандартный сертификат X.509, помимо прочего, содержит, например, эта информация:
Имя субъекта, информация об открытом ключе субъекта, алгоритм открытого ключа, уникальный идентификатор эмитента (необязательно), ...
Ваш вопрос пятый (Куда идет проверка CN?): Проверка CN (общее имя) выполняется во время проверки сертификата. CN определяет действительное имя хоста для текущего сертификата. Он ограничен одной записью. В качестве расширения был представлен SAN (альтернативное имя субъекта). Сертификат может содержать более одного SAN. Запись CN (и SAN) является частью сертификата и проверяется с помощью проверки подписи сертификата.
Ваш вопрос шестой (Если сертификат клиента по каким-либо причинам скомпрометирован, можно ли просто удалить его из хранилища доверенных сертификатов сервера?): Следовательно, CA используют так называемый revocation lists. Если вы используете, например, самозаверяющие сертификаты, также можно просто удалить скомпрометированную запись сертификата из хранилища доверенных сертификатов серверов.
Ваш вопрос седьмой (Есть ли преимущество в моем сценарии использования доверенного центра сертификации, например. verisign для создания клиентского сертификата вместо самоподписанного?): Существует несколько преимуществ использования подписанного сертификата CA вместо самозаверяющего.
- Сертификатом и, в конечном итоге, отзывом управляет
CA. - Сертификат действителен для каждой полагающейся стороны общедоступного
CA, например Verisign - Большинство общедоступных
CAпредлагают стандартизированные способы создания сертификата.
CA обычно принимается сервером и клиентом. Если у клиента нет сертификата, подписанного CA, сервер должен иметь открытый сертификат клиента в своем хранилище доверенных сертификатов. Таким образом, сервер может проверять запросы клиентов.
@ git-flow Спасибо за ваш ответ, я очень признателен. Что касается проверки CA (вопрос 2), CA предположительно должен быть специфичным для этого сервера. то есть клиент поднимает csr, а сервер подписывает его своим CA? На вопрос 2, как работает проверка, когда ЦС не используется, т.е. сертификат клиента устанавливается непосредственно в хранилище доверенных сертификатов сервера?