Сертификат не является секретной информацией, скорее напротив - это то, что устройство передает на проверку. Секретная информация - закрытый ключ ключевой пары. Он должен храниться на устройстве.
Английский - очень важен в ИБ. Вариантов несколько:
- добросовестно учить англ в универе
- доп. курсы или репетитор или даже заниматься по skype с носителем.
- lingualeo и т.п. Помогает расширить словарный запас.
- фильмы/сериалы на английском языке.
retaliation Возможность использовать ГОСТ не означает, что CA не может использовать RSA. Вы можете изучить требования на сайте www.webtrust.org и попробовать их выполнить при создании своего PKI. В РФ даже нет лицензированного аудитора для этой задачи. Вам придется приглашать из Европы или другой ближайшей страны.
Согласно принятой в последнее время терминологии все таки ЭП (электронная подпись), а не ЦП. Конкретную реализацию не подскажу.
Но если вы используете PHP, то подпись делается так: php.net/manual/ru/function.openssl-sign.php
А проверка так: php.net/manual/ru/function.openssl-verify.php
Изначально вам надо сгенерировать ключевую пару, например, используя openssl. Закрытый ключ нужен для подписи. Открытый ключ используется для проверки подписи.
HSM - это и есть специальное железо. Для одной базы вам нужен 1 HSM. Пользователи напрямую с HSM не работают. Это будет делать ваш софт, обрабатывающий запросы к базе. Промышленные HSM - недешевое удовольствие. Крупнейшие производители: Thales, Safenet, Utimaco, Bull.
Смарт-карта - это по сути тоже HSM в простейшем виде.
Игорь Мамонтов: Да, подойдет. Судя по описанию вам при заказе надо добавить домены.
Choose a Symantec SSL Certificate and secure multiple domain names by adding them to the Subject Alternative Name (SAN) field during enrollment.
Михаил: Полагаю, что, используя только OAuth, ваш сайт может получить идентификатор пользователя от facebook и использовать его как идентификатор пользователя на вашем сайте.
Судя по всему вам надо сделать так в /etc/nginx/conf.d/default:
ssl_certificate /etc/nginx/certs/server.crt; - Это сертификат, выданный Comodo
ssl_certificate_key /etc/nginx/certs/server.key; - Это закрытый ключ в сертификату, выданному Comodo
ssl_client_certificate /etc/nginx/certs/ca.crt; - Это сертификат, который вы получите для сервера по моей инструкции в п.2
ssl_verify_client on;
Прочитал ваш комментарий на соседний ответ.
То, что вам надо - получить сертификат от доверенного УЦ (например, Comodo).
Дальше настраивайте ваш веб сервер в соответсвтии с тем, как я описал:
выпускаете ключевую пару, сертификат УЦ, потом подписывете клиентские сертификаты вашим УЦ. А веб-серверу указываете сертификат вашего УЦ в том месте, где требуется, чтобы ваш веб-сервер проверял пользовательские сертификаты исходя из доверия сертификату вашему УЦ.
Это вообще 2 разные задачи: сертификат сервера и сертификат пользователя. И они не мешают друг другу.
Так что рекомендую перечитать мой изначальный ответ.
извините, не понимаю о чем речь.
То, что описал я: настройка аутентификации (не путайте с авторизацией) на веб сервере (хоть domain.com, хоть subdomain.domain.com). Аутентификация через браузер будет работать, да.
Даже если VPN клиент и VPN сервер - одна и та же машина(что мне кажется бессмысленным на первый взгляд), то у вас должны в итоге быть 2 разных IP у сервера и у клиента. Так устроен стек протоколов TCP/IP
я имею в виду, что при помощи openssl вы можете получить pfx, а потом установить его на сервер с IIS через консоль mmc. Остнастка сертификаты. хранилище компьютера, а не пользователя.
Посмотрите требования GeoTrust например - https://www.geotrust.com/support/true-businessid/e...
P.S.: Конечно можно обойти любые проверки.