Системы, использующие сертификаты, и PKI
Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.
Цель PKI состоит в обеспечении надежного и эффективного управления ключами и сертификатами открытых ключей . Пользователи систем, основанных на PKI, должны быть уверены, что в любой момент времени при коммуникации с определенным субъектом они полагаются на открытый ключ, связанный с секретным ключом, владельцем которого является именно этот субъект. Эта уверенность возникает в результате использования сертификатов открытых ключей , связывающих значения открытых ключей с их владельцами. Связывание происходит в результате проверки доверенным УЦ идентичности субъекта и заверения цифровой подписью каждого сертификата открытого ключа.
| Термин на английском языке | Аббревиатура | Термин на русском языке |
|---|---|---|
| Attribute Authority | AA | Атрибутный центр |
| Attribute Certificate | AC | Атрибутный сертификат |
| Certificate | Сертификат | |
| Certification Authority | CA | Удостоверяющий центр (УЦ) |
| Certificate Policy | CP | Политика применения сертификатов (ППС) |
| Certification Practice Statement | CPS | Регламент УЦ |
| End-Entity | EE | Конечный субъект |
| Public Key Certificate | PKC | Сертификат открытого ключа |
| Public Key Infrastructure | PKI | Инфраструктура открытых ключей |
| Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |
| Registration Authority | RA | Регистрационный центр (РЦ) |
| Relying Party | Доверяющая сторона | |
| Root CA | Корневой УЦ | |
| Subordinate CA | Подчиненный УЦ | |
| Subject | Субъект | |
| Top CA | УЦ верхнего уровня |
Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей . Компоненты PKI представлены в табл. 15.6 . Сертификат открытого ключа имеет ограниченный период действия , который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.
| Компонент | Описание |
|---|---|
| Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |
| Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |
| Владельцы сертификатов | Подписывают и шифруют электронные документы |
| Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |
| Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |
Создание сертификатов
Первое, что сделаем, это создадим серверный и клиентские сертификаты. Нужна програмка openssl.exe (у меня установлен xampp , в нём есть всё, что нужно – вам его тоже советую). Итак, в папке /сервер/apache/bin находим openssl.exe и создаём файлы ca.config и openssl.cnf. Также, создадим папку db, а в ней папки certs, newcerts, пустые текстовые файлы index.txt и serial (внутри этого файла написать “01” без ковычек.)
Содержимое файла ca.config
| [ ca ] default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT [ CA_CLIENT ] default_days = 365 # Срок действия подписываемого policy = policy_anything # Название секции с описанием [ policy_anything ] |
Содержимое файла openssl.cnf
| # ================================================= # OpenSSL configuration file # ================================================= RANDFILE = .rnd [ ca ] default_ca = CA_default [ CA_default ] dir = . certs = $dir new_certs_dir = $dir crl_dir = $dir database = $dir/db/index.txt private_key = $dir/ca.key certificate = $dir/ca.crt serial = $dir/db/serial crl = $dir/crl.pem RANDFILE = $dir/db/private/.rand default_days = 365 default_crl_days = 30 default_md = sha1 preserve = no policy = policy_anything name_opt = ca_default cert_opt = ca_default [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem distinguished_name = req_distinguished_name x509_extensions = v3_ca string_mask = nombstr [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [ usr_cert ] basicConstraints = CA:FALSE # nsCaRevocationUrl = https://url-to-exposed-clr-list/crl.pem [ ssl_server ] basicConstraints = CA:FALSE nsCertType = server extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = «OpenSSL Certificate for SSL Web Server» [ ssl_client ] basicConstraints = CA:FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = «OpenSSL Certificate for SSL Client» [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] basicConstraints = critical, CA:true, pathlen:0 nsCertType = sslCA keyUsage = cRLSign, keyCertSign extendedKeyUsage = serverAuth, clientAuth nsComment = «OpenSSL CA Certificate» [ crl_ext ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment nsComment = «OpenSSL generated CRL» |
открываем cmd.exe (Пуск –> Выполнить –> cmd –> enter), далее запускаем через cmd программу openssl.exe и приступаем непосредственно к созданию наших сертификатов.
1) создаём серверный ключ и сертификат
req -new -x509 -days 365 -sha1 -newkey rsa:1024 -nodes -keyout server.key -out server.crt -subj ‘/O=НазваниеКомпании/OU=Подразделение/CN=localhost’
Укажите здесь название вашей компании, подразделения, а также доменное имя.
req -config openssl.cnf -new -x509 -days 3652 -sha1 -newkey rsa:1024 -keyout ca.key -out ca.crt -subj ‘/O=Организация/OU=Подразделение’
Укажите здесь название вашей компании, подразделения.
3) создаём пользовательские сертификаты
- req -new -sha1 -newkey rsa:1024 -nodes -keyout server.key -out request.pem -subj ‘/O=Skif Grid/OU=PSI RAS/CN=localhost’
- ca -config openssl.cnf -policy policy_anything -extensions ssl_server -out signed.pem -infiles request.pem
- x509 -in signed.pem -out server.crt
- openssl pkcs12 -export –in signed.pem –inkey server.key -certfile ca.crt -name «Имя\Отчество» -out user.p12
Получившееся ca.crt и user.p12 импортируем в браузер. С сертификатами покончено, теперь пришло время Apach’a.
Настройка Apache
Открываем файл /сервер/apache/conf/extra/httpd-ssl.conf, стираем всё, что там есть и копируем туда следующее:
| ErrorLog D:/www/apache/logs/ssl_error.log LogLevel warn AddType application/x-x509-ca-cert .crt .pem SSLPassPhraseDialog builtin NameVirtualHost *:443 AddDefaultCharset utf-8 DocumentRoot «D:/www/htdocs» SSLEngine on SSLCertificateFile conf/ssl/server.crt SSLVerifyClient require SSLProxyEngine off
|
Если мы хотим сделать авторизацию не обязательной (скажем, чтобы, если у пользователя не будет сертификата, то показать ему красивую страничку с надписью, скажем – получите сначала сертификат), то SSLVerifyClient поставьте как optional.
Стандарт PGP (Pretty Good Privacy).
Сертификат PGP содержит, прежде всего, открытый ключ и идентификатор (или несколько альтернативных идентификаторов) владельца. Идентификатор владельца может быть как текстовым, так и графическим.
Сертификат может быть заверен более чем одной цифровой подписью; причем каждая подпись заверяет связь открытого ключа с одним или несколькими из приведенных в сертификате идентификаторов владельца (это разрешает реализовать концепцию кумулятивного доверия). Предполагается, что подписчиками могут выступать обычные пользователи.
В конце концов (начиная, по крайней мере, из версии 7.0), для каждого из подписчиков сертификат может содержать пометку о том, что подписант полностью доверяет субъекту (владельцу) сертификата как издателю сертификатов для других пользователей (причем еще и указать домен адресов электронной почты, на который распространяется это доверие). Это дает возможность расширять “сети доверия” пользователей за границы круга их личных знакомых (хотя и недалеко) и создавать корпоративные ИУОК с определенной политикой издания сертификатов практически любой сложности.
Стандарт PGP применяется в одноименной системе защиты электронной переписки. Первая версия этой системы была разработана в 1991 году Ф. Циммерманом (США). Версия 7.0 вышла в 2000 году (как разработка фирмы Network Associates, Inc.).
Стандарт ISO ITU-T X.509v1, 2.
X.509v1 — исторически первый стандарт цифрового сертификата (появился в 1988 году). Отличие между версиями 1 и 2 несущественная.
Сертификат X.509v1, 2 — это обычный идентификационный сертификат с жестким форматом.
Содержит, прежде всего, открытый ключ и идентификатор (один) владельца. Идентификатор владельца является текстовым.
Указывается также срок действия сертификата (открытого ключа).
Заверяется одним издателем.
Стандарт ISO ITU-T X.509v3.
Главное отличие сертификата X.509v3 от сертификата X.509v1, 2 — наличие так называемых приложений (extensions). Стандарт X.509v3 (появился в 1997 году) определяет несколько стандартных (standard), т.е. определенных не только по форме, но и по содержанию, приложений. Кроме того, разрешает включать в сертификат так называемые пользовательские (user-defined) приложения, которые определяются только по форме.
Пользовательские приложения применяются ИУОК, главным образом, для включения в сертификат информации о полномочии субъектов.
Среди наиболее важных стандартных приложений можно выделить такие:
- идентификатор политики издания;
- альтернативные идентификаторы субъекта;
- идентификатор полномочий субъекта как издателя сертификатов (пользователи могут применять это приложение при авторизации полномочий издателя);
- адрес сервера публикации СОС (может быть несколько таких приложений, в том числе, например, адреса сервера публикации дельта-СОС).
Сертификаты формата X.509 применяются подавляющим большинством современных ИУОК. Например, они применяются в системах Visa и MasterCard, на их основе функционирует всемирная ИУОК фирмы VeriSign (эта фирма, в частности, выдает сертификаты для Web-Серверов), на их основе функционируют, как правило, системы, предназначенные для создания корпоративных ИУОК (например, от фирм Entrust и TimeStamp), их применение предусматривает проект глобальной ИУОК для Интернет PKIX.
В рамках спонсорства:
Незабываемый отдых, туристические экскурсии по известным местам, лазурное море, горячий песок, умеренные цены, Анталия (см. www.tourskidki.ru) ждет Вас!..
OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.
Здесь простейшая шпаргалка процедуры подготовки к приобретению SSL/TLS-сертификата, проверки его корректности и применения в web-сервисе, расширенная некоторыми пояснениями.
Генерируем закрытый и открытый ключи.
Работы с компонентами сертификата очень желательно проводить в месте, закрытом от доступа посторонних:
$ mkdir -p ./make-cert
Прежде всего необходимо создать "закрытый" (он же "приватный") и "открытый" (он же "публичный") RSA-ключи шифрования, которые в дальнейшем будут использоваться при создании всех остальных компонентов сертификата и подтверждения подлинности такового на стороне web-сервера:
$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048
Мешанина символов, которую мы видим в текстовом файле ключей на самом деле представляет собой контейнер обфусцированного набора блоков сгенерированных в соответствии с алгоритмом RSA уникальных шифров, и один из этих блоков - "modulus" - является "открытым" ключём связки асимметричного шифрования, используемым во всех компонентах сертификата. Всё остальное содержимое - "закрытый" ключ.
Для ознакомления с содержимым блоков контейнера ключей его код можно раскрыть в более структурированном виде:
$ openssl rsa -noout -text -in ./example.net.key
Ключ (закрытый) шифрования по определению самое секретное, что есть в компонентах SSL-сертификата - потому по умолчанию он защищается паролем. Обязательно запоминаем введённый по запросу утилиты генерации пароль, он нам понадобится.
Надо отметить, что на практике, когда SSL-сертфикат применяется всего лишь для перевода на HTTPS ряда сайтов, большинство предпочитает не возиться с запароленным контейнером ключей, а сразу освобождает его от этой защиты, создавая рядом ещё один - "беспарольный":
$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt
Создаем запрос на выпуск X.509-сертификата (CSR).
Сама по себе подсистема защиты потока трафика посредством SSL/TLS обычно реализуется на сессионных симметричных ключах, вырабатываемых web-сервером и браузером клиента при первичном согласовании соединения, и какие-то особые предустановленные ключи шифрования для этого не требуются (хотя и облегчают процедуру согласования - DH-key, например). Сертификат же (стандарта X.509), набор компонентов которого мы здесь поэтапно формируем, предназначен для своего рода подтверждения подлинности web-ресурса в интернет-инфраструктуре, где условно доверенный центр сертификации гарантирует связь указанных в сертификате "открытого" ключа и описания ресурса посредством электронной подписи содержимого такового.
Для передачи центру сертификации нашего "публичного" ключа (не всего содержимого "приватного" ключа, а лишь его блока "modulus"!) и сведений о ресурсе, подлинность которого мы подтверждаем, предназначен специальный CSR-контейнер (Certificate Signing Request). Создаём его, указывая в качестве источника "открытого" ключа контейнер таковых:
$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr
В процессе потребуется указать данные о собственнике ресурса, для которого запрашивается сертификат, такие как:
"Country Name" - двухсимвольный код страны согласно ISO-3166 (RU - для России);
"State or Province Name" - название области или региона;
"Locality Name" - название города или населённого пункта;
"Organization Name" - название организации;
"Organizational Unit Name" - название подразделения (необязательное поле);
"Common Name" - полностью определённое доменное имя ресурса (FQDN), для которого запрашивается сертификат;
"Email Address" - контактный e-mail адрес администратора доменного имени (необязательное поле);
"A challenge password" - (необязательное поле, не заполняется);
"An optional company name" - альтернативное имя компании (необязательное поле, не заполняется).
Обращаю внимание, что если действие сертификата должно распространяться на поддомены удостоверяемого ресурса, то FQDN в поле "Common Name" потребуется дополнить маской "*." ("*.example.net" - например).
Любопытствующие могут посмотреть, что скрыто в коде CSR-контейнера:
$ openssl req -noout -text -in ./example.net.csr
CSR-файл "example.net.csr" отправляем в удостоверяющий центр, у которого мы приобретаем сертификат.
Приобретение SSL/TLS-сертификата (X.509).
Нюансы выбора поставщика сертификата, процедуры оформления заказа и оплаты здесь не рассматриваются, это не технический вопрос. Один из немаловажных моментов - не пропустить выбор между сертификатом предназначенным для одного домена и "wildcard", покрывающий своими гарантиями все поддомены следующего уровня.
Генерирование самоподписанного X.509-сертификата (опционально).
Как вариант, для использования исключительно в локальной сети, можно создать требуемый сертификат самостоятельно, подписав его своим "закрытым" ключём вместо доверенного центра сертификации - так называемый "self-signed" (самоподписанный):
$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt
В результате работы вышеприведённой команды в дополнение к имеющимся компонентам мы получим файл "example.net.crt" самодельного сертификата, подлинность которого нельзя проверить в интернет инфраструктуре центров сертификации, хотя функционально он нормален и применим.
Проверка корректности сертификатов и ключей.
В полученном SSL/TLS-сертификате зафиксирована как минимум следующая информация:
Версия сертификата;
Серийный номер сертификата;
Алгоритм подписи;
Полное (уникальное) имя владельца сертификата;
Открытый ключ владельца сертификата;
Дата выдачи сертификата;
Дата окончания действия сертификата;
Полное (уникальное) имя центра сертификации;
Цифровая подпись издателя.
Лично я всегда проверяю верность указанных в сертификате данных, декодируя и просматривая его содержимое с помощью следующей команды:
$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt
На практике часто случается так, что некомпетентные клиенты или коллеги предоставляют для применения непосредственно в web-сервисах перепутанные сертификаты и ключи, не связанные между собой. Попытка применения таковых в web-сервере вызовет ошибку вроде "x509 key value mismatch".
Простейший способ проверки корректности связки "приватного" ключа, CSR-запроса и финального X.509-сертификата заключается в сверке контрольной суммы "публичного" ключа (блока "modulus"), содержащегося во всех этих контейнерах:
$ openssl rsa -noout -modulus -in ./example.net.key | openssl md5
$ openssl req -noout -modulus -in ./example.net.csr | openssl md5
$ openssl x509 -noout -modulus -in ./example.net.crt | openssl md5
Строка MD5-хеша короткая, и выявление различий между ними не составит труда.
Формируем типовой набор файлов сертификатов и ключей.
Обычно центры сертификации предоставляют не только запрашиваемый сертификат, а ещё и дополнительный набор промежуточных сертификатов (самого центра, его вышестоящего узла, и так вплоть до корневого узла).
В общем, в процессе у нас может скопиться несколько файлов, которые я именую соответственно их функционалу, примерно так:
"example.net.key" - контейнер с "закрытым" и "открытым" ключами (защищённый паролем);
"example.net.key.decrypt" - незащищённый паролем контейнер с "закрытым" и "открытым" ключами;
"example.net.csr" - CSR-запрос, использовавшийся при заказе сертификата;
"example.net.crt" - непосредственно наш X.509-сертификат;
"intermediate.crt" - сертификат (или цепочка таковых) центра сертификации;
"root.crt" - сертификат корневого центра, от которого начинается цепь доверия.
Промежуточные сертификаты нам предоставлены не только для ознакомления - ими желательно дополнить предназначенный для применения в web-сервисе контейнер с нашим сертификатом, сформировав там цепочку вплоть до общеизвестного доверенного узла. Делается это простейшим добавлением текстовых кодов в конец файла:
$ cd ./make-cert
$ cat ./example.net.crt >> ./example.net-chain.crt
$ сat ./intermediate.crt >> ./example.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt
Обращаю внимание, что наш сертификат обязательно должен быть в начале цепочки, размещённой в контейнере - обычно web-сервер сверяет прилагаемый "закрытый" ключ с "открытым" в первом попавшемся в процессе чтения содержимого контейнера сертификате.
В Linux-е для сертификатов и ключей шифрования уже предусмотрены места в файловой системе. Распределяем файлы и защищаем их от доступа посторонних:
# mkdir -p /etc/ssl/certs
# mkdir -p /etc/ssl/private
# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/
# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl
SSL-сертификат в web-сервере Nginx.
В самом простом случае применение SSL-сертификата в web-сервере "Nginx" реализуется примерно следующим образом:
# vi /etc/nginx/sites-enabled/example.net.conf
....
server {
listen 443 ssl;
server_name example.net;
....
ssl on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_certificate /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....
SSL-сертификат в web-сервере Apache.
В web-сервере "Apache" SSL-сертификат применяется примерно так:
# vi /etc/apache2/sites-enabled/example.net.conf
....
# Описание рабочего окружения доступного по HTTPS web-сайта
ServerName example.net
....
# Рекомендуемые обобщённые настройки протокола
SSLEngine on
SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
SSLCompression off
# Файлы сертификатов и ключей
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt
....
Формат сертификата Х.509
Х.509 - это другой очень распространённый формат. Все сертификаты Х.509 соответствуют международному стандарту ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающем этот стандарт. На практике, однако, сложилась ситуация, что разные компании создают собственные расширения для Х.509, не все из которых между собой совместимы.
Всякий сертификат требует, чтобы кто-то заверил взаимосвязность открытого ключа и идентифицирующей владельца ключа информации. Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащихся в нём сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). Но в случае сертификатов Х.509 заверителем может быть только Центр сертификации или некто, специально уполномоченный им на эту роль. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)
Сертификат Х.509 - это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).
Сертификат Х.509 содержит следующие сведения:
Версия Х.509 - указывает, на основе какой версии стандарта Х.509 построен данный сертификат, что определяет, какая информация может в нём содержаться.
Открытый ключ владельца сертификата - открытый ключ наряду с идентификатором используемого алгоритма (указывающим криптосистему, к которой принадлежит данный ключ) и прочая информация о параметрах ключа.
Серийный номер сертификата - организация-издатель сертификата обязана присвоить ему уникальный серийный (порядковый) номер для его опознавания среди прочих сертификатов, выданных данной организацией. Эта информация применяется в ряде случаев; например, при аннулировании сертификата, его серийный номер помещается в список аннулированных сертификатов (Certificate Revocation List, CRL).
Уникальный опознаватель владельца ключа (или DN, distinguished name - уникальное имя) - это имя должно быть уникальным и единственным во всём Интернете. DN состоит из нескольких подпунктов и может выглядеть примерно так:
CN=Bob Davis, [email protected], OU=PGP Engineering,
O=PGP Corporation, C=US
(Что обозначает Понятное имя субъекта, Электронную почту, Подразделение организации, Организацию и Страну соответственно.)
Период действия сертификата - дата начала действия сертификата и дата окончания его действия; указывает на то, когда сертификат станет недействителен.
Уникальное имя издателя - уникальное имя организации, подписавшей сертификат. Обычно, это наименование Центра сертификации. Использование сертификата подразумевает доверие организации, его подписавшей. (В случаях с корневыми сертификатами выдавшая организация - этот же ЦС - подписывает его сама.)
ЭЦП издателя - электронная подпись, созданная закрытым ключом организации, выдавшей сертификат. Идентификатор алгоритма подписи - указывает алгоритм, использованный ЦС для подписания сертификата.
Существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:
вы можете лично создать собственный сертификат PGP;
вы должны запросить и получить сертификат Х.509 от Центра сертификации; сертификаты Х.509 содержат только одно имя владельца сертификата;
сертификаты Х.509 содержат только одну ЭЦП, подтверждающую подлинность сертификата.
Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляете системе свой открытый ключ, чем доказываете, что обладаете соответствующим закрытым, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет - запрос сертификата - в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной информации и, если всё сходится, создаёт сертификат, подписывает и возвращает вам.
