Проверка сертификата SSL

Я хотел бы знать, каковы точные шаги аутентификации сертификата через HTTP. Я знаю, что это было задано раньше, но из того, что я прочитал, до сих пор неясно, как это работает.

  1. При первом обращении к защищенному клиенту сайта клиент отправит свой сертификат

    • Это будет его открытый ключ (скажем, файл public_key.pem, просящий с ----BEGIN PUBLIC KEY----)
  2. Сервер будет проверять, был ли этот сертификат подписан доверенным ЦС.

    • Сервер имеет только список сертификатов, которым он доверяет (вы настраиваете это хранилище ключей при настройке SSL). Именно там хранятся все секретные ключи. Это эквивалентно всем доверенным ЦС сервера?
    • Следующий шаг теперь - принять public_key.pem и проверить, подписывали ли какие-либо из сертификатов в хранилище ключей.

Если вышеуказанный процесс является точным:

Первый вопрос: "сертификат" - это закрытый ключ, подписанный другим сертификатом (или самозаверяющим)

Второй вопрос: как именно сервер подтверждает, что открытый ключ был подписан с конкретным закрытым ключом (сертификатом)?

Третий вопрос: "сертификат" A может использоваться для подписи другого "сертификата" B, поэтому "сертификат" B может использоваться для подписания сертификата C и т.д. Если у моего сервера есть сертификат A в его доверенном хранилище, это означает, что он также будет доверять открытым ключам, поступающим из сертификатов B и C?

Изменить на основе ответа ниже

Мой сервер имеет cert.pem и privkey.pem. Сертификат cert.pem (сертификат x509) был подписан доверенным ЦС с использованием его закрытого ключа (процесс "подписания" включает в себя CA, чтобы сделать "что-то" с его закрытым ключом и подписать мой запрос на подпись сертификата).

Когда SSL согласован, мой сервер отправит cert.pem клиенту (в некоторой форме). Как клиент определяет, что мой публичный сертификат был подписан доверенным ЦС. My truststore pb содержит только другие общедоступные сертификаты доверенных ЦС, поэтому он проверяет, подписан ли мой cert.pem, используя только общедоступные сертификаты доверенных ЦС. Это та часть, которая неясна, и я могу не понимать весь процесс. Может ли клиент проверить, действительно ли мой сертификат x509 имеет только список сертификатов доверенных центров сертификации x509?

0
27 янв. '17 в 16:33
источник поделиться
1 ответ

При первом обращении к защищенному клиенту сайта клиент отправит свой сертификат

Клиенту не нужно отправлять сертификат. Судя по вашему вопросу, не похоже, что вы спрашиваете конкретно об аутентификации клиентов-сертификатов. На многих сайтах, например, если вы переходите на google, stackoverflow, facebook и т.д., Клиент/браузер не отправит сертификат.

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

Не совсем. Сертификат содержит открытый ключ, который подписывается закрытым ключом, который соответствует другому сертификату.

Я думаю, что это стоит прояснить. Сам сертификат будет содержать только открытый ключ или "Subject Public Key Info" на языке x509. Для этого открытого ключа имеется соответствующий закрытый ключ, который хранится отдельно от сертификата x509.

Существуют некоторые форматы, которые "объединяют" сертификат и закрытый ключ в один файл, но на данный момент он больше не является сертификатом, это файл, содержащий сертификат, примером которого является PKCS № 12. Это формат, который может хранить как можно больше сертификатов и частных ключей.

Закрытый ключ может даже не быть файлом на диске - он может быть в модуле безопасности, смарт-карте и т.д.

"сертификат" A может использоваться для подписи другого "сертификата" B, поэтому "сертификат" B может использоваться для подписания сертификата C и т.д. Если у моего сервера есть сертификат A в его доверенном хранилище, это означает, что он также будет доверять открытым ключам, поступающим из сертификатов B и C?

Да. Это называется цепочкой сертификатов. A является "корневым" сертификатом, B является "промежуточным", а C - сертификатом "конец-сущность" или "лист".

Это очень распространено среди сертификатов HTTPS по CA. Сертификаты никогда не выдаются непосредственно из корня, они выдаются с промежуточного.

Как точно проверяет сервер, что открытый ключ был подписан с определенным закрытым ключом (сертификатом)?

Это делает предположение, что сертификат является закрытым ключом, а это не так.

Сервер, как и в обслуживании HTTPS, действительно не заботится о действительности сертификата. Это зависит от клиента, чтобы решить, должен ли он доверять сертификату, предоставленному сервером.

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

Сервер будет предоставлять сертификат клиенту, как браузер. Браузер проверяет многие вещи, но, как минимум, он проверит две важные вещи:

  1. Может ли браузер построить цепочку обратно к сертификату в хранилище доверия. Поэтому браузер будет смотреть на подписчика сертификата, называемого Эмитентом, и проверить, находится ли его эмитент в хранилище доверия. Если да, то сертификат доверен. Если нет, он увидит, есть ли у этого сертификата Эмитент, и зацикливайтесь до конца цепи до тех пор, пока он не достигнет конца цепочки, или когда он не найдет что-то в хранилище доверия. Если он достигнет конца, то сертификат не выдается кому-либо, которому он доверяет.

  2. Сертификат действителен для этого домена. Сертификат содержит альтернативное имя субъекта (SAN), которое указывает, в каких доменах действителен сертификат.

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

Как клиент определяет, что мой публичный сертификат был подписан доверенным ЦС.

У каждого клиента есть собственный магазин доверия. Internet Explorer в Windows использует хранилище доверия Windows, Google Chrome на MacOS и Windows использует хранилище доверия операционной системы (Keychain, Windows Trust Store и т.д.).

Браузеру/клиенту необходимо создать путь доверия, как описано выше. Как это немного сложнее, но он работает с атрибутом Authority Key ID - если он существует, а также с имуществом Issuer сертификата. Он использует эти значения для поиска сертификата, который его выпустил.

Как только он находит сертификат выдачи, он проверяет подпись в сертификате с открытым ключом сертификата эмитента.

Сертификат выдачи может находиться в "корневом" хранилище доверия и использует открытый ключ в сертификате выдачи для проверки подписанного сертификата.

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

может ли клиент проверить, действительно ли мой сертификат x509 действителен, просто имея список сертификатов доверенных центров сертификации x509?

Да. Это магазин доверия. Каждый браузер имеет/использует его. У Firefox есть собственный магазин доверия NSS. У операционных систем также есть свой собственный магазин доверия.

3
27 янв. '17 в 17:59
источник

Посмотрите другие вопросы по меткам или Задайте вопрос