Вопросы Теги

Клиентская ошибка аутентификации сертификата

Кэширующийся слой помог бы со статическим содержанием, но я не вижу, как это поможет с динамическими API очень. Однако это может все еще быть полезно.

Например, Вы могли использовать CDN, чтобы помочь кэшировать и распределить статические вещи уменьшить рабочую нагрузку Вашего сервера так, чтобы это могло провести больше времени на динамическом материале.

Для Вашего динамического материала, можно хотеть использовать что-то как то, что он упомянул здесь при использовании CDN для динамического материала.

3
задан 13 September 2010 в 02:06
3 ответа

Тот же способ, которым сертификаты сервера однозначно определяют сервер (или домен), клиентские сертификаты, однозначно определяет клиент. И точно так же, как сертификаты сервера должны быть подписаны кем-то клиентские тресты, клиентские сертификаты должны быть подписаны кем-то тресты сервера.

Обычно при конфигурировании сервера для принятия клиентских сертификатов, Вы указываете сертификат подписания, который должен использоваться для подписания сертификата клиента. Это позволяет серверу знать, что клиент "авторизовывается", независимо от того, что это могло бы означать в Вашем контексте, так как, по-видимому, Вы только подпишете сертификаты для "авторизованных" пользователей.

Разрешение клиентских сертификатов, не делая никакого вида проверки обычно возможно с большинством серверов, но видом поражений целая цель.

5
ответ дан 3 December 2019 в 05:08
  • 1
    @kelly.dunn, которому список CA доверял сервером, абсолютно независимо от АВАРИИ, которой доверяют клиентом, таким образом, у Вас может быть Verisign-сертифицированный сертификат для Вашего сервера (поскольку большинство клиентов будет доверять им по умолчанию), и примите решение принять клиентские сертификаты от своего собственного CA (для клиентов, к которым Вы испустили такие сертификаты). CA.pl который идет с OpenSSL (см. man CA.pl) сценарий, который может помочь Вам создать свое собственное Приблизительно –  Bruno 13 September 2010 в 21:56
  • 2
    @Bruno Благодарит, это разрешило некоторый остаточный беспорядок, который я имел о "доверяемой АВАРИИ", мое понимание выросло немного с тех пор вчера :D Но теперь это кажется нечетным, когда я явно установил клиент список CA в моем приложении для включения моей собственной доверяемой АВАРИИ. Я закончил "неизвестный CA" ошибка, но клиент все еще не примет мой сервер cerfiticate ~ –  kelly.dunn 14 September 2010 в 21:40
  • 3
    Это не примерно список CA, но о доверительных привязках (фактические доверяемые сертификаты CA). Они отличны (список CA на SSL/TLS CertificateRequest сообщение является на самом деле просто подсказкой). Если Вы смотрите на то, как Apache, Httpd делает это, список, настроен через SSLCADNRequestFile директива, тогда как принятая АВАРИЯ прибывает из SSLCACertificatePath/...File (конфигурирование SSLCADNRequestFile обычно не необходимо, поскольку список DN CA автозаполняется списком АВАРИИ по умолчанию. Посмотрите это: stackoverflow.com/questions/3476288 / … –  Bruno 14 September 2010 в 22:06

Это зависит от типа сертификата сервера. Иногда самоподписываемые сертификаты могут быть проблематичными. Если это подписывается Центром сертификации, обычно клиентский сертификат должен будет также быть подписан тем же CA и, возможно, нуждается во всей цепочке сертификата, включенной также.

Можно использовать openssl для сбора некоторой информации о приемлемой АВАРИИ для клиентских сертификатов с командной строкой:

openssl s_client -connect host.domain.tld:443

или независимо от того, что порт SSL слушает на. Это должно дать информацию о цепочке сертификата полностью до корневого CA и также обеспечить приемлемую АВАРИЮ для клиентских сертификатов также.

3
ответ дан 3 December 2019 в 05:08

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

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

0
ответ дан 3 December 2019 в 05:08

Теги

Похожие вопросы