Первое, что сделаем, это создадим серверный и клиентские сертификаты. Нужна програмка 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) создаём пользовательские сертификаты
Получившееся ca.crt и user.p12 импортируем в браузер. С сертификатами покончено, теперь пришло время Apach’a.
Открываем файл /сервер/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.
OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.
Здесь простейшая шпаргалка процедуры подготовки к приобретению SSL/TLS-сертификата, проверки его корректности и применения в web-сервисе, расширенная некоторыми пояснениями.
Генерируем закрытый и открытый ключи.
Работы с компонентами сертификата очень желательно проводить в месте, закрытом от доступа посторонних:
$ mkdir -p ./make-cert
$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048
Мешанина символов, которую мы видим в текстовом файле ключей на самом деле представляет собой контейнер обфусцированного набора блоков сгенерированных в соответствии с алгоритмом RSA уникальных шифров, и один из этих блоков - "modulus" - является "открытым" ключём связки асимметричного шифрования, используемым во всех компонентах сертификата. Всё остальное содержимое - "закрытый" ключ.
$ openssl rsa -noout -text -in ./example.net.key
Надо отметить, что на практике, когда SSL-сертфикат применяется всего лишь для перевода на HTTPS ряда сайтов, большинство предпочитает не возиться с запароленным контейнером ключей, а сразу освобождает его от этой защиты, создавая рядом ещё один - "беспарольный":
$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt
Сама по себе подсистема защиты потока трафика посредством 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" - альтернативное имя компании (необязательное поле, не заполняется).
Любопытствующие могут посмотреть, что скрыто в коде CSR-контейнера:
$ openssl req -noout -text -in ./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
Проверка корректности сертификатов и ключей.
В полученном SSL/TLS-сертификате зафиксирована как минимум следующая информация:
Версия сертификата;
Серийный номер сертификата;
Алгоритм подписи;
Полное (уникальное) имя владельца сертификата;
Открытый ключ владельца сертификата;
Дата выдачи сертификата;
Дата окончания действия сертификата;
Полное (уникальное) имя центра сертификации;
Цифровая подпись издателя.
$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt
Простейший способ проверки корректности связки "приватного" ключа, 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
Формируем типовой набор файлов сертификатов и ключей.
Обычно центры сертификации предоставляют не только запрашиваемый сертификат, а ещё и дополнительный набор промежуточных сертификатов (самого центра, его вышестоящего узла, и так вплоть до корневого узла).
В общем, в процессе у нас может скопиться несколько файлов, которые я именую соответственно их функционалу, примерно так:
"example.net.key" - контейнер с "закрытым" и "открытым" ключами (защищённый паролем);
"example.net.key.decrypt" - незащищённый паролем контейнер с "закрытым" и "открытым" ключами;
"example.net.csr" - CSR-запрос, использовавшийся при заказе сертификата;
"example.net.crt" - непосредственно наш X.509-сертификат;
"intermediate.crt" - сертификат (или цепочка таковых) центра сертификации;
"root.crt" - сертификат корневого центра, от которого начинается цепь доверия.
$ 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
В 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" реализуется примерно следующим образом:
# 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;
....
}
....
В 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 согласованы с международным стандартом ITU-T X.509; таким образом (теоретически), сертификат Х.509, созданный для одного приложения, может быть использован в любом другом, поддерживающим этот стандарт. На деле, однако, выясняется, что разные компании создали собственные расширения Х.509, многие из которых друг с другом никак не совместимы.
Имея дело с PGP-сертификатом, каждый может выступать в качестве заверителя содержащейся в нём информации (за исключением случаев, когда эта возможность намеренно ограничена системным администратором). Однако, в случае сертификатов Х.509, заверителем может быть только Центр сертификации или некто, специально уполномоченный им. (Имейте в виду, что PGP-сертификаты также в полной мере поддерживают иерархическое структурирование системы доверия, использующее ЦС для удостоверения сертификатов.)
Сертификат Х.509 -- это набор стандартных полей, содержащих сведения о пользователе или устройстве, и их соответствующий открытый ключ. Стардарт Х.509 определяет, какие сведения входят в сертификат и как они кодируются (формат данных).
Сертификат Х.509 содержит следующие сведения:
Существует ряд различий между форматами сертификатов Х.509 и PGP, но наиболее выделяются следующие:
Чтобы получить сертификат Х.509, вы должны попросить ЦС выдать его вам. Вы предоставляется свой открытый ключ, тем самым доказывая, что обладаете соответствующим частным, а также некоторые идентифицирующие вас сведения. Затем вы электронно подписываете эти сведения и отправляете весь пакет -- запрос сертификата -- в Центр сертификации. ЦС выполняет определённый процесс по проверке подлинности предоставленной вами информации и, если всё сходится, создаёт сертификат и возвращает его вам.
Вы можете представить сертификат Х.509, как обычный бумажный сертификат или аттестат с прилепленным к нему общественным ключом. На нём написано ваше имя, а также некоторые сведения о вас, плюс подпись лица, выдавшего сертификат.
Рис. Сертификат Х.509
Вероятно, наибольшая польза от сертификатов Х.509, это их применение в Веб-браузерах.
Необходимость защиты информации
Продолжающееся бурное развитие компьютерных технологий и повсеместное внедрение в бизнес с использованием Интернета коренным образом изменяет устоявшиеся способы ведения бизнеса. Системы корпоративной безопасности, обеспечивающие бизнес, тоже не могут оставаться в стороне.
В настоящее время, например, средства электронной почты, используются не только для общения между людьми, а для передачи контрактов и конфиденциальной финансовой информации. Web сервера используются не только для рекламных целей, но и для распространения программного обеспечения и электронной коммерции. Электронная почта, доступ к Web серверу, электронная коммерция, VPN требуют применения дополнительных средств для обеспечения конфиденциальности, аутентификации, контроля доступа, целостности и идентификации. В настоящее время в качестве таких средств повсеместно используются средства криптографической защиты и Инфраструктура Открытых Ключей (ИОК).
Система криптографической защиты должна обеспечивать:
Криптографическое преобразование (шифрование)- взаимно-однозначное математическое преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации (представленной в некоторой цифровой кодировке) блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.
Криптография делится на два класса: с симметричными ключами и открытыми ключами.
В криптографии с симметричными ключами отправитель и получатель используют один и тот же (общий) ключ, как для шифрования, так и для расшифрования.
Преимущества криптографии с симметричными ключами:
Недостатки криптографии с симметричными ключами:
В криптографии с открытыми ключами используется пара ключей: открытый ключ и секретный (личный) ключ, известный только его владельцу. В отличие от секретного ключа, который должен сохраняться в тайне, открытый ключ может распространяться по сети. Секретный ключ в криптографии с открытыми ключами используется для формирования электронной подписи и расшифрования данных.
Криптография с открытыми ключами обеспечивает все требования, предъявляемые к криптографическим системам. Но реализация алгоритмов требует больших затрат процессорного времени. Поэтому в чистом виде криптография с открытыми ключами в мировой практике обычно не применяется. Для шифрования данных используются симметричные (сеансовые) ключи, которые в свою очередь шифруются с использованием открытых для передачи сеансовых ключей по сети.
Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI - Public Key Infrastructure) - неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.
Верификация открытого ключа
Непосредственное использование открытых ключей требует дополнительной их защиты и идентификации для определения связи с секретным ключом. Без такой дополнительной защиты злоумышленник может представить себя как отправителем подписанных данных, так и получателем зашифрованных данных, заменив значение открытого ключа или нарушив его идентификацию. В этом случае каждый может выдать себя за английскую королеву. Все это приводит к необходимости верификации открытого ключа. Для этих целей используется электронный сертификат.
Электронный сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. Для заверения электронного сертификата используется электронная цифровая подпись доверенного центра - Центра Сертификации (ЦС). Исходя из функций, которые выполняет ЦС, он является основной компонентой всей Инфраструктуры Открытых Ключей. Используя открытый ключ ЦС, каждый пользователь может проверить достоверность электронного сертификата, выпущенного ЦС, и воспользоваться его содержимым.
Верификация цепочки сертификатов
Как описывалось ранее, доверие любому сертификату пользователя определяется на основе цепочки сертификатов. Причем начальным элементом цепочки является сертификат центра сертификации, хранящийся в защищенном персональном справочнике пользователя.
Процедура верификации цепочки сертификатов описана в рекомендациях X.509 и RFC 2459 и проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все "правильные" цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.
Алгоритм верификации цепочек использует следующие данные:
Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:
Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:
После построения двух цепочек (сертификатов и СОС) выполняется:
В состав компонент ИОК входят следующие компоненты:
Центр Сертификации (или Удостоверяющий Центр) - основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненных Центров и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов X.509 CRL (СОС) с регулярностью, определенной Регламентом системы.
К основным функция ЦС относятся:
Опциональная компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР - регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.
Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.
Опциональная компонента ИОК, содержащая сертификаты и списки отозванных сертификатов и служащая для целей распространения этих объектов среди пользователей с использованием протокола LDAP (HTTP, FTP).
ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.
Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure Multipurpose Internet Mail Extensions), который является расширением стандарта Internet почты MIME (Multipurpose Internet Mail Extensions).
Web броузеры и сервера используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых банковских приложений и электронных магазинов. Наиболее распространенным протоколом в этой сфере является протокол SSL (Secure Sockets Layer). Протокол SSL не ограничивается применением только для защиты HTTP (Hypertext Transfer Protocol), а также может быть использован для FTP (File Transfer Protocol) и Telnet.
Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.
Стандарты в области ИОК делятся на две группы: часть из них описывает собственно реализацию ИОК, а вторая часть, которая относится к пользовательскому уровню, использует ИОК, не определяя ее. На приведенном рисунке показана связь приложений со стандартами. Стандартизация в области ИОК позволяет различным приложениям взаимодействовать между собой с использованием единой ИОК.
В особенности стандартизация важна в области:
Основным центром по выпуску согласованных стандартов в области ИОК является рабочая группа ИОК (PKI working group) организации IETF (Internet Engineering Task Force), известная как группа PKIX (от сокращения PKI for X.509 certificates).
Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) firmy RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.509 в повседневной практике пользователи, поставщики и комитеты по стандартизации обращаются к стандартам PKCS. PKIX группа издала следующие стандарты Internet (RFC).
Стандарт 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) ждет Вас!..
