Enter pem pass phrase что это

Советы и трюки по работе с OpenSSL

Автор: Джошуа Дэвис (Joshua Davies)

Получение справки о подкомандах OpenSSL

Утилита для работы с командной строкой в OpenSSL является оболочкой для многих «подпрограмм». Для запуска нужной подпрограммы необходимо указать ее имя (например, ca, x509, asn1parse и т. д.) В документации по OpenSSL о подпрограммах сказано не особо много, однако на каждую такую подкоманду есть отдельная страница с документацией. Например, чтобы получить справку о подпрограмме openssl x509, наберите следующую команду:

Просмотр необработанной структуры ASN.1 файла

Протокол SSL является реализацией PKI (Public Key Infrastructure, Инфраструктура Открытых Ключей) и как таковой работает непосредственно с сертификатами. Можно с уверенностью сказать, если при настройке SSL возникли какие-то проблемы, то с 90% вероятностью дело в неправильно сконфигурированном сертификате. Сертификаты (или, если быть более точным, X.509 сертификаты) описываются формальным языком «ASN.1» (или Abstract Syntax Notation (.1)), в чем-то схожим с XML или JSON. Существует довольно много файлов, связанных с сертификатами, и нет никаких стандартов относительно их имен или расширений. Когда файл сертификата обнаружен, просмотр необработанной структуры (raw structure) может помочь в поиске проблемы. Однако если открыть файл сертификата, скажем, в текстовом редакторе, то можно увидеть нечто подобное:

MIICbDCCAioCAQAwaDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlRYMQ4wDAYDVQQHEwVQbGFubzER
MA8GA1UEChMIMnhvZmZpY2UxETAPBgNVBAsTCFJlc2VhcmNoMRYwFAYDVQQDEw1Kb3NodWEgRGF2
aWVzMIIBtzCCASwGByqGSM44BAEwggEfAoGBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2
USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4
O1fnxqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAhUAl2BQjxUjC8yykrmC
ouuEC/BYHPUCgYEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCB
gLRJFnEj6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhR
kImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoDgYQAAoGAOPlkQGq47HhKxmGBTDWaLaa140+Rl3b+
rZk3TpODy/BTS6O+v608EEBnJvF6ck26qFjLBHPC8IihovdcczKEAofIiR+do7CMjUEWdWIFnwKX
6W46ElBJN1ieWl1HtGj5RXnSfcfitiRGOiee1jsyV7wVn0Y4/8vbYPAUFRSPpk2gADALBgcqhkjO
OAQDBQADLwAwLAIUFgkt1lvVhcR1JE6wW7pyBAsgA1wCFHcSuOTaZdIM/dKwJ5dOFgsK0zOi

Файл закодирован по схеме Base64, но раскодировка не даст сколь-нибудь полезных результатов, поскольку в Base64 закодировано представление по стандарту DER (Distinguished Encoding Rule). Чтобы получить нечто более осмысленное, необходимо воспользоваться подкомандой asn1parse:

Результат выполнения подпрограммы:

0:d=0 hl=4 l= 620 cons: SEQUENCE
4:d=1 hl=4 l= 554 cons: SEQUENCE
8:d=2 hl=2 l= 1 prim: INTEGER :00
11:d=2 hl=2 l= 104 cons: SEQUENCE
13:d=3 hl=2 l= 11 cons: SET
15:d=4 hl=2 l= 9 cons: SEQUENCE
17:d=5 hl=2 l= 3 prim: OBJECT :countryName
22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :US
26:d=3 hl=2 l= 11 cons: SET
28:d=4 hl=2 l= 9 cons: SEQUENCE
30:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
35:d=5 hl=2 l= 2 prim: PRINTABLESTRING :TX
39:d=3 hl=2 l= 14 cons: SET
41:d=4 hl=2 l= 12 cons: SEQUENCE
43:d=5 hl=2 l= 3 prim: OBJECT :localityName
48:d=5 hl=2 l= 5 prim: PRINTABLESTRING :Plano
55:d=3 hl=2 l= 17 cons: SET
57:d=4 hl=2 l= 15 cons: SEQUENCE
59:d=5 hl=2 l= 3 prim: OBJECT :organizationName
64:d=5 hl=2 l= 8 prim: PRINTABLESTRING :2xoffice
74:d=3 hl=2 l= 17 cons: SET
76:d=4 hl=2 l= 15 cons: SEQUENCE
78:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
83:d=5 hl=2 l= 8 prim: PRINTABLESTRING :Research
93:d=3 hl=2 l= 22 cons: SET
95:d=4 hl=2 l= 20 cons: SEQUENCE
97:d=5 hl=2 l= 3 prim: OBJECT :commonName
102:d=5 hl=2 l= 13 prim: PRINTABLESTRING :Joshua Davies
117:d=2 hl=4 l= 439 cons: SEQUENCE
121:d=3 hl=4 l= 300 cons: SEQUENCE
125:d=4 hl=2 l= 7 prim: OBJECT :dsaEncryption
134:d=4 hl=4 l= 287 cons: SEQUENCE
138:d=5 hl=3 l= 129 prim: INTEGER :FD7F53811D75122952DF4A9C2.
270:d=5 hl=2 l= 21 prim: INTEGER :9760508F15230BCCB292B982A.
293:d=5 hl=3 l= 129 prim: INTEGER :F7E1A085D69B3DDECBBCAB5C3.
425:d=3 hl=3 l= 132 prim: BIT STRING
560:d=2 hl=2 l= 0 cons: cont [ 0 ]
562:d=1 hl=2 l= 11 cons: SEQUENCE
564:d=2 hl=2 l= 7 prim: OBJECT :dsaWithSHA1
573:d=2 hl=2 l= 0 prim: NULL
575:d=1 hl=2 l= 47 prim: BIT STRING

Если вы немного знакомы с концепцией PKI, то, возможно, уже догадались, что это ни что иное как запрос на подпись сертификата. В недавних версиях OpenSSL появился параметр –i, используемый подкомандой asn1parse и отвечающий за глубину парсинга, что может быть полезно при анализе больших структур (например, цепочек сертификатов).

Работа с PEM-файлами и файлами, закодированными по стандарту DER

Впервые термин PEM начал использоваться в проекте PGP (Pretty Good Privacy), который был особенно популярен в 90-х годах и направлен на защиту электронной почты. В то же время предпринималась попытка популяризировать стандарт IETF, где описывалась общая инфраструктура по шифрованию электронных писем. В настоящее время любой файл, закодированный в Base64 и имеющий отношение к сертификату, мы называем «закодированный по стандарту PEM», даже если он не предназначен для передачи конфиденциальной информации.

Если и в этом случае возникает ошибка «offset too large», значит, файл либо не имеет отношение к сертификату, либо произошло его повреждение во время передачи.

Просмотр содержимого сертификата

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

——BEGIN CERTIFICATE——
MIIEszCCA5ugAwIBAgIJAMR0RhX+M2iEMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCVFgxDjAMBgNVBAcTBVBsYW5vMREwDwYDVQQKEwgy
.
qRH8SwcC2/+kLp5/SqpC7Tv1K1466jrxltb4ncJL6Is8p2FDRn1GTLTj3Z086JgX
s9y/DGoyTw==
——END CERTIFICATE——

Для того чтобы OpenSSL отобразил нечто осмысленное, необходимо указать корректные параметры, например:

-subject
Вывод имени сертификата
-issuer
Вывод имени эмитента сертификата
-dates
Вывод срока действия сертификата

По умолчанию вся информация о сертификате будет выведена после закодированного содержимого. Чтобы закодированное содержимое не выводилось, используйте команду –noout (логичнее было бы сделать использование этого параметра по умолчанию). Если нужно вывести всю общую информацию о сертификате (что требуется в большинстве случаев), используйте параметр –text.

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
56:32:44:76:86:8c:08:92:74:71:0e:ac:a6:7d:ba:1d:7c:d3:
b6:74:ef:27:7a:5e:53:21:fc:8e:eb:26:58:e0:6e:4f:5c:01:
f1:40:ca:0a:e9:d2:0e:00:60:ae:1f:f6:a5:a4:4c:47:fb:e0:
68:7f:25:63:ab:60:38:0f:74:94

Создание самоподписанного тестового сертификата

Параметр –newkey заставляет OpenSSL сгенерировать секретный ключ, иначе вам придется ввести его самостоятельно.

Если вы не хотите выводить на экран содержимое сертификата, используйте параметр –out.

По умолчанию секретный ключ записывается в файл privkey.pem (если уже существует файл с таким именем, то он перезаписывается без предупреждения!). Чтобы избежать возможных проблем, старайтесь определять самостоятельно файл для секретного ключа:

Если вы хотите подцепить SSL на сервере Apache2 (только для тестирования!), раскомментируйте строку #Include /private/etc/apache2/extra/httpd-ssl.conf в файле /etc/apache2/httpd.conf и запустите следующую команду:

При этом вам будет предложено ввести некоторые параметры сертификата, но главное – в параметре Common Name следует указать «localhost».

Создание запроса для загрузки сертификата в центр сертификации

Естественно после тестирования вам потребуется настоящий сертификат. Если, к примеру, установить самоподписанный сертификат на сервер, в браузере пользователя появится следующее сообщение:

Рисунок 1: Сообщение с предупреждением о недостоверном сертификате, которое выводится в браузере Chrome

Вышеуказанная команда создает файл PKCS #10 (или запрос на подпись сертификата), который нужно загрузить в центр сертификации. Процедура получения достоверного сертификата варьируется от центра к центру, но в целом, вначале, вам нужно загрузить CSR-файл через вебформу. По завершению всех необходимых проверок, сертификат будет готов к работе. Обратите внимание, что сертификат не содержит секретный ключ (если вы еще не успели забыть, то он генерируется в отдельный файл). По сути, это часть публичной информации, которую ваш сервер будет отсылать каждому клиенту, пытающемуся подключиться по протоколу HTTPS.

Помните, когда я говорил о том, что могут возникнуть проблемы при перезаписи файла секретного ключа? Так вот, представьте себе ситуацию, когда CSR загружен в центр сертификации, а потом, нечаянно, перезаписан файл секретного ключа. Не забывайте, что секретный ключ не подлежит восстановлению (иначе инфраструктура, а которой базируется SSL, была бы уязвима). Если же ключ утерян, сгенерированный сертификат становится бесполезен (необходимо делать регулярные резервные копии подобных файлов).

Подписание запроса на создание сертификата

При помощи OpenSSL можно создать свой собственный центр сертификации и не прибегать к услугам коммерческих центров и тем самым сэкономить немного денег.

В документации утверждается, что средства по созданию своего собственного центра сертификации были разработаны лишь в демонстрационных целях. Их никогда не планировалось использовать для работы в боевых условиях. Выдержка из документации:

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

Во-первых, как было показано выше, необходимо создать самоподписанный корневой сертификат. После этого создайте конфигурационный файл. В OpenSSL есть пример файла openssl.cnf, который находится в соответствующей папке (название директории может изменяться от версии к версии). В большинстве случаев (и особенно при тестировании) можно использовать как раз этот файл без каких-либо изменений. Если же вы планируете более плотно поработать с сертификатами, следует поподробнее ознакомиться с содержимым файла конфигурации. В нем есть несколько полезных параметров, например, местонахождение серийных номеров и списка отозванных сертификатов (Certificate Revocation List). Я не будут рассказывать обо всех опциях (если по-честному, с некоторыми из них я не сильно знаком). В большинстве случаев вы можете воспользоваться настройками по умолчанию.

Однако некоторые записи из раздела [ CA_default ] ссылаются на директории и файлы, которые, в случае их отсутствия, могут привести к проблемам при развертывании центра сертификации, и вы должны создать все необходимые файлы и папки перед тем, как подписывать CSR. В составе OpenSSL идет простая утилита CA.pl, которая упрощает весь процесс (на самом деле просто создается структура директорий, на которые ссылается файл openssl.cnf). За создание папок отвечает следующая секция:

mkdir demoCA
mkdir demoCA/certs
mkdir demoCA/crl
mkdir demoCA/newcerts
mkdir demoCA/private
touch demoCA/index.txt
echo «01» | demoCA/crlnumber

Этого вполне достаточно, чтобы развернуть простейший центр сертификации. В любой момент, в файле openssl.cnf можно изменить имена файлов и директорий.

После создания рабочего файла конфигурации и валидного CSR, можно подписать запрос при помощи следующей команды:

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

Рассмотрим еще раз весь алгоритм при развертывании центра сертификации:

Создаем конфигурационный файл. Его минимальное содержимое должно быть следующим:

Если вы намереваетесь использовать центр сертификации для серьезных целей, установите сильный пароль для защиты файла cakey.pem и выставьте соответствующие права доступа:

$ chmod 400 cakey.pem

Сам по себе сертификат (в данном случае cakey.pem) будет размещен в конечных пунктах, где будут утверждаться подписанные сертификаты (к примеру, веб сервера, которые сконфигурированы для запроса клиентских сертификатов).

Команда для подписания запроса:

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Смотрим обновленное содержимое директории:

$ ls
ca.cnf certs index.txt.attr serial
cacert.pem index.txt.old serial.old
cakey.pem index.txt signed.pem

Были добавлены новые файлы: index.txt.attr, index.txt.old и serial.old

Также в директории certs появилась копия подписанного сертификат:

Этот файл идентичен файлу signed.pem.

Следует отметить на поле subject у подписанного сертификата:

Оно не совпадает с тем же самым полем из запроса:

Причина в содержимом раздела [ policy ], который находится в конфигурационном файле. Там я указал, чтобы выводился только атрибут commonName. Если бы я заходил отобразить другие атрибуты, то указал бы их отдельно:

countryName = optional
stateOrProvinceName = optional

Важно отметить, что поле subject подписанного сертификата необязательно будет совпадать с полем subject у запроса. Идентичным является лишь публичный ключ.

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

Подписание сертификата с начальной прошлой датой

При работе с сертификатами я столкнулся с проблемой, связанной с часовыми поясами. По умолчанию при подписании сертификата используется часовой пояс сервера. Бывали случаи, когда сертификат, созданный в часовом поясе восточном побережья, не устанавливался на сервере, находящимся на западном. Конечно, проблема не столь критична, но слегка раздражает. В OpenSSL команда ca позволяет указать начальную дату задним числом:

Передача информации для поля subject через командную строку

Если у вас уже есть некоторый опыт по созданию тестовых сертификатов (или даже отправки запроса в центр сертификации), то, возможно, вы заметили, что немного раздражает постоянно указывать поля country, state, locality, и т. д. Вы можете передать эту информацию через командную строку при помощи следующего скрипта:

Источник

Инструкция по созданию запроса на сертификат

Пожалуйста, внимательно и до конца прочитайте и выполните инструкции, расположенные на этой странице.

Даже если вы очень сильно спешите, пожалуйста, прочитайте нижеизложенное: возможно это сэкономит вам время и силы, которые будут потрачены на переписку с RDIG CA в дальнейшем. Спасибо!

Исходные предположения

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

Процедура создания запроса

Первый экран: информация о закрытом ключе

Сначала сценарий выдаст вам информацию о том, куда будет сохранен ваш закрытый ключ:

Если вы генерируете запрос на сертификат узла или сервиса, то предупреждений про пароль не будет и первая порция информации будет выглядеть примерно так:

Второй экран: ввод пароля закрытого ключа

После нажатия клавиши «Enter» будет сгенерирован закрытый ключ:

Если пароли в обоих попытках не совпадут, то будет выдано соответствующее сообщение и вам придется снова дважды ввести пароль:

Если введенный пароль будет короче четырех символов, то вам будет предложено ввести пароль подлиннее:

Завершающий экран

После этого (а для получающих сертификат узла или сервиса — даже не останавливаясь на ввод пароля) сценарий выведет информацию о проделанном:

Внутри этого сообщения есть несколько важных частей.

Часть первая

Суффикс имени файла

Обратите внимание, что файл может называться не «userkey.pem», а, например, «userkey.20080116-191210.pem». Это может произойти потому что на момент запуска сценария файл «userkey.pem» уже существует и, возможно, содержит какой-то закрытый ключ. Поэтому сценарий будет использовать другой файл: к исходному имени добавляется суффикс, основанный на текущих дате и времени.

Если суффикс используется, то он дописывается ко всем создаваемым файлам:

/.globus/ уже существовали файлы usercert.pem, userkey.pem и userreq.mail. Но даже если бы в каталоге

/.globus/ существовал бы только один из этих файлов, то все три созданных файла все равно бы имели суффикс «.20080116-191210».

Таким образом вы всегда сможете понять, какие из файлов были созданы во время данного запуска сценария.

Часть вторая

Если вместо этого вы получаете сообщение

Третья часть

Четвертая часть, необязательная

Далее может следовать необязательный блок текста, указывающий на то, что сценарий создал файлы с нестандартными именами (использовал суффикс имени файлов, как было объяснено выше):

После отправки запроса в RDIG CA, на указанный вами в запросе адрес должно придти потверждение о получении вашего запроса. В нём будет содержаться серийный номер вашего запроса. Используйте его при заполнении бумажной формы.

Может случиться, что вы в течении долгого времени (порядка четырёх-пяти часов) не получаете ответа от RDIG CA с серийным номером вашего запроса. Если вы отправляли запрос по электронной почте, то, вероятно, ваш почтовый агент как-то повредил сгенерированный текст и запрос был отброшен как недействительный. В этом случае, пожалуйста, воспользуйтесь Web-интерфейсом отправки запроса.

Исли и это не исправит ситуации — напишите по адресу rdig-ca-supportgrid.kiae.ru, описав сделанные вами шаги, указав дату и время отсылки запроса в RDIG CA и способ отправки: через Web-интерфейс или электронной почтой. В случае отсылки электронной почтой укажите почтовый адрес, с которого отсылался запрос.

Посещение Registration Authority

При посещении вашего Registration Authority (список всех RA) вам будет необходимо представить ему бумажную форму запроса на сертификат, заполненную и подписанную вами. В форму должны быть заполнены поле с серийным номером запроса и поле с модулем открытого ключа.

Вдобавок, вы должны расписаться и поставить дату в первой части бумажной формы, которая ограничена рамкой с надписью «Заполняется пользователем» (это для сертификата пользователя; для сертификата узла надпись гласит «Заполняется администратором узла», а для сертификата сервиса — «Заполняется администратором сервиса»).

Во второй части бумажной формы, рамка которой имеет подпись «Заполняется Registration Authority», писать ничего не нужно.

Модуль открытого ключа вы сможете получить после успешного завершения работы ранее загруженного файла сценария, а номер запроса — после отправки сгенерированного сценарием запроса в RDIG CA.

Registration Authority удостоверит вашу личность, проверит правильность вашего запроса и ваше право получать сертификат в RDIG CA. Registration Authority имеет право отвергнуть ваш запрос или задержать его одобрение; при этом он должен объяснить вам причину данного действия.

Дальнейшие шаги

После того, как вы посетите вашего Registration Authority и он одобрит или отвергнет ваш запрос, вам должно придти об этом уведомление. Уведомление придет по электронной почте, на адрес, который вы указывали, создавая запрос на получение сертификата.

Письмо об отвержении вашего запроса означает, что Registration Authority не счел возможным выдачу вам сертификата. В письме будет изложена причина отвержения. Если вы просто ошиблись при заполнении формы, указали неправильные данные или сделали что-то подобное, то вы можете попытаться получить сертификат, сделав новый запрос на получение сертификата.

Письмо об одобрении запроса означает, что ваша заявка автоматически поступит операторам RDIG CA и в течение трёх рабочих дней ваш запрос будет рассмотрен. Результатом рассмотрения, скорее всего, станет выдача сертификата.

Готовый сертификат придёт вам по электронной почте. Если сертификат не приходит долгое время, то проверьте страницу действительных сертификатов: быть может, ваш сертификат был подписан, но электронное сообщение не дошло. Тогда сохраните содержимое вашего сертификата на вашу локальную машину.

Источник

eSSL — SSL сертификаты для встраиваемых систем

Немого общей имформации об SSL

eSSL — embedded Secure Socket Layer

Сценарий использования SSL во встраиваемых системах

Создание корневого сертификата

Здесь dir — это базовый каталог в котором будет располагаться наш собственный Центр Сертификации (Certificate Authority). Создаем его в текущем каталоге.
Т.к. наши устройства могут иметь одинаковые имена (параметр commonName при создании сертификата), по этому, параметром unique_subject, мы разрешаем создавать много сертификатов для одного субъекта.
Зададим длину ключа в 2048 (а можно и в 4096) бит.

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

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

Его нужно указать в файле конфигурации(/home/user/my-certs/conf/openssl.cnf), тогда при создании пользовательских сертификатов не нужно будет каждый раз вводить пароль для корневого сертификата.

Его нужно указать в файле конфигурации, тогда при создании пользовательских сертификатов не нужно будет каждый раз вводить пароль для корневого сертификата.

Эти файлы надо «беречь как зеницу ока» ибо ими будут подписываться все сертификаты для конечных пользователей. Но файл ca.crt будет передаваться конечным пользователям для импорта в браузеры.

Сертификаты для устройств

При запуске ему нужно передавать как параметр имя нового сертификата, например

Такой вызов создаст 2 файла device.crt и device.key, т.е. сертификат и ключ к нему. Во время выполнения скрипта будут заданы вопросы о пароле для нового сертификата, а также стране, городе, фирме для кого выпускается сертификат. В поле commonName можно указать любую строку, например My cool device, в обычной практике сюда записывается домен для которого выпускается сертификат, но мы записываем IP адреса (и домены) в раздере альтернативных имен, так что браузеры не ругаются страшными словами, а при просмотре сертификата показывают красивый путь проверки.

Как всё это применять?

Итак, мы создали 2 вида сертификатов, корневой сертификат и сертификат пользователя. Корневой сертификат, как правило, создается один раз и в дальнейшем используется для подписи пользовательских сертификатов, которые мы раздаем пользователям, т.е. помещаем на наши девайсы. Разберемся, как их применять.
Сертификат пользователя и ключ к нему нужно поместить на целевое устройство, у меня это некая плата с ARM контроллером и Linux-ом на борту. Не буду описывать этот процесс, т.к. он зависит от WEBсервера, что у нас там установлен.
А вот корневой сертификат нужно импортировать как корневой сертификат доверенного центра сертификации в каждый браузер пользователя. Только в этом случае браузер не будет показывать предупреждения при заходе на страничку Вашего embedded WEB-сервера.

Импорт корневого сертификата в FireFox 6(Linux)

Импорт корневого сертификата в IE8 (Windows 7 64bit)

Заключение

Мы рассмотрели некоторые возможности SSL сертификатов позволяющие идентифицировать систему имеющую несколько IP адресов и/или Доменных имен, а так же рассмотрели простейший сценарий применения сертификатов во встраиваемых системах. Можно ли улучшить этот сценарий? Конечно можно. Например можно сделать так чтобы корневой сертификат генерировался прямо на устройстве и отдавался пользователю по запросу, например на USB Stick. В этом случае кража корневого сертификата не повлечет за собой опастность для подобных устройств у других покупателей. Применение самоподписанных сертификатов, безусловно, не является наилучшей практикой, но иногда для производителей встраиваемых систем это бывает единственный способ обеспечить минимальную безопастность своих устройств.
Часть информации относящуюся к сертификатам пользователей можно использовать и при покупке сертификатов подписываемых доверенными центрами сертификации. В этом случае обеспечивается наивысший уровень безопастности который может обеспечить технология SSL.

Источник