Что такое сертификат клиента и где его получить, как использовать его для подключения к серверу?
Я пишу клиентское приложение на C ++ для получения некоторой информации с сервера через https, но сервер запрашивает сертификат клиента для аутентификации, я знаю, как работает сертификат сервера во время просмотра веб-страниц через https: общедоступный сертификат передается любому веб-браузеру, который Приходите с обширным встроенным списком доверенных корневых сертификатов, который подключается к веб-сайту и доказывает веб-браузеру, что поставщик считает, что он выдал сертификат владельцу веб-сайта, но я не совсем уверен относительно клиента сертификат.
Я много гуглил, но все еще растерялся. Кто-нибудь может мне это объяснить? И где я могу получить сертификат клиента? С сервера? Я знаю, что могу загрузить файл сертификата, позвонив SSL_CTX_use_certificate_chain_file() и загрузите закрытый ключ, позвонив SSL_CTX_use_PrivateKey_file в openssl, если у меня есть сертификат клиента и закрытый ключ клиента.
Решение
Во-первых, мы должны знать Закрытый ключ / Открытый ключ:
Шифрование с использованием пары закрытый ключ / открытый ключ гарантирует, что данные могут быть зашифрованы одним ключом, но могут быть расшифрованы только другой парой ключей. Ключи схожи по своей природе и могут использоваться альтернативно: то, что один ключ шифрует, другая пара ключей может расшифровать. Пара ключей основана на простых числах, а их длина в терминах битов обеспечивает сложность возможности расшифровки сообщения без пар ключей. Хитрость в паре ключей заключается в том, чтобы сохранить один ключ в секрете (закрытый ключ) и распространить другой ключ (открытый ключ) среди всех. Любой может отправить вам зашифрованное сообщение, которое только вы сможете расшифровать. Вы единственный, у кого есть другая пара ключей, верно? Напротив, вы можете подтвердить, что сообщение приходит только от вас, потому что вы зашифровали его с помощью своего закрытого ключа, и только соответствующий открытый ключ расшифровывает его правильно. Осторожно, в этом случае сообщение не защищено, вы только подписали его. У всех есть открытый ключ!
Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message
Одна из оставшихся проблем — узнать открытый ключ вашего корреспондента. Обычно вы просите его отправить вам не конфиденциальное подписанное сообщение, которое будет содержать его открытый ключ, а также сертификат.
Откуда вы знаете, что имеете дело с правильным человеком или, вернее, с правильным веб-сайтом? Ну, кто-то потратил много времени (если он серьезен), чтобы убедиться, что владельцы веб-сайтов являются теми, кем себя называют. Этот человек, которому вы должны безоговорочно доверять: у вас есть его / ее сертификат, загруженный в ваш браузер (корневой сертификат). Сертификат содержит информацию о владельце сертификата, например адрес электронной почты, имя владельца, использование сертификата, срок действия, местоположение ресурса или отличительное имя (DN), которое включает в себя общее имя (CN) (адрес веб-сайта или электронный адрес). -адрес электронной почты в зависимости от использования) и идентификатор сертификата лица, которое сертифицирует (подписывает) эту информацию. Он также содержит открытый ключ и, наконец, хеш, чтобы гарантировать, что сертификат не был подделан. Поскольку вы сделали выбор в пользу доверенного лица, подписывающего этот сертификат, вы также доверяете этому сертификату. Это дерево доверия сертификата или путь сертификата. Обычно ваш браузер или приложение уже загрузили корневой сертификат хорошо известных центров сертификации (CA) или корневые сертификаты CA. CA поддерживает список всех подписанных сертификатов, а также список отозванных сертификатов. Сертификат небезопасен, пока не подписан, так как только подписанный сертификат не может быть изменен. Вы можете подписать сертификат с помощью самого себя, он называется самоподписанным сертификатом. Все корневые сертификаты CA являются самозаверяющими.
Клиентские сертификаты:
Клиентские сертификаты выдаются пользователю центром сертификации. Они состоят из части открытого ключа сертификата и личного ключа, который хранится только у субъекта, которому выдан сертификат. Центром сертификации может быть известная общественная организация, предоставляющая услуги по сертификации в рамках своей деятельности, или внутренний сервер, которым пользуется только ваша компания. В любом случае клиентский сертификат будет иметь определенную информацию, которая идентифицирует пользователя по отдельности или как часть группы. Они предназначены для аутентификации клиента на сервере.
Например, вы можете создать самозаверяющий сертификат клиента так же, как сертификат сервера:
openssl req -nodes -new -x509 -keyout clientkey.pem -out clientreq.pem -days 365 -config openssl.cnf
Ответьте на необходимые вопросы, затем подпишите:
openssl x509 -x509toreq -in clientreq.pem -signkey clientkey.pem -out tmp.pem
openssl ca -config openssl.cnf -policy policy_anything -out clientcert.pem -infiles tmp.pem
Затем вы можете попробовать подключиться к серверу с помощью сертификата клиента:
openssl s_client -connect host:443 -cert clientcert.pem -key clientkey.pe -state -quiet
Одна важная деталь в клиентских сертификатах (сертификаты в целом) заключается в том, что их можно экспортировать, и большинство реализаций не блокируют переносимость сертификата. Независимо от того, будут ли храниться сертификаты клиента или как они будут храниться, без надлежащих мер сертификат может быть легко скопирован с устройства на устройство. Некоторые реализации хранят сертификат в файловой системе (файлы, оканчивающиеся на .cer, .der, .key, .crt, обычно указывают на то, что сертификаты хранятся в файловой системе). Более сильные реализации (зависящие от приложения) могут хранить сертификаты и ключи в хранилище ключей (то есть хранилище ключей Java). Хранилище ключей может добавить дополнительную защиту, например, гарантировать, что закрытый ключ не экспортируется. Однако уверенность в том, что ключ не был экспортирован, так же сильна, как и само хранилище ключей. Хранилища аппаратных ключей (например, смарт-карты, usb hsm, ironkey и т. Д.) Дают гораздо более надежную гарантию того, что закрытый ключ не экспортируется, чем хранилища программных ключей.
Другие решения
Вы должны создать пару ключей, создать запрос на подпись сертификата, а затем подписать его центром сертификации. Все тщательно документировано для OpenSSL и не по теме для SO.
Сертификат клиента используется в двусторонних или взаимных SSL-соединениях. Обычное SSL-соединение, которое вы описали в своем вопросе, это односторонний SSL … клиентский браузер аутентифицирует сервер.
В двухстороннем SSL сервер также должен аутентифицировать клиента. Поэтому клиенту нужен сертификат.
Одним из примеров этого сценария является случай, когда компания / субъект, которому принадлежит сервер, хочет контролировать, кто к нему подключается. Поэтому они выдают учетные данные клиента тем, кому доверяют, чтобы подключиться к нему. Эти учетные данные могут принимать форму электронных токенов USB, программных клавиш и т. Д. Если программные клавиши создаются на клиентском компьютере, CSR отправляется владельцу сервера (или доверенному серверу CA), который, в свою очередь, может подписать Сертифицируйте и отправьте его обратно клиенту.