Что такое код openssl_csr_new


Содержание

Что такое код openssl_csr_new

openssl_csr_new — генерирует privkey и CSR.

Описание

bool openssl_csr_new (array dn, resource privkey [, array extraattribs [, array configargs]])

Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.

Предупреждение!

Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.

openssl_csr_new

openssl_csr_new — генерирует privkey и CSR.

Описание

bool openssl_csr_new (array dn, resource privkey [, array extraattribs [, array configargs]])

Предупреждение!

Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.

Предупреждение!

Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.

1.2.1. Создание запроса на сертификат с помощью OpenSSL

Не важно, UNIX у вас или Windows: если вы решили создавать CSR с помощью программы openssl — все действия будут одинаковые, отличаться могут разве только пути к файлам.

Если предполагается, что сертификат должен быть правильным для нескольких доменных имен, то предварительно нужно обеспечить возможность передать openssl дополнительные доменные имена (основное будет запрошено). К сожалению, в openssl нет никакого механизма, чтобы SAN (Subject Alternate Names — альтернативные имена субъекта) можно было запрашивать с консоли. Поэтому, чтобы иметь возможность создавать запросы на сертификаты как с дополнительными именами, так и без них, в файле /etc/ssl/openssl.cnf на том компьютере, на котором создается CSR, следует сделать небольшие добавления, а именно заменить в секции [v3_req] строку subjectAltName, наложив следующий патч (именно этот патч накладывает скрипт keyreq):

— openssl.cnf.old 2012-03-25 21:43:23.000000000 +0700

+++ openssl.cnf 2012-03-25 21:44:47.000000000 +0700 @@ -261,7 +261,7 @@

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

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

SAN=»DNS: www. first. org, DNS :firse. org, DNS: www. second, org»

Ну и, разумеется, для задания содержимого SAN можно использовать все способы, описанные в разделе 1.1.3.

Программа openssl имеет столько различных параметров и режимов работы, что даже описывается не в одной man-странице, а каждому ее режиму работы посвящена отдельная страница. В данном случае мы пользуемся режимом req — режимом генерации запросов на сертификацию. Полная командная строка генерации нового CSR при наличии SAN выглядит так:

env SAN=”DNS:dcltahv.ru, DNS:www.deltahw.ru, emaihcopy, URI: http://www.dcltahw.ru” openssl req -new -shal -newkey rsa:2048 -nodes -keyout filename.key -out filename.pem -config /etc/ssl/ openssl.cnf

При отсутствии необходимости в SAN строка будет куда короче и патч предварительно накладывать не надо:

openssl req -new -shal -newkey rsa:2048 -nodes -keyout filenamc.key -out filename.pern -config /etc/ssl/openssl.cnf

Вся приводимые команды — это одна строка, без конвейеров и перенаправлений! Запускается команда env, которая формирует заданную переменную окружения и вызывает заданную команду, передав ей эту переменную, оттого запись несколько громоздкая. Конечно, это не все ключи командной строки — их там раза в два больше, но остальные имеют отношение главным образом к отображению подготовленного CSR, перекодировке его между различными форматами и созданию самоподписанных сертификатов, которые обычно используются или для тестирования, или как сертификаты СЛ. Эти операции описаны в разделе 1.6.

Разберем нужные нам ключи командной строки подробнее.

  • -new создает новый CSR и заполняет его данными, которые запрашивает у пользователя.
  • -sha 1 — указывает message digest для запроса.
  • -rsa:2048 создаваемый сертификат будет формата RSA 2048 бит. -nodes — не шифровать ключ сертификата.
  • -keyout имя файла ключа сертификата.
  • -out — имя файла собственно CSR.
  • -config указывает, где находится конфигурационный файл openssl.

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

Что здесь можно было бы поменять: кроме message digest sha 1, есть еще md5, md2 и mdc2. Поскольку они все априори слабее, используется максимально сильный digest. (Как известно, message digest позволяет гарантировать, что текст сообщения не был модифицирован.)

Ключи RSA длиной 2048 бит стали использоваться совсем недавно, до этого были 512 и 1024 бита.

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

keyout и out задают имена файлов ключа и CSR. Их можно задавать произвольно.

config — указывает расположение конфигурационного файла openssl. Ключ обязателен только в том случае, если используется конфигурационный файл, расположенный не в /etc/ssl, а в другом месте. В Windows этот ключ обязателен.

Какие еще можно было бы использовать ключи: х509 — мы его использовали при генерации сертификата СЛ. Если в команде указан этот ключ, то генерируется самоподписанный сертификат, а не CSR, серийный номер этого сертификата устанавливается в 0.

days — задает время, в течение которого сертификат будет действителен. По умолчанию для обычных сертификатов — 365 дней (1 год), для CRL — 30 дней. Для сертификатов СА обычно задается достаточно продолжительный период времени (10 лет и более, например мы при создании нашего сертификата СЛ указали интервал 20 лет).

set serial — имеет смысл только для сертификатов СЛ. Задает серийный номер сертификата С Л и фактически номер, с которого начнется нумерация в данном СЛ (все сертификаты получают номер после номера СЛ). Правда, при этом нужно соответствующим образом поправить файл serial.

При создании CSR (любым способом), как правило, нужно указывать некоторые данные. Практически ни одни запрашиваемые данные не являются обязательными, но не указать некоторые — значит просто создать бессмысленный сертификат, потому что многие проверки базируются как раз на значениях, получаемых из этих полей. Все данные указываются ASCII-кодами с применением транслитерации. Транслитерация русских букв, вообще говоря, не стандартизирована, некоторые используют свои собственные таблицы, но я как человек ленивый предпочитаю использовать готовую таблицу, которую используют при заполнении загранпаспортов [5].

При вводе строк имейте в виду, что кавычки любого типа считаются недопустимыми символами — сертификат с ними будет создан, но в дальнейшем при попытке проверить его поля могут возникнуть проблемы в силу того, что кавычки в ОС UNIX могут быть «интерпретированы», а не просто переданы. То есть при получении, например, строки ‘ sometext’ будет выполняться команда sometext. Разные программы по-разному обрабатывают поля, а сертификат выдается надолго. Обнаружите ошибку — и придется еще год с ним мириться, писать обходы — ведь как всегда, по закону падающего бутерброда, ошибочный сертификат будет выдан одному из директоров. Поэтому лучше ограничиться старым добрым DOS’obckum стандартом — [a-zA- Z0-9], а также символами «минус» и «знак подчеркивания». Максимальная длина строк указана в разделе 1.1.2.

Как правило, запрашиваются:

  • ? страна (Country). Указывается двухбуквенным кодом по ISO 3166, Россия имеет код «RU»;
  • ? регион (State or Province). Указывается произвольной строкой текста. При этом слово «область» обычно указывается как region;
  • ? город (Locality). Указывается название города;
  • ? наименование организации (Organization Name). Указывается наименование организации вместе с организационно-правовой формой, при этом для указания собственно формы используется не транслитерация сокращения, а его перевод в общепринятое латинское, например ООО => LLC, несмотря на то что это не точное соответствие. Можно также указать в конце наименования Ltd [1] ;
  • ? наименование подразделения (Organizational Unit Name). Указывается наименование подразделения организации, если, конечно, таковое имеется. Также можно вписать любой текст, который можно потом проверить;
  • ? общее имя (Common Name). Самое важное поле, собственно, из-за которого сертификат и выдается. Заносить сюда произвольное значение можно, только если сертификат запрашивается для человека. Если запрашивается сертификат для серве- ра/сервиса, в этом поле должно содержаться DNS-имя сервера, к которому будут обращаться. Имя должно быть записано в точности так, как будет использоваться. Если, например, будет использоваться http://www.deltahw.ru, то поле CN должно содержать www.deltahv;.ru. Если же сертификат запрашивается на человека, то сюда обычно заносятся имя и фамилия;
  • ? адрес электронной почты (Email). Самое важное поле в персональных сертификатах. Здесь указывается адрес электронной почты, для защиты которой он будет использоваться. Если персональный сертификат будет использоваться с другой целью (например, для доступа к защищенному ресурсу), сюда можно вписать произвольный текст, но для защиты электронной почты такой сертификат уже не подойдет. Для серверов/сервисов не используется, можно вписать произвольный текст, обычно это адрес электронной почты ответственного лица.

Итак, создадим запрос на сертификат для сервера www.deltahw.ru таким образом, чтобы допустимыми именами для него были также deltahw.ru и ftp.deltahw.ru:

# env SAN=”DNS:dcltahw.ru, DNS: ftp.dcltahw.ru, emaihcopy, URI: http://www.deltahw.ru” opcnssl rcq -new -shal -newkey rsa:2048 -nodes -keyout deltalnv.key -out deltahw.pem -config /etc/ssl/opcnssl.cnf

Generating a 2048 bit RSA private key . +++

writing new private key to ‘deltahw.key’

You are about to be asked to enter information that w’ill be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank For some fields there will be a default value,

If you enter the field will be left blank.

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:Novosibirsk region Locality Name (eg, city) [ ] :Novosibirsk

Organization Name (eg, company) [Internet Pty Ltd]:DeltaHardware Ltd. Organizational Unit Name (eg, section) []:Web Server Common Name (eg, YOUR name) []rwww.deltahw.ru Email Address []: Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script

Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []:

An optional company name []:

Теперь у нас есть файл ключа сертификата — перемещаем его сразу в каталог /etc/ssl — и файл CSR. В нашем случае файл CSR мы сразу можем переписать в ssl.csr и создавать сертификат. В обычном случае CSR направляется в СЛ обычными способами — электронной почтой, FTP, веб-формами, даже на флэшке можно принести — в нем нет ни конфиденциальной информации, ни пользы для того, кто его может перехватить. В Windows файл ключа просто прибирается «подальше» до тех пор, пока не будет получен собственно сертификат, после чего сертификат вместе с ключом будет импортирован в системное хранилище, поскольку один личный ключ поместить в системное хранилище нельзя.

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

21 пример команд OpenSSL, которые помогут вам на практике

Одним из самых популярных инструментов для создания и управления SSL-сертификатами является библиотека OpenSSL. В этой статье я расскажу о часто используемых командах OpenSSL.

Некоторые аббревиатуры, относящиеся к сертификатам:

  • SSL – Secure Socket Layer (уровень защищённых cокетов).
  • CSR – Certificate Signing Request (запрос на получение сертификата).
  • TLS – Transport Layer Security (протокол защиты транспортного уровня).
  • PEM – Privacy Enhanced Mail (формат файлов для хранения и отправки криптографических ключей).
  • SHA – Secure Hash Algorithm (алгоритм криптографического хеширования).
  • PKCS – Public-Key Cryptography Standards (стандарты криптографии с открытым ключом).

1. Создание нового секретного ключа и запрос на получение сертификата

Команда генерирует CSR и файл 2048-битногоRSA-ключа. Если вы собираетесь использовать этот сертификат на Apache или Nginx, то необходимо отправить CSR-файл в центр сертификации. Он предоставит вам заверенный сертификат (в формате der или pem) , который нужно настроить на веб-сервере Apache или Nginx.

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

Команда генерирует самозаверенный сертификат и файл 2048-битного RSA-ключа. Я также включил в команду хеш-функцию sha256, поскольку она считается наиболее безопасной.

Совет: По умолчанию команда генерирует самозаверенный сертификат, действительный только один месяц. Для увеличения этого срока переопределите параметра — days.

Пример: для получения сертификата, действительного два года.

3. Верификация CSR-файла

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

4. Создание секретного RSA-ключа

Если нужно создать секретный RSA-ключ, используйте приведенную выше команду.

5. Удаление пароля-фразы из ключа

Если вы используете составной пароль (фразу) в файле ключа и работаете на Apache, то при каждом запуске нужно вводить секретную фразу. Если вас это раздражает, то можно использовать приведенную выше команду, чтобы удалить пароль-фразу из существующего ключа.

6. Верификация секретного ключа

Если вы сомневаетесь в файле ключа, то можете использовать данную команду.

7. Верификация файла сертификата

Если хотите проверить данные сертификата, такие как CN, OU и т.д., используйте приведенную выше команду, которая предоставит данные сертификата.

8. Верификация центра сертификации

Для проверки центра сертификации можно использовать приведенную выше команду.

9. Проверка хеш-значения сертификата

10. Преобразование формата DER в PEM

Центр сертификации предоставляет SSL-сертификат в формате .der . Если вам необходимо использовать его в формате apache или .pem , примените приведенную выше команду для соответствующего преобразования.

11. Преобразование формата PEM в DER

Если необходимо изменить формат .pem на .der .

12. Преобразование сертификата и секретного ключа в формат PKCS#12

Если необходимо использовать сертификат с Java-приложением, принимающим только формат PKCS#12, примените приведенную выше команду. Она генерирует один pfx файл, содержащий сертификат и ключ.

Совет. Вы также можете включить цепочку сертификатов, передав параметр -chain, как показано в примере ниже.

13. Создание CSR с использованием существующего секретного ключа

Если не хотите создавать новый секретный ключ вместо существующего, выполните приведенную выше команду.

14. Проверка содержимого сертификата в формате PKCS12

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

15. Преобразование формата PKCS12 в PEM-сертификат

Если нужно использовать существующий файл в формате pkcs12 на Apache или только в формате pem , в этом поможет приведенная выше команда.

16. Проверка SSL-сертификата определенного URL-адреса

Я часто использую эту команду для проверки SSL-сертификата URL-адреса. Это удобно для проверки данных протокола, шифрования и сертификата.

17. Определение версии OpenSSL


18. Проверка даты истечения срока действия PEM-файла

Команда выведет дату в формате notBefore и notAfter. notAfter — это та дата, которая нужна, чтобы определить, истек ли срок действия сертификата или он еще действителен.

19. Проверка срока действия SSL-сертификата для URL-адреса

Команда позволяет контролировать дату истечения срока действия SSL- сертификата удаленно или для конкретного URL-адреса.

20. Проверка, принимается ли на URL-адресеSSL V2 или V

Чтобы проверить SSL V2:

Чтобы проверить SSL V3:

Чтобы проверить TLS 1.0:

Чтобы проверить TLS 1.1:

Чтобы проверить TLS 1.2:

Если необходимо проверить, включен ли SSL V2 / V3 или нет, используйте приведенную выше команду. Если он включен, то вы получите сообщение «CONNECTED», в противном случае –сообщение «handshake failure».

21. Проверка того, принимается ли конкретный шифр на URL-адресе

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

Для этого необходимо задать шифр и URL-адрес. Если шифр будет принят, вы получите сообщение «CONNECTED», иначе – сообщение «handshake failure».

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

Данная публикация представляет собой перевод статьи « 21 OpenSSL Examples to Help You in Real-World » , подготовленной дружной командой проекта Интернет-технологии.ру

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

В наши дни очень часто для повышения безопасности сетевых соединений или просто для аутентификации используются ssl сертификаты. Одна из самых популярных свободных программ для создания сертификатов — это OpenSSL. Это утилита командной строки, которая позволяет создавать различные виды сертификатов, например, PKI или HTTPS.

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

Что такое сертификаты?

Думаю нужно начать с самого начала. Сертификаты в первую очередь позволяют идентифицировать человека, подтвердить что вы тот, за кого себя выдаете. А работает это так — есть два ключа — закрытый и открытый. Зашифровать сообщение можно с помощью открытого ключа, но чтобы его расшифровать нужен только закрытый ключ. Если у вас нет закрытого ключа, то вы попросту не сможете расшифровать зашифрованное сообщение. Фактически зашифровать сообщение может каждый, но расшифровать его способен только владелец закрытого (секретного ключа).

Если вы смогли расшифровать отправленное сообщение, зашифрованное с помощью вашего открытого ключа, то значит — это вы. Ключи работают только в паре, и вы не сможете расшифровать ничего другим ключом. Но еще остался один момент. Как определить что этот открытый ключ именно ваш, например, принадлежит вашему домену? Все просто, достаточно, чтобы кто-то из авторитетных источников, например, Comodo или LetsEncrypt подписал ваш ключ. Это так называемые центры сертификации.

В этой инструкции мы будем иметь дело с такими видами ключей:

  • .pem, .crt, .cer — готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей компании;
  • .key — закрытый или открытый ключ;
  • .csr — запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, о компании и домене, которую вы указали.

А теперь рассмотрим как создать сертификат openssl, как его подписать и что для этого нужно сделать. Генерация ключей openssl — это довольно простая задача, если во всем разобраться.

Создание закрытого ключа и запроса на подпись

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

Чтобы создать закрытый ключ и запрос на подпись открытого ключа выполните такую команду:

openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

Опция -newkey указывает, что нужно создать новую пару ключей, а в параметрах мы сообщаем тип rsa и сложность 2048 байт. Опция -nodes указывает, что шифровать ключ не нужно, опция -new указывает что нужно создать запрос csr. Если у вас уже есть закрытый ключ, то вы можете создать для него csr запрос такой командой:

openssl req -key domain.key -new -out domain.csr

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

openssl genrsa -des3 -out domain.key 2048

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

openssl x509 -in domain.crt -signkey domain.key -x509toreq -out domain.csr

Параметр -x509toreq указывает, что нужно использовать сертификат для X509 для получения CSR. X509, это сертификаты, подписанные сами собой. Обычно сертификат подписывается другим сертификатом, а этот был подписан сам собой. Если вы получили сертификат от CA, то этот параметр не нужен.

Подпись сертификатов OpenSSL

Допустим, у вас есть приватный ключ и запрос на подпись, фактически, открытый ключ. Теперь вам нужно его подписать чтобы получить сертификат, который можно использовать. Тут есть несколько вариантов. Можно отправить csr файл на подпись какому-либо центру сертификации, например, LetsEncrypt. Можно подписать сертификат тем же ключом, с помощью которого он был создан, и третий вариант — создать свой центр сертификации.

Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:

openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt

С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:

openssl req -newkey rsa:2048 -nodes -keyout domain.key
-x509 -days 365 -out domain.crt

Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:

openssl req -key domain.key -new -x509 -days 365 -out domain.crt

Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL — подписать его с помощью собственного CA, центра сертификации.

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

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

Дальше нужно создать самоподписанный сертификат openssl для нашего CA:

openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout /etc/ca/certs/ca.key -out /etc/ca/certs/ca.crt -days 3654

Параметр -extensions загружает необходимые расширения для создания сертификата центра сертификации. Мы устанавливаем долгий строк действия — десять лет. Осталось подписать наш сертификат, созданный ранее:

openssl ca -extensions x509_client -in

Готово, теперь наш сертификат подписан. Но теперь, чтобы браузеры ему доверяли нужно добавить сертификат CA в список доверенных браузера.

Просмотр сертификатов

Сертификаты сохраняются в формате pem, а это значит, что вы не сможете их открыть как текстовый файл и нужно использовать специальные команды для просмотра информации о них. Сначала смотрим содержимое csr:

openssl req -text -noout -verify -in domain.csr

Смотрим содержимое сертификата в режиме обычного текста:

openssl x509 -text -noout -in domain.crt

Проверяем действительно ли сертификат подписан нужным CA:

openssl verify -verbose -CAfile ca.crt domain.crt

Просмотр закрытого ключа:

openssl rsa -check -in domain.key

Чтобы проверить связаны ли между собой закрытый ключ, сертификат и открытый ключ можно подсчитать сумы md5 для этих ключей, если значения совпадут, то есть вероятность что это ключи из одной пары:

openssl rsa -noout -modulus -in domain.key | openssl md5
$ openssl x509 -noout -modulus -in domain.crt | openssl md5
$ openssl req -noout -modulus -in domain.csr | openssl md5

Выводы

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

Генерация CSR-запроса на Linux/MacOS

Для получения SSL-сертификата вам необходимо сгенерировать CSR-запрос, а затем заказать сертификат SSL в панели управления 1cloud c использованием созданного запроса. Эта процедура выполняется одинаково для любого веб-сервера под управлением Linux (Apache, Nginx и т.д.).

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

Создание CSR-запроса с помощью сервиса генерации

Лучшие цены на SSL-сертификаты (от 550 руб.)

  • Все доверенные центры сертификации
  • Большой выбор сертификатов
  • Пошаговые инструкции по выпуску и установке

Самый простой способ создания CSR-запроса — использование одного из многочисленных онлайн CSR-генераторов (CSR generator).

Важно! Для генерации запроса таким сервисам необходимо также создать для вас пару открытый/закрытый ключ. Последний является конфиденциальным и не должен передаваться вами третьим лицам. Несмотря на это, соблюдение данного требования сделает работу CSR-генераторов технически невозможной, поэтому сервис так или иначе будет иметь доступ к вашему файлу секретного ключа. Если этот факт является для вас критичным, используйте приведенную ниже инструкцию по самостоятельной генерации CSR-запроса с помощью OpenSSL. Если для вас предпочтительнее использовать онлайн CSR-генератор, выбирайте только проверенные сервисы и обращайте внимание на подлинность сайта сервиса.

Генерация CSR-запроса с помощью OpenSSL

OpenSSL — кроссплатформенное программное решение для работы с технологиями SSL/TLS. С помощью него вы можете выполнять различные операции по управлению криптографическими ключами.

Сгенерировать ключи и CSR-запрос вы можете на любой машине под управлением Linux (Ubuntu, Debian, CentOS) или MacOS. Проще всего сгенерировать запрос CSR (Certificate Signing Request) на том же веб-сервере, на который вы планируете установить сертификат сайта, но можно использовать и другую машину, а затем перенести сгенерированные файлы на веб-сервер.

Для генерации запроса CSR выполните следующие операции:

  1. Откройте командную строку (терминал) вашего Linux/MacOS компьютера или подключитесь к Linux-серверу по SSH.
  2. Перейдите в директорию, в которую будут сохранены сгенерированные ключи. Например, для выбора директории /home/root, выполните: cd /home/root
  3. Сгенерируйте CSR-запрос и приватный ключ: openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Примечание: при работе с OpenSSL не используйте символы

! @ # $ % ^ * / \ ( ) . &
Примечание: длина ключа (rsa) должна быть от 2048 до 8192 бит

Если библиотека openssl не установлена на вашем сервере, вы можете установить ее с помощью команды:
Ubuntu/Debian: apt-get install openssl
CentOS: yum install openssl
Откроется форма для заполнения информации о сертификате. Укажите точные данные владельца веб-сайта.
Например:

  • Country Name (двухбуквенный код страны) — RU (для России)
  • State or Province (Район, Область) — Saint Petersburg
  • Locality (Полное название города) — Saint Petersburg
  • Organization (Официальное наименование организации) — Full Company Name LLC

Примечение: При заказе сертификата физическим лицом (актуально для SSL-сертификатов с проверкой домена (DV-Domain Validation), в этом поле необходимо указать полное имя владельца сертификата, а в поле Organizational Unit — название вашей площадки или бренда.

  • Organizational Unit (необязательное поле: отдел/департамент) — IT
  • Common Name (Имя домена, на который оформляется SSL-сертификат) — www.mydomain.com

    Примечание:Если вы заказываете Wildcard-сертификат (сертификат для домена и его поддоменов), указанное здесь доменное имя должно начинаться с символа * (*.mydomain.com).

  • После генерации в директории, выбранной на шаге 1, появятся файлы закрытого ключа (.key) и запроса на подпись сертификата (.csr). Приватный ключ должен располагаться на вашем веб-сервере и не передаваться третьим лицам.
    Содержимое файла запроса необходимо прикрепить к форме заказа сертификата в панели управления 1cloud.

  • Заказ SSL-сертификата через панель управления 1cloud

    Созданный на предыдущих шагах CSR-запрос следует скопировать в панель управления 1cloud. Самый простой способ — открыть файл запроса в терминале (на локальном компьютере или через SSH) и скопировать его содержимое в буфер обмена, а затем вставить скопированный CSR-запрос в соответствующее окно панели управления 1cloud.

    1. Открыть файл CSR-запроса можно командой:
      Debian/Ubuntu: nano home/root/CSR.csr CentOS:
      а) Установите редактор nano (если он еще не установлен): yum install nano б) Отройте файл CSR-запроса: nano home/root/CSR.csr Примечение: Если вы указали другую папку для сохранения ключей, укажите этот путь в команде выше.
    2. Содержимое файла следует полностью скопировать в окно запроса CSRпанели управления 1cloud. Для этого скопируйте содержимое CSR.csr в буфер обмена из командной строки или блокнота. Откройте панель управления 1cloud, выберите интересующий вас сертификат и нажмите кнопку Заказать. На вкладке Данные владельца вставьте скопированное ранее содержимое и заполните необходимые поля ниже. Нажмите Заказать.

    На этом процедура заказа SSL-сертификата завершена. Инструкции по получению заказанного сертификата будут отправлены на ваш адрес электронной почты.

    После получения сертификата его необходимо установить на веб-сервер. Для этого вы можете воспользоваться нашей одной из наших инструкций по установке SSL-сертификата на веб-сервер (Apache, Nginx и др.).

    Что такое код openssl_csr_new

    1. Подключится к серверу по защищённому протоколу ssh.

    1.1. Вам необходимо скачать ssh-клиента PuTTY, это можно сделать в любой поисковой системе (к примеру Google или Yandex набрав в строке поиска: «Скачать PuTTY»).

    1.2. Установить и настроить данную программу в соответствии с рекомендациями на странице http://hosting.nic.ru/support/ssh/index.shtml

    2. Сгенерировать приватный ключ и файл csr

    2.1 Генерируем приватный ключ:

    openssl genrsa -out server.key 2048

    2.2 затем вводите команду для создания запроса на сертификат (csr):

    openssl req -new -key server.key -out server.csr

    2.3 Далее ответить на вопросы:

    Country Name (2 letter code) [AU]:

    State or Province Name (full name) [Some-State]:

    Locality Name (eg, city) []:

    Organization Name (eg, company) [Internet Widgits Pty Ltd]:

    Organizational Unit Name (eg, section) []:

    Common Name (eg, YOUR name) []:

    Please enter the following ‘extra’ attributes

    to be sent with your certificate request

    A challenge password []:

    An optional company name []:

    После этого в домашней директории (/home/login/) будут лежать файлы server.key и server.csr. необходимо взять файл server.csr и отдать его на подпись в организацию, выпускающую сертификаты, после его подписи, разместить на сервере.

    2.4 Самоподписанный сертификат генерируется так:

    openssl req -new -x509 -days 365 -key server.key -out server.crt

    Дополнительную информацию Вы можете посмотреть на страницу помощи по выпуску сертификатов:
    http://hosting.nic.ru/support/ssl_csr_file.shtml

    Предупреждение!
    Меню пользователя Павел Удовенко
    Посмотреть профиль
    Отправить личное сообщение для Павел Удовенко
    Найти ещё сообщения от Павел Удовенко

    для тех, у кого как и у меня возникли сложности с данным объяснением привожу вариант как делал это я:

    openssl genrsa -des3 -out название_ключа.key 1024

    Затем ответы на вопросы:
    Enter pass phrase for название_ключа.key: вводите свой пароль
    Verifying — Enter pass phrase for название_ключа.key: вводите свой пароль(повторно)

    затем команда:
    /usr/local/bin/openssl req -new -config /usr/local/openssl/openssl.cnf.sample -key название_ключа.key -out название_ключа.csr

    Enter pass phrase for название_ключа.key: вводите свой пароль указанный ранее для ключа

    Дальше отвечаем на вопросы сервера:

    Country Code: Двухбуквенный код страны, для России — RU

    State/Province: Лично я здесь ничего не поставил, просто нажал Enter

    City/Locality: Город/местоположение, в моем случае — Moscow

    Organization: Название организации, при чем, как я понял, Полное, т.е. Pupkin Ltd

    Organizational Unit: Отдел организации. Можно ничего не ставить или поставить что то типа Engineering или Human Resources

    Common name
    : Вот тут важно не перепутать! Здесь ставим название сайта, т.е. www.название_сайта.ru. Не ставить http:// или https://
    При этом вроде как (не проверял, но читал) если вы ставите www.название_сайта.ru, то и название_сайта.ru тоже попадает под сертификат.

    дальше вроде все понятно.

    14.11.2008, 18:35 #2
    Меню пользователя stffclb
    Посмотреть профиль
    Отправить личное сообщение для stffclb
    Найти ещё сообщения от stffclb
    15.11.2008, 00:40 #3
    Меню пользователя Павел Удовенко
    Посмотреть профиль
    Отправить личное сообщение для Павел Удовенко
    Найти ещё сообщения от Павел Удовенко
    18.11.2008, 14:07 #4
    Меню пользователя vanicon
    Посмотреть профиль
    Отправить личное сообщение для vanicon
    Найти ещё сообщения от vanicon
    18.11.2008, 14:22 #5
    Меню пользователя Максим Васильев
    Посмотреть профиль
    Отправить личное сообщение для Максим Васильев
    Найти ещё сообщения от Максим Васильев

    2. Сгенерировать файл:

    ]$ /usr/local/bin/openssl genrsa -out test.key 1024

    Enter pass phrase for Имя_Вашего_сайта.key:

    Здесь вводите Ваш приватный ключ.

    Verifying — Enter pass phrase for Имя_Вашего_сайта.key:

    24.11.2008, 16:05 #6
    Меню пользователя vlastelin_koda
    Посмотреть профиль
    Отправить личное сообщение для vlastelin_koda
    Найти ещё сообщения от vlastelin_koda

    и ещё вопросик. вот я сделал сертификат_наме.crt как его использовать? куда копировать?

    заранее благодарю за помощь!

    24.11.2008, 16:39 #7
    Меню пользователя vlastelin_koda
    Посмотреть профиль
    Отправить личное сообщение для vlastelin_koda
    Найти ещё сообщения от vlastelin_koda

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

    24.11.2008, 21:40 #8
    и ещё вопросик. вот я сделал сертификат_наме.crt как его использовать? куда копировать?

    заранее благодарю за помощь!

    Меню пользователя Павел Удовенко
    Посмотреть профиль
    Отправить личное сообщение для Павел Удовенко
    Найти ещё сообщения от Павел Удовенко

    и ещё вопрос, он конечно напримую с сертификатами не связан, но технология все же таже.

    допустим включил я на одном из своих сайтов name1.ru ssl, чтобы работать по защищенному протоколу https. А да другом, допустим name2.ru у меня не включен ssl и если на name2.ru набрать адрес вида: https://name2.ru то выполняется автоматический редирект на https://name1.ru.

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

    Коротко о главном

    Удостоверяющий центр (по-английски Certification authority, сокращённо CA) — это единый центр генерации цифровых сертификатов. У конечных клиентов (например, веб-браузеров) имеется база публичных ключей разных CA и они проверяют ими приходящие, например, от сайтов сертификаты. Нас интересуют сертификаты, используемые в сеансах, защищённых протоколом SSL/TLS.

    Собственно, всю процедуру можно разбить на такие шаги:

    1. генерим приватный ключ (сильно случайный набор байтов);
    2. генерим на основе приватного ключа пару сертификатов для CA (публичный и приватный);
    3. генерим пару сертификатов для домена, подписанных созданным на прошлом шаге CA.

    Создаём CA

    Для начала сгенерим приватный ключ (файл ca.key), если хотите зашифровать приватный ключ с паролем, добавьте аргумент -des3 :

    Теперь сгенерим пару сертификатов для нашего CA (вместо 365 можно подставить любое другое значение, это срок годности пары сертификатов в днях):

    Вводим пароль к ключу (если ключ был зашифрован) и затем аккуратно заполняем поля субъекта (subject). По этим данным можно будет потом идентифицировать публичный сертификат среди списка других, например. На выходе получаем файл ca.crt — это публичный сертификат нашего CA.

    Можно создать ключ и сертификат одной командой, причём в эту же команду можно включить параметры субъекта:

    К сожалению, эта команда генерит невалидный ключ. Openssl и основанные на этой библиотеке приложения его понимает корректно, однако другие программы могут его не принять. Решается это такой командой (мы просто считываем и снова записываем файл):

    Содержимое параметра -subj состоит из сегментов вида /$KEY=$VALUE , где $KEY может принимать такие значения:

    • L — locality, обычно это город
    • ST — state, обычно это регион, область, район и т.д.
    • C — country, двухбуквенный код страны, например, RU или US
    • O — organization, название организации
    • OU — organization unit, отдел в организации
    • CN — common name, обычно это адрес веб-сайта
    • emailAddress — email

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

    Итак, у нас есть некий домен (к примеру, example.com) и мы хотим выписать для него SSL-сертификат, подписанный только что созданным CA. Сертификат дальше использовать в браузере. Шаги примерно такие же, как и в случае создания CA:

    1. создаём новый приватный ключ (нужен новый приватный ключ, тот, нельзя использовать тот, который мы делали для CA);
    2. создаём Certificate signing request (CSR), который потом нужно отправить CA;
    3. со стороны CA генерим сертификат на основе Certificate signing request;
    4. устанавливаем полученный сертификат на сервер.

    Итак, генерим ключ (можете добавить -des3 , чтобы зашифровать ключ паролем):

    Приватный ключ хранится на стороне владельца сервера и не должен никогда никому отдаваться. На базе приватного ключа server.key генерится так называемый запрос на подпись сертификата (по-английски certificate signing request (csr)), в запросе заполняются параметры субъекта (имя, адрес, домены итп), затем этот файл отправляется CA и тот создаёт сертификат на основе данных из CSR, подписывает его своим приватным ключом, в результате получаем подписанный публичный сертификат.

    Вот простейший способ создать csr:

    В процессе работы нужно ответить на несколько вопросов (страна, город, имя домена итп), в результате получится csr-файл, который можно отправлять CA. Однако у такого способа есть несколько существенных недостатков — запрос данных идёт по заранее заданному шаблону, в который не входят некоторые важные поля, например, subjectAltName (это расширение для включения нескольких DNS-имён в сертификат).

    Единственный мне известный способ указать расширение subjectAltName — это воспользоваться собственным конфигом для openssl. Вот, например, таким:

    Сохраните его в файл openssl-csr.cnf и отредактируйте (нужно прописать в поле subjectAltName свои домены, если вы в конфиге openssl разбираетесь, то можно и другие опции изменить/добавить), после чего выполните вот такую команду:

    Полученный файл server.csr теперь нужно «отправить» CA, чтобы там его подписали. Поскольку CA наш собственный, то подписывать будем сами. И здесь тоже есть нюанс, связанный с X509v3-расширениями — команда создания сертификата по умолчанию не включает расширения, указанные в csr (то есть указанные в csr значения для subjectAltName в сертификат не попадут). Мы пойдём по самому простому пути — будем использовать тот же конфиг (openssl-csr.cnf), что и для генерации csr, из него нам понадобится только секция [ req_ext ] :

    В данном случае «срок годности» сертификата устанавливаем в один год (365 дней).

    Теперь у нас есть практически полный комплект всех нужных сертификатов. Иногда в сервере нужно использовать незашифрованный ключ, вот как его можно вытащить в файл server.key.insecure, если в server.key лежит зашифрованный ключ:

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

    Используем сертификаты

    Для начала полезные команды, позволяющие «посмотреть» сертификаты и csr:

    Основы OpenSSL: SSL-сертификаты, закрытые ключи и запросы на подпись

    OpenSSL – это многофункциональный инструмент командной строки, предназначенный для управления инфраструктурой открытых ключей (PKI) и HTTPS.


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

    Запросы на подпись сертификатов (CSR)

    Чтобы получить SSL-сертификат от центра сертификации (ЦС), нужно сначала создать запрос на подпись сертификата (CSR). CSR включает в себя открытый ключ и некоторые дополнительные данные. При подписи эти данные добавляются в сертификат.

    Чтобы сгенерировать запрос на подпись сертификата, нужно предоставить данные о сертификате. В частности важно правильно заполнить поле Common Name (CN) в разделе Distinguised Name, в котором нужно указать FQDN хоста, для которого предназначается сертификат. Чтобы обойти интерактивные подсказки, можно передать все запрашиваемые данные через командную строку.

    Другие поля в разделе Distinguised Name запрашивают данные об организации или компании. Если вы заказываете сертификат в ЦС, эти поля, как правило, нужно обязательно заполнить.

    Запрос на подпись сертификата имеет такой вид:


    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:New York
    Locality Name (eg, city) []:Brooklyn
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Brooklyn Company
    Organizational Unit Name (eg, section) []:Technology Division
    Common Name (e.g. server FQDN or YOUR name) []:examplebrooklyn.com
    Email Address []:

    Чтобы ответить на запросы CSR в неинтерактивном режиме, добавьте в команду опцию –subj, например:

    -subj «/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com»

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

    Генерирование запроса на подпись сертификата

    Генерирование закрытого ключа и запроса

    Этот метод позволяет вам подписать сертификат в ЦС и защитить веб-сервер Apache или Nginx с помощью HTTPS. Сгенерированный запрос на подпись можно отправить в ЦС, чтобы получить подписанный сертификат. Если ЦС поддерживает SHA-2, добавьте опцию -sha256.

    Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):

    openssl req \
    -newkey rsa:2048 -nodes -keyout domain.key \
    -out domain.csr

    Заполните поля в запросе на подпись.

    Опция -newkey rsa:2048 создаст 2048-битный RSA-ключ. Опция –nodes отключает пароль для закрытого ключа.

    Генерирование запроса для существующего закрытого ключа

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

    Следующая команда создаст запрос сертификата (domain.csr) для существующего ключа (domain.key):

    openssl req \
    -key domain.key \
    -new -out domain.csr

    Ответьте на запросы программы, чтобы продолжить. Опция –new указывает, что запрос нужно сгенерировать.

    Генерирование запроса для существующего сертификата и ключа

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

    Следующая команда создаст запрос (domain.csr) на основе существующего сертификата (domain.crt) и закрытого ключа (domain.key):

    openssl x509 \
    -in domain.crt \
    -signkey domain.key \
    -x509toreq -out domain.csr

    Опция -x509toreq создаст сертификат X509.

    Генерирование SSL-сертификата

    Если вы хотите защитить свой сервис, но не хотите подписывать его в ЦС, вы можете создать и подписать сертификат самостоятельно.

    Такие сертификаты называются самоподписанными.

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

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

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

    Этот метод позволяет защитить веб-сервер Apache или Nginx с помощью HTTPS.

    Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):

    openssl req \
    -newkey rsa:2048 -nodes -keyout domain.key \
    -x509 -days 365 -out domain.crt

    Заполните запрос на подпись.

    Опция -x509 создаёт самоподписанный сертификат. Опция -days 365 задаёт срок действия сертификата в днях.

    Создание сертификата для существующего закрытого ключа

    Если у вас уже есть закрытый ключ, но нет сертификата, вы можете сгенерировать сертификат для этого ключа.

    Следующая команда создаст сертификат (domain.csr) для существующего ключа (domain.key):

    openssl req \
    -key domain.key \
    -new \
    -x509 -days 365 -out domain.crt

    Ответьте на запросы программы, чтобы продолжить.

    • Опция -x509 создаёт самоподписанный сертификат. Опция -days 365 задаёт срок действия сертификата в днях.
    • Опция –new запускает запрос данных для создания CSR.

    Генерирование запроса для существующего сертификата и ключа

    Этот метод позволяет создать сертификат, если у вас уже есть закрытый ключ и запрос на подпись сертификата.

    Следующая команда создаст сертификат (domain.crt) на основе существующего запроса (domain.csr) и закрытого ключа (domain.key):

    openssl x509 \
    -signkey domain.key \
    -in domain.csr \
    -req -days 365 -out domain.crt

    Опция -days 365 задаёт срок действия сертификата в днях.

    Просмотр сертификатов

    Файлы сертификатов и запросов на подпись закодированы в формате PEM, который не может быть прочитан человеком.

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

    Просмотр CSR

    Эта команда позволяет просмотреть содержимое файла запроса на подпись сертификата в виде простого текста:

    openssl req -text -noout -verify -in domain.csr

    Просмотр сертификата

    Следующая команда позволяет просмотреть содержимое сертификата в виде простого текста:

    openssl x509 -text -noout -in domain.crt

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

    Чтобы убедиться, что сертификат был подписан в ЦС, введите:

    openssl verify -verbose -CAFile ca.crt domain.crt

    Закрытые ключи

    Создание закрытого ключа

    Чтобы создать закрытый 2048-битный ключ, защищённый паролем, введите:

    openssl genrsa -des3 -out domain.key 2048

    По запросу введите пароль, чтобы продолжить.

    Проверка закрытого ключа

    Эта команда подтвердит валидность закрытого ключа:

    openssl rsa -check -in domain.key

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

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

    Эта команда позволяет узнать, относится ли закрытый ключ (domain.key) к тому или иному сертификату (domain.crt) и запросу (domain.csr):

    openssl rsa -noout -modulus -in domain.key | openssl md5
    openssl x509 -noout -modulus -in domain.crt | openssl md5
    openssl req -noout -modulus -in domain.csr | openssl md5

    Если команды вернули одинаковый вывод, то, скорее всего, этот ключ, запрос и сертификат связаны.

    Шифрование закрытого ключа

    Следующая команда возьмёт незашифрованный ключ (unencrypted.key) и зашифрует его (encrypted.key):

    openssl rsa -des3 \
    -in unencrypted.key \
    -out encrypted.key

    Введите пароль, чтобы зашифровать ключ.

    Дешифровка закрытого ключа

    Эта команда может расшифровать зашифрованный ключ:

    openssl rsa \
    -in encrypted.key \
    -out decrypted.key
    Enter the pass phrase for the encrypted

    Введите пароль, чтобы расшифровать ключ.

    Форматы сертификатов

    До этого в руководстве рассматривались только сертификаты X.509 с кодированием ASCII PEM. Однако существует множество других форматов. Некоторые форматы позволяют объединить компоненты – ключ, запрос, сертификат – в один файл.

    Конвертация PEM в DER

    Чтобы конвертировать PEM в DER, используйте такую команду:

    openssl x509 \
    -in domain.crt \
    -outform der -out domain.der

    Формат DER обычно использует Java.

    Конвертация DER в PEM

    Для этого введите:

    openssl x509 \
    -inform der -in domain.der \
    -out domain.crt

    Конвертация PEM в PKCS7

    Чтобы добавить сертификаты PEM (domain.crt и ca-chain.crt) в файл PKCS7 (domain.p7b), введите:

    openssl crl2pkcs7 -nocrl \
    -certfile domain.crt \
    -certfile ca-chain.crt \
    -out domain.p7b

    Файлы PKCS7 (также известные как P7B) часто используются в Java Keystores и Microsoft IIS (Windows).

    Конвертация to PKCS7 в PEM

    Чтобы конвертировать PKCS7 в PEM, введите:

    openssl pkcs7 \
    -in domain.p7b \
    -print_certs -out domain.crt

    Обратите внимание: файл PKCS7 содержит много компонентов, а именно сертификат и промежуточный сертификат ЦС.

    Конвертация PEM в PKCS12


    Следующая команда позволяет объединить закрытый ключ и сертификат в файл PKCS12.

    openssl pkcs12 \
    -inkey domain.key \
    -in domain.crt \
    -export -out domain.pfx

    Программа запросит пароль. Файл PKCS12 позволяет объединить несколько сертификатов в один PEM-файл (domain.crt).

    Файлы PKCS12 (или PFX) обычно используются для перемещения наборов сертификатов в Micrsoft IIS (Windows).

    Конвертация PKCS12 в PEM

    Чтобы конвертировать файл PKCS12 в формат PEM, введите:

    openssl pkcs12 \
    -in domain.pfx \
    -nodes -out domain.combined.crt

    Если в файле PKCS12 было несколько объектов (например, ключ и сертификат), все они переместятся в файл PEM.

    Версии OpenSSL

    Чтобы проверить версию OpenSSL, используйте команду openssl version.

    Следующая команда выведет версию OpenSSL и все параметры, с которыми она была скомпилирована.

    openssl version -a

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

    OpenSSL 1.0.1f 6 Jan 2014
    built on: Mon Apr 7 21:22:23 UTC 2014
    platform: debian-amd64
    options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
    compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector —param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,—noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
    OPENSSLDIR: «/usr/lib/ssl»

    Теперь вы знакомы с основными методами и командами OpenSSL.

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

    Скорее всего, вы уже знакомы с OpenSSL как с библиотекой, которая дает возможность работать по протоколу SSL. Помимо библиотеки в составе OpenSSL идет полезная утилита для работы с командной строкой, которая используется при администрировании SSL/PKI. Сам этот инструмент плохо задокументирован, и цель данной статьи — немного рассказать о полезных советах и трюках по работе с OpenSSL в виде «поваренной книги».

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

    Скорее всего, вы уже знакомы с OpenSSL как с библиотекой, которая дает возможность работать по протоколу SSL. Помимо библиотеки в составе OpenSSL идет полезная утилита для работы с командной строкой, которая используется при администрировании SSL/PKI. Сам этот инструмент плохо задокументирован, и цель данной статьи — немного рассказать о полезных советах и трюках по работе с OpenSSL в виде «поваренной книги».

    Получение справки о подкомандах 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:

    $ openssl asn1parse -in mysterious_file.pem

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

    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

    В большинстве случаев команда openssl asn1parse -in file будет работать корректно с любыми файлами, имеющими отношение к SSL/PKI, однако иногда может возникать следующая ошибка:

    $ openssl asn1parse -in request.der
    Error: offset too large

    Скорее всего, это означает, что вы имеете дело с файлом, закодированным в формате DER, а не в формате PEM. В чем же различие? Формат DER – «необработанное представление», используемое SSL для корректной обработки сертификата. Именно в этом формате сертификат передается от сервера к клиенту для аутентификации. Как вы, возможно, уже знаете о том, что бинарные файлы и электронные сообщения не смешиваются, так как файлы обычно (но не всегда) кодируются в Base64 после чего прикрепляются к сообщению. Представление сертификата (или запроса на подпись), закодированного по стандарту DER, в виде Base64 называется (немного нелогично) Privacy Enhanced Mail или PEM-формат. В целом соглашение об именах гласит о том, чтобы «необработанным» (raw) файлам сертификатов назначалось расширение .der, а файлам закодированным в Base64 – расширение .pem.

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

    Предполагается, что любой объект, с которым взаимодействует OpenSSL, закодирован в Base64 и, следовательно, перед обработкой происходит его декодирование. Если необходимо обойти этот шаг, укажите параметр -inform der:

    $ openssl asn1parse -inform der -in request.der
    0:d=0 hl=4 l= 342 cons: SEQUENCE
    4:d=1 hl=4 l= 256 cons: SEQUENCE
    8:d=2 hl=2 l= 1 prim: INTEGER :00
    .

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

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

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

    Для получения этой информации в OpenSSL предусмотрена подкоманда x509. Однако если использовать команду $ openssl x509 -in sample.cer, результат будет примерно таким:

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

    По сути, вышеуказанная команда вывела текстовое содержимое сертификата, так же как если бы вы использовали команду: $ cat sample.cer

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

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

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

    $ openssl x509 -in sample.cer -noout -text
    Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    af:69:46:11:10:bd:82:88
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, ST=Texas, L=Plano, O=2xoffice, OU=Architecture, CN=Joshua Davies/emailAddress=joshua.davies.tx@gmail.com
    Validity
    Not Before: May 21 21:49:10 2014 GMT
    Not After : Jun 20 21:49:10 2014 GMT
    Subject: C=US, ST=Texas, L=Plano, O=2xoffice, OU=Architecture, CN=Joshua Davies/emailAddress=joshua.davies.tx@gmail.com
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (512 bit)
    Modulus (512 bit):
    00:b7:38:0d:e0:ab:37:18:a7:26:95:9d:9e:6f:a2:
    69:b1:b9:ee:b3:7f:29:04:fb:f0:94:b3:d0:d5:55:
    c0:d8:6b:14:7f:94:13:3c:d9:a2:61:bf:ba:3f:0a:
    44:37:dc:18:b5:23:c7:ee:96:2d:7c:d8:92:04:48:
    74:f8:c6:46:a5
    Exponent: 65537 (0x10001)
    X509v3 extensions:
    X509v3 Subject Key Identifier:
    1A:A5:C9:C8:36:EA:7D:FA:B4:DF:A4:9C:11:F9:C1:BE:78:C4:42:DD
    X509v3 Authority Key Identifier:
    keyid:1A:A5:C9:C8:36:EA:7D:FA:B4:DF:A4:9C:11:F9:C1:BE:78:C4:42:DD
    DirName:/C=US/ST=Texas/L=Plano/O=2xoffice/OU=Architecture/CN=Joshua Davies/emailAddress=joshua.davies.tx@gmail.com
    serial:AF:69:46:11:10:BD:82:88

    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

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

    При использовании сертификатов в реальной инфраструктуре, они должны быть подписаны и проверены корневым центром сертификации (например, Verisign или Thawte). Однако подобные сертификаты довольно дороги и, к тому же, для их получения требуется потратить много времени. Для тестирования вполне достаточно «поддельного» или самоподписанного сертификата, в котором определяется публичный ключ, и он же используется для создания подписи. Для создания подобных сертификатов в OpenSSL предусмотрена подкоманда req, которая используется вместе с параметром -x509.

    $ openssl req -x509 -newkey rsa:2048
    Generating a 512 bit RSA private key
    . ++++++++++++
    . ++++++++++++
    writing new private key to ‘privkey.pem’
    Enter PEM pass phrase:
    Verifying — Enter PEM pass phrase:
    .

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

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

    $ openssl req -x509 -newkey rsa:2048 -out selfsign.cer

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

    $ openssl req -x509 -newkey rsa:2048 -out selfsign.cer -keyout selfsign.key

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

    $ openssl req -x509 -newkey rsa:2048 -out server.crt -keyout server.key

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

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

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

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

    Даже если пользователь кликнет на «Proceed Anyway», вебсайт в некоторых браузерах может отображаться некорректно (к примеру, Chrome не загрузит картинки у сайта с недостоверным сертификатом, если страница загружена по протоколу HTTPS). Вы не сможете сами создать «настоящий» сертификат, поскольку он должен быть подписан «настоящим» центром сертификации. Перед отправкой в центр необходимо создать запрос на подпись сертификата (certificate signing request, CSR). CSR содержит всю информацию (включая публичный ключ и домен сайта) за исключением подписи. Такой запрос можно создать в точности так же, как мы создавали ранее самоподписанный сертификат, но без параметра -x509:

    $ openssl req -newkey rsa:2048 -out selfsign.cer -keyout selfsign.key

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

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

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

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

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

    «Первоначальной цель утилиты ca — продемонстрировать на примере, как происходит подпись запроса в центре сертификации, и не предполагается ее использование в реальной жизни. Тем не менее, некоторые пользователи используют утилиту ca для подписи запросов»

    Для нечастого использования – средства 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, можно подписать запрос при помощи следующей команды:

    openssl ca -config ca.cnf -in csr.pem -out certificate.pem

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

    Если вы посмотрите на содержимое сгенерированного сертификата, то увидите текстовое описание (в точности такое же, какое сгенерировала бы команда openssl x509 -noout –text). Этот раздел, включаемый по умолчанию, создает проблемы в некоторых системах. Чтобы текстовое описание не добавлялось, используйте параметр –notext или же просто удалите его вручную.

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

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

    2. [ ca ]
    3. default_ca = miniCA
    4.
    5. [ miniCA ]
    6. certificate = ./cacert.pem
    7. database = ./index.txt
    8. private_key = ./cakey.pem
    9. new_certs_dir = ./certs
    10. default_md = sha1
    11. policy = policy_match
    12. serial = ./serial
    13. default_days = 365
    14.
    15. [policy_match]
    16. commonName = supplied
    17. Создаем структуру директорий:
    18. $ mkdir certs
    19. $ touch index.txt
    20. $ echo «01» | serial
    21. Создаем корневой сертификат
    22. $ openssl req -x509 -newkey rsa:2048 -out cacert.pem -keyout cakey.pem
    23. Generating a 2048 bit RSA private key
    24. . +++
    25. . +++
    26. writing new private key to ‘cakey.pem’
    27. Enter PEM pass phrase:
    28. Verifying — Enter PEM pass phrase:
    29. ——
    30. You are about to be asked to enter information that will be incorporated
    31. into your certificate request.
    32. What you are about to enter is what is called a Distinguished Name or a DN.
    33. There are quite a few fields but you can leave some blank
    34. For some fields there will be a default value,
    35. If you enter ‘.’, the field will be left blank.
    36. ——
    37. Country Name (2 letter code) [AU]:US
    38. State or Province Name (full name) [Some-State]:Texas
    39. Locality Name (eg, city) []:Plano
    40. Organization Name (eg, company) [Internet Widgits Pty Ltd]:2xoffice
    41. Organizational Unit Name (eg, section) []:Architecture
    42. Common Name (e.g. server FQDN or YOUR name) []:Certificate Authority
    43. Email Address []:joshua.davies.tx@gmail.com

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

    $ chmod 400 cakey.pem

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

    1. Создайте запрос на подписание сертификата
    2. $ openssl req -newkey rsa:2048 -out csr.pem -keyout privkey.pem
    3. Подпишите запрос. Перед этим вы, возможно, захотите обратить внимание на содержимое директории с сертификатами для того, чтобы понимать механику процесса подписания сертификата.
    4. $ ls
    5. ca.cnf certs index.txt serial
    6. cacert.pem cakey.pem

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

    $ openssl ca -config ca.cnf -in csr.pem -out signed.pem
    Using configuration from ca.cnf
    Enter pass phrase for ./cakey.pem:
    Check that the request matches the signature
    Signature ok
    The Subject’s Distinguished Name is as follows
    countryName :PRINTABLE:’US’
    stateOrProvinceName :PRINTABLE:’Texas’
    localityName :PRINTABLE:’Plano’
    organizationName :PRINTABLE:’2xoffice’
    organizationalUnitName:PRINTABLE:’Architecture’
    commonName :PRINTABLE:’Joshua Davies’
    emailAddress :IA5STRING:’joshua.davies.tx@gmail.com’
    Certificate is to be certified until May 29 14:54:35 2015 GMT (365 days)
    Sign the certificate? [y/n]:y

    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 у подписанного сертификата:

    $ openssl x509 -in signed.pem -noout -subject
    subject= /CN=Joshua Davies

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

    $ openssl req -in csr.pem -noout -subjec
    subject=/C=US/ST=Texas/L=Plano/O=2xoffice/OU=Architecture/CN=Joshua Davies/emailAddress=joshua.davies.tx@gmail.com

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

    countryName = optional
    stateOrProvinceName = optional

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

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

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

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

    $ openssl ca -in csr.pem -startdate 140529000000Z

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

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

    if [$# -ne 1]
    then
    echo «Usage: $0 »
    exit
    fi

    openssl req -subj /C=US/ST=Texas/L=Plano/O=2xoffice/OU=Architecture/CN=$1

    Илон Маск рекомендует:  Что такое код ingres_field_nullable
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    25.11.2008, 17:47 #9