Клиентские сертификаты Apache для аутентификации

Question

Я хочу предоставить сервис через API с двумя факторами аутентификации с использованием PHP / MySQL. Одним из факторов является простое имя пользователя и пароль. Что касается другого фактора, я пытаюсь использовать взаимный TLS, в котором сертификат клиента сопоставляется с именем пользователя. Я намереваюсь использовать самозаверяющие сертификаты из ЦС, который я установил на компьютере CentOS с Apache, и выдавать клиентские сертификаты клиентам через защищенный канал вместе с закрытыми ключами.

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

https://cweiske.de/tagebuch/ssl-client-certificates.htm

Но, кажется, есть дыра в этой и других статьях с точки зрения объяснения мне чего-то. Я предполагаю, что эта работа заключается в том, что, когда клиент делает запрос POST, наряду с именем пользователя и паролем, также включается сертификат с цифровой подписью, подписанной секретным ключом, выданным пользователю. Затем эта подпись может быть расшифрована открытым ключом, чтобы подтвердить, что владелец личного ключа отправил сообщение. Но эти статьи на самом деле не подтверждают, что это то, что происходит.

Вместо этого они говорят, что Apache подтверждает, что сертификат был подписан CA Cert. Они также объясняют, как использовать PHP для доступа к полям сертификата, таким как SSL_CLIENT_S_DN_Email и SSL_CLIENT_M_SERIAL, и используют их для подтверждения того, что сертификат принадлежит отправителю сообщения. Но мне не ясно, что они не просто используют информацию в публичном сертификате. Таким образом, любой, кто может получить доступ к общедоступному сертификату, может использовать его в качестве одного из факторов аутентификации для аутентификации в сервисе. Если это так, это означает, что на самом деле это не фактор аутентификации.

Я ошибаюсь, если думаю, что именно так и есть - сертификат, включенный в сообщение, включает подпись, подписанную закрытым ключом, выданным пользователю, и что Apache расшифровывает подпись с помощью открытого ключа, а не просто подтверждает сертификат выдан СА?

Answer 1

Настройка Apache для разрешения взаимной аутентификации довольно проста, а документация по http://httpd.apache.org довольно понятна.В основном вам нужны два сертификата: серверный для установки на сервер Apache и затем клиентский для установки в браузер Firefox или клиентское приложение или другое устройство.Сертификат клиента должен быть выдан одним из CA, которые сервер Apache знает для успешной аутентификации.

Этот проект https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication реализует полную конфигурацию взаимной аутентификации SSL / TLS Apache

Answer 2

Есть две точки.

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

Что касается представленного сертификата, то никто не может представить какой-либо сертификат, потому что обмен TLS будет предписывать клиенту что-то делать с соответствующим закрытым ключом, поэтому сервер сможет проверить, действительно ли у клиента имеется соответствующий закрытый ключ для публичный сертификат предъявлен.

Это хорошо объяснено по адресу: https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake, которое я суммирую здесь:

1. другие шаги, не относящиеся к нашему обсуждению
2. Клиент отвечает сообщением сертификата, содержащим сертификат клиента.
3. ClientKeyExchange шаг , который мы можем пропустить в нашем обсуждении
4. Клиент отправляет сообщение CertificateVerify, которое является подписью предыдущих сообщений рукопожатия, используя закрытый ключ сертификата клиента. Эту подпись можно проверить с помощью открытого ключа сертификата клиента. Это позволяет серверу знать, что клиент имеет доступ к закрытому ключу сертификата и, следовательно, владеет сертификатом. Итак, здесь вы видите, что клиент должен что-то делать со своим закрытым ключом, и сервер сможет проверить, что .

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