Я использую apache2 (2.2.3) для обслуживания сайта, где я хотел бы, чтобы клиенты проходили аутентификацию с помощью сертификатов. Поскольку мне нужно только проверить, что пользователь, представляющий конкретный сертификат, является тем же пользователем, который представлял этот сертификат в прошлом, центр сертификации, подписывающий сертификат, не имеет значения. Кажется, однако, что использование SSLVerifyClient requirerequire SSLCACertificateFile ...(или SSLCACertificatePath ...), и тогда apache будет принимать только сертификаты, подписанные CA в этом файле / пути. Есть ли способ заставить apache принять любой клиентский сертификат, независимо от выдающего / подписывающего CA? (т.е. убедитесь, что у клиента есть соответствующий закрытый ключ к представленному открытому ключу, но не пытайтесь проверить выдающий / подписывающий CA)
9
mod_sslбыл разработан для аутентификации пользователей на основе отношений подписи сертификатов; если вы по какой-то причине предпочитаете не обращать на это внимания, вам необходимо реализовать аутентификацию сертификата в своем собственном коде, который также обрабатывает сопоставление сертификата с пользователем.mod_sslработать на уровне приложений, но, поскольку там есть все механизмы, я надеялся, что она позаботится о некоторых делах для меня.optional_no_caявляется то, что он может быть лучше для пользовательского интерфейса, так как вы можете отобразить сообщение об ошибке HTTP, если что-то не так с сертификатом (иначе вы не могли бы, так как плохой клиентский сертификат прервал бы соединение до уровня HTTP ). Это также полезно, если вы хотите попробовать альтернативные способы проверки сертификата (например, WebID ). Вы правы, что хотите что-то сделать для проверки, и это действительно сработает только тогда, когда запрос обрабатывается кодом (например, в PHP / CGI / Java), а не столько с файлами.Ответы:
Как вы обнаружили, вы можете отключить проверку сертификата на уровне рукопожатия SSL / TLS в Apache Httpd с помощью
SSLVerifyCLient optional_no_ca.Вторая проблема, с которой вы столкнетесь, - заставить клиента отправить сертификат. Поскольку ваш сертификат не предназначен для использования в рамках PKI, он может быть самоподписанным и иметь разных эмитентов.
При запросе сертификата клиента сервер отправляет клиенту
CertificateRequestсообщение TLS во время передачи запроса. Это сообщение содержитcertificate_authoritiesсписок:Браузеры используют это для выбора клиентского сертификата для отправки (если есть).
(Обратите внимание, что часть о пустом списке есть только в спецификации, начиная с TLS 1.1 и далее. В SSL 3.0 и TLS 1.0 об этом ничего не говорится, и на практике это также будет работать.)
Вы получаете два варианта для этого.
Если клиентские сертификаты, которые вы ожидаете, будут самозаверяющими, все они будут иметь разных эмитентов. Поскольку вы не будете знать, чего ожидать, серверу нужно будет отправить пустой список. Чтобы сделать это, используйте
SSLCADNRequestFileдирективу и укажите ее в файле, который содержит только пустую строку (если я хорошо помню, он не работает с полностью пустым файлом).Второй (менее чистый) вариант. Согласовать DN эмитента, общий для всех ожидаемых клиентских сертификатов, независимо от того, были ли они действительно выданы этим сертификатом CA (или даже существует этот CA). Поступая так, вы бы значительно нарушили модель PKI (подробнее).
Если вы согласны с DN эмитента, например
CN=Dummy CA(например). Любой может создать самозаверяющий сертификат, используя вCN=Dummy CAкачестве DN субъекта (и DN эмитента), возможно, с разными ключами. Хотя вSSLCADNRequestFileдирективе предполагается, что для создания списка будут настроены сертификаты, они вообще не используются для проверки сертификата клиента, это просто сложный (но естественный в контексте других директив) способ настройкиcertificate_authoritiesсписка. Если вы, как служба, поместите самоподписанный сертификат с этими именамиSSLCADNRequestFile, это приведет кCertificateRequestиспользованию сообщения TLSCN=Dummy CAвcertificate_authoritiesсписке (на данном этапе это просто имена, а не сертификаты). После этого клиент сможет получить свой собственный сертификат с DN эмитента.CN=Dummy CAнезависимо от того, может ли его подпись быть проверена этим сертификатом (теми же ключами) или нет, так как в любом случае проверка подписи не вовлечена в эти шаги.При этом, помните, что с
SSLVerifyCLient optional_no_ca, никакая реальная проверка сертификата не сделана (я полагаю, что вы могли бы проверитьSSL_CLIENT_VERIFYпеременную, если ваша ручная проверка является просто резервным решением для PKI, который вы все равно настроили). Все, что вы будете знать на этом этапе, - это то, что у клиента есть закрытый ключ для сертификата открытого ключа, который он представил (гарантированоCertificateVerifyсообщением TLS ): вам потребуется выполнить некоторую форму проверки, если вы хотите, чтобы какая-то аутентификация была Сортировать. (Вы не можете доверять какому-либо содержимому сертификата, то есть любой привязке между его открытым ключом и именами / атрибутами, которые он содержит.)Это не будет работать для файлов, но вы можете сделать это для приложения (например, PHP / CGI / ... даже Java, если вы передаете сертификат на прокси-сервер Java). Одним из основных способов было бы иметь заранее известный список открытых ключей, или вы можете посмотреть на идеи в FOAF + SSL / WebID .
источник
Использование
SSLVerifyCLient optional_no_ca(вместоrequire) заставляет apache не проверять выдающий CA (и, следовательно, не нужно файл или путь сертификата CA). Это позволяет клиенту / пользователю не предоставлять сертификат, поэтому проверка того, что сертификат вообще использовался, должна выполняться отдельно.(Очевидно, я просто не смог полностью прочитать
mod_sslдокументацию.)источник