Предположим, у меня есть сайт, на который я хочу, чтобы пользователи могли входить в систему с помощью клиентских сертификатов. Насколько я понимаю, клиент представляет сайту публичную половину пары ключей и доказывает, что у них есть соответствующая приватная половина. Это правильно? Если да, то не проверяет ли клиент, что он предоставляет известный (ранее авторизованный) открытый ключ, достаточный, чтобы знать, что это известный пользователь, без подписи сертификата доверенным центром сертификации?
Конечно, вы можете это сделать, но теряете преимущества центра сертификации. Преимущество ЦС в том, что вам нужно знать только ЦС, вам не нужно заранее знать каждого клиента индивидуально. Если вы используете схему, в которой вы распознаете только ключ, вам необходимо индивидуально настроить каждый ключ на сервере. Если вы просто хотите знать, что это один и тот же пользователь, вы можете просто подтвердить, что это тот же открытый ключ.
Конечно, а ты жестяная банка Сделайте это, попросив клиентов самостоятельно подписать каждый сертификат и вручную доверять каждому из них как своему собственному корневому ЦС, вместо того, чтобы их подписывал доверенный ЦС.
Но в этом нет особого смысла - похоже, у вас есть клиенты, которые иметь сертификаты, подписанные доверенным центром сертификации. Вы просто пытаетесь избежать этапа проверки доверительных отношений?
Вы можете пояснить, чего пытаетесь достичь?
Когда вы используете аутентификацию сертификата клиента, ближе к концу рукопожатия клиент отправляет Certificate Verify Сообщение TLS где он подписывает своим закрытым ключом конкатенацию всех сообщений TLS, которыми обмениваются клиент и сервер: что-то, что хорошо известно обоим.
Это не зависит от того, является ли сертификат клиента доверенным или нет. Сервер все еще проверяет подпись по общему ключу, представленному в сертификате клиента. Если это не удастся, рукопожатие не удастся.
В конце рукопожатия, независимо от того, доверяет ли сервер тому, что утверждает сертификат, то есть привязке между открытым ключом, идентификатором и различными другими атрибутами, он будет знать, по крайней мере, что у клиента есть закрытый ключ для общедоступного ключ в этом сертификате (остальное может быть правдой, а может и нет).
Если у вас есть заранее определенный список известных открытых ключей (сродни открытым ключам, которые вы могли бы настроить, например, для SSH-соединения), вы можете выполнить аутентификацию таким образом. Что вам не хватает, так это PKI: вся инфраструктура, которая поможет вам управлять ключами и тем, кому они принадлежат. Поскольку большинство параметров конфигурации предназначены для использования в PKI, может потребоваться дополнительная работа (включая, возможно, дополнительное программирование).
Все остальные свойства TLS-соединения остаются неизменными: шифрование по-прежнему гарантируется так же, как и в контексте PKI. Я не уверен, о чем говорит @WesleyDavid в своем ответе на эту тему. В любом случае, это касается клиентских сертификатов, поэтому шифрование между клиентом и сервером будет происходить в любом случае, независимо от того, представлен ли клиентский сертификат (конечно, при условии, что используется набор шифров с ненулевым шифрованием).
Предположим, у меня есть сайт, на который я хочу, чтобы пользователи могли входить в систему с помощью клиентских сертификатов.
Чтобы быть ясным, мы говорим о входе в систему с сертификатами и не говорим о каких-либо темах шифрования.
Насколько я понимаю, клиент представляет сайту публичную половину пары ключей и доказывает, что у них есть соответствующая приватная половина. Это правильно?
Это правильно для аутентификации пары ключей.
Если да, то не проверяет ли клиент, что он представляет известный (ранее авторизованный) открытый ключ, достаточный для того, чтобы знать, что это известный пользователь, без подписи сертификата доверенным центром сертификации?
Достаточно знать, что у клиента, пытающегося пройти аутентификацию, есть закрытый ключ (и, возможно, пароль закрытого ключа, если он был защищен таким образом). Пока это просто для аутентификации, а не для шифрования, вам не нужно беспокоиться о центрах сертификации. Вам просто нужно собрать открытые ключи и соответствующим образом делегировать полномочия на основе этих ключей.