Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.
Предупреждение!
Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.
Эта функция — ЭКСПЕРИМЕНТАЛЬНАЯ. Поведение, имя и всё остальное, что задокументировано для данной функции может быть изменено в будущих релизах РНР без предупреждения. Вы можете использовать эту функцию только на свой страх и риск.
Предупреждение!
Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.
1.2.1. Создание запроса на сертификат с помощью OpenSSL
Не важно, UNIX у вас или Windows: если вы решили создавать CSR с помощью программы openssl — все действия будут одинаковые, отличаться могут разве только пути к файлам.
Если предполагается, что сертификат должен быть правильным для нескольких доменных имен, то предварительно нужно обеспечить возможность передать openssl дополнительные доменные имена (основное будет запрошено). К сожалению, в openssl нет никакого механизма, чтобы SAN (Subject Alternate Names — альтернативные имена субъекта) можно было запрашивать с консоли. Поэтому, чтобы иметь возможность создавать запросы на сертификаты как с дополнительными именами, так и без них, в файле /etc/ssl/openssl.cnf на том компьютере, на котором создается CSR, следует сделать небольшие добавления, а именно заменить в секции [v3_req] строку subjectAltName, наложив следующий патч (именно этот патч накладывает скрипт keyreq):
Ну и, разумеется, для задания содержимого SAN можно использовать все способы, описанные в разделе 1.1.3.
Программа openssl имеет столько различных параметров и режимов работы, что даже описывается не в одной man-странице, а каждому ее режиму работы посвящена отдельная страница. В данном случае мы пользуемся режимом req — режимом генерации запросов на сертификацию. Полная командная строка генерации нового CSR при наличии SAN выглядит так:
Вся приводимые команды — это одна строка, без конвейеров и перенаправлений! Запускается команда 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:
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.
Некоторые аббревиатуры, относящиеся к сертификатам:
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 , в этом поможет приведенная выше команда.
Я часто использую эту команду для проверки 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, где должно быть указанно ваше доменное имя, для которого вы собираетесь использовать сертификат, также можно указать дополнительную информацию о вашей компании, адресе и организации, но это уже необязательно.
Чтобы создать закрытый ключ и запрос на подпись открытого ключа выполните такую команду:
Опция -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 запрос из уже существующего сертификата и закрытого ключа, тогда вам не придется вводить информацию, она будет получена из сертификата:
Параметр -x509toreq указывает, что нужно использовать сертификат для X509 для получения CSR. X509, это сертификаты, подписанные сами собой. Обычно сертификат подписывается другим сертификатом, а этот был подписан сам собой. Если вы получили сертификат от CA, то этот параметр не нужен.
Подпись сертификатов OpenSSL
Допустим, у вас есть приватный ключ и запрос на подпись, фактически, открытый ключ. Теперь вам нужно его подписать чтобы получить сертификат, который можно использовать. Тут есть несколько вариантов. Можно отправить csr файл на подпись какому-либо центру сертификации, например, LetsEncrypt. Можно подписать сертификат тем же ключом, с помощью которого он был создан, и третий вариант — создать свой центр сертификации.
Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:
С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:
Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL — подписать его с помощью собственного CA, центра сертификации.
Вот вы сейчас думаете что это что-то такое сложное, да? А нет, это обычная папка, в которой лежит защищенный паролем закрытый ключ, с помощью которого мы будем подписывать все другие ключи. А открытая пара этого ключа должна быть добавлена во все браузеры, которые будут ему доверять.
Вообще, центр сертификации в крупных корпорациях находится на отдельных компьютерах, которые даже к сети не подключены. Но для примера мы разместим папку в нашей файловой системе /etc/:
Дальше нужно создать самоподписанный сертификат openssl для нашего CA:
Параметр -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, какие бывают сертификаты, ключи и как все эти понятия связаны между собой. Это очень сложная и обширная тема, и недостаточно одной статьи чтобы все охватить, но, надеюсь, что теперь вам намного понятнее как это все работает.
Генерация 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 выполните следующие операции:
Откройте командную строку (терминал) вашего Linux/MacOS компьютера или подключитесь к Linux-серверу по SSH.
Перейдите в директорию, в которую будут сохранены сгенерированные ключи. Например, для выбора директории /home/root, выполните: cd /home/root
Примечание: при работе с 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.
Открыть файл CSR-запроса можно командой: Debian/Ubuntu: nano home/root/CSR.csr CentOS: а) Установите редактор nano (если он еще не установлен): yum install nano б) Отройте файл CSR-запроса: nano home/root/CSR.csr Примечение: Если вы указали другую папку для сохранения ключей, укажите этот путь в команде выше.
Содержимое файла следует полностью скопировать в окно запроса 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 и отдать его на подпись в организацию, выпускающую сертификаты, после его подписи, разместить на сервере.
Дополнительную информацию Вы можете посмотреть на страницу помощи по выпуску сертификатов: http://hosting.nic.ru/support/ssl_csr_file.shtml
Меню пользователя Павел Удовенко
Посмотреть профиль
Отправить личное сообщение для Павел Удовенко
Найти ещё сообщения от Павел Удовенко
14.11.2008, 18:35
#2
для тех, у кого как и у меня возникли сложности с данным объяснением привожу вариант как делал это я: openssl genrsa -des3 -out название_ключа.key 1024
Затем ответы на вопросы: Enter pass phrase for название_ключа.key: вводите свой пароль Verifying — Enter pass phrase for название_ключа.key: вводите свой пароль(повторно)
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 тоже попадает под сертификат.
Verifying — Enter pass phrase for Имя_Вашего_сайта.key:
Меню пользователя vlastelin_koda
Посмотреть профиль
Отправить личное сообщение для vlastelin_koda
Найти ещё сообщения от vlastelin_koda
24.11.2008, 16:39
#7
и ещё вопросик. вот я сделал сертификат_наме.crt как его использовать? куда копировать?
заранее благодарю за помощь!
Меню пользователя vlastelin_koda
Посмотреть профиль
Отправить личное сообщение для vlastelin_koda
Найти ещё сообщения от vlastelin_koda
24.11.2008, 21:40
#8
При применении данной инструкции при перезапуске Apache нет необходимости вводить вручную пароль, что Вам будет очень мешать, если Вы его сделаете.
и ещё вопросик. вот я сделал сертификат_наме.crt как его использовать? куда копировать?
заранее благодарю за помощь!
Меню пользователя Павел Удовенко
Посмотреть профиль
Отправить личное сообщение для Павел Удовенко
Найти ещё сообщения от Павел Удовенко
25.11.2008, 17:47
#9
и ещё вопрос, он конечно напримую с сертификатами не связан, но технология все же таже.
допустим включил я на одном из своих сайтов name1.ru ssl, чтобы работать по защищенному протоколу https. А да другом, допустим name2.ru у меня не включен ssl и если на name2.ru набрать адрес вида: https://name2.ru то выполняется автоматический редирект на https://name1.ru.
Не подскажете выход из этой ситуации? а то мало ли пользователь возьмет и сам наберет этот протокол, что не желательно.
Коротко о главном
Удостоверяющий центр (по-английски Certification authority, сокращённо CA) — это единый центр генерации цифровых сертификатов. У конечных клиентов (например, веб-браузеров) имеется база публичных ключей разных CA и они проверяют ими приходящие, например, от сайтов сертификаты. Нас интересуют сертификаты, используемые в сеансах, защищённых протоколом SSL/TLS.
Собственно, всю процедуру можно разбить на такие шаги:
генерим приватный ключ (сильно случайный набор байтов);
генерим на основе приватного ключа пару сертификатов для CA (публичный и приватный);
генерим пару сертификатов для домена, подписанных созданным на прошлом шаге 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:
создаём новый приватный ключ (нужен новый приватный ключ, тот, нельзя использовать тот, который мы делали для CA);
создаём Certificate signing request (CSR), который потом нужно отправить CA;
со стороны CA генерим сертификат на основе Certificate signing request;
Приватный ключ хранится на стороне владельца сервера и не должен никогда никому отдаваться. На базе приватного ключа 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, например:
Ознакомившись с запросами на подпись сертификата, вы можете перейти к любому другому разделу руководства.
Генерирование запроса на подпись сертификата
Генерирование закрытого ключа и запроса
Этот метод позволяет вам подписать сертификат в ЦС и защитить веб-сервер Apache или Nginx с помощью HTTPS. Сгенерированный запрос на подпись можно отправить в ЦС, чтобы получить подписанный сертификат. Если ЦС поддерживает SHA-2, добавьте опцию -sha256.
Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):
Если вы хотите защитить свой сервис, но не хотите подписывать его в ЦС, вы можете создать и подписать сертификат самостоятельно.
Такие сертификаты называются самоподписанными.
По сути, самоподписанный сертификат – это сертификат, подписанный своим собственным закрытым ключом. Такие сертификаты тоже шифруют соединения, однако они не подтверждают подлинности сайта, потому пользователи, которые открывают сайт, увидят предупреждение.
Если вам ненужно подтверждать подлинность сайта, вы можете спокойно использовать самоподписанные сертификаты.
Генерирование самоподписанного сертификата
Этот метод позволяет защитить веб-сервер Apache или Nginx с помощью HTTPS.
Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):
Эта команда может расшифровать зашифрованный ключ:
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.
Советы и трюки по работе с 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) может помочь в поиске проблемы. Однако если открыть файл сертификата, скажем, в текстовом редакторе, то можно увидеть нечто подобное:
Файл закодирован по схеме Base64, но раскодировка не даст сколь-нибудь полезных результатов, поскольку в Base64 закодировано представление по стандарту DER (Distinguished Encoding Rule). Чтобы получить нечто более осмысленное, необходимо воспользоваться подкомандой asn1parse:
Если вы немного знакомы с концепцией 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:
Если и в этом случае возникает ошибка «offset too large», значит, файл либо не имеет отношение к сертификату, либо произошло его повреждение во время передачи.
Просмотр содержимого сертификата
Допустим, вы имеете дело с настоящим сертификатом стандарта X.509. Подпрограмма asn1parse во всех деталях расскажет о файле сертификата ( возможно, даже больше, чем вы ожидали). Вам же нужно узнать лишь срок действия и имя.
Для получения этой информации в OpenSSL предусмотрена подкоманда x509. Однако если использовать команду $ openssl x509 -in sample.cer, результат будет примерно таким:
По сути, вышеуказанная команда вывела текстовое содержимое сертификата, так же как если бы вы использовали команду: $ 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
При использовании сертификатов в реальной инфраструктуре, они должны быть подписаны и проверены корневым центром сертификации (например, 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.
По умолчанию секретный ключ записывается в файл privkey.pem (если уже существует файл с таким именем, то он перезаписывается без предупреждения!). Чтобы избежать возможных проблем, старайтесь определять самостоятельно файл для секретного ключа:
Если вы хотите подцепить SSL на сервере Apache2 (только для тестирования!), раскомментируйте строку #Include /private/etc/apache2/extra/httpd-ssl.conf в файле /etc/apache2/httpd.conf и запустите следующую команду:
При этом вам будет предложено ввести некоторые параметры сертификата, но главное – в параметре Common Name следует указать «localhost».
Создание запроса для загрузки сертификата в центр сертификации
Естественно после тестирования вам потребуется настоящий сертификат. Если, к примеру, установить самоподписанный сертификат на сервер, в браузере пользователя появится следующее сообщение:
Рисунок 1: Сообщение с предупреждением о недостоверном сертификате, которое выводится в браузере Chrome
Даже если пользователь кликнет на «Proceed Anyway», вебсайт в некоторых браузерах может отображаться некорректно (к примеру, Chrome не загрузит картинки у сайта с недостоверным сертификатом, если страница загружена по протоколу HTTPS). Вы не сможете сами создать «настоящий» сертификат, поскольку он должен быть подписан «настоящим» центром сертификации. Перед отправкой в центр необходимо создать запрос на подпись сертификата (certificate signing request, CSR). CSR содержит всю информацию (включая публичный ключ и домен сайта) за исключением подписи. Такой запрос можно создать в точности так же, как мы создавали ранее самоподписанный сертификат, но без параметра -x509:
Вышеуказанная команда создает файл PKCS #10 (или запрос на подпись сертификата), который нужно загрузить в центр сертификации. Процедура получения достоверного сертификата варьируется от центра к центру, но в целом, вначале, вам нужно загрузить CSR-файл через вебформу. По завершению всех необходимых проверок, сертификат будет готов к работе. Обратите внимание, что сертификат не содержит секретный ключ (если вы еще не успели забыть, то он генерируется в отдельный файл). По сути, это часть публичной информации, которую ваш сервер будет отсылать каждому клиенту, пытающемуся подключиться по протоколу HTTPS.
Помните, когда я говорил о том, что могут возникнуть проблемы при перезаписи файла секретного ключа? Так вот, представьте себе ситуацию, когда CSR загружен в центр сертификации, а потом, нечаянно, перезаписан файл секретного ключа. Не забывайте, что секретный ключ не подлежит восстановлению (иначе инфраструктура, а которой базируется SSL, была бы уязвима). Если же ключ утерян, сгенерированный сертификат становится бесполезен (необходимо делать регулярные резервные копии подобных файлов).
Подписание запроса на создание сертификата
При помощи OpenSSL можно создать свой собственный центр сертификации и не прибегать к услугам коммерческих центров и тем самым сэкономить немного денег.
В документации утверждается, что средства по созданию своего собственного центра сертификации были разработаны лишь в демонстрационных целях. Их никогда не планировалось использовать для работы в боевых условиях. Выдержка из документации:
«Первоначальной цель утилиты ca — продемонстрировать на примере, как происходит подпись запроса в центре сертификации, и не предполагается ее использование в реальной жизни. Тем не менее, некоторые пользователи используют утилиту ca для подписи запросов»
Для нечастого использования – средства OpenSSL вполне подходят, однако если вы хотите создать что-то более масштабное, необходимо развернуть серьезную инфраструктуру по управлению сертификатами.
Во-первых, как было показано выше, необходимо создать самоподписанный корневой сертификат. После этого создайте конфигурационный файл. В OpenSSL есть пример файла openssl.cnf, который находится в соответствующей папке (название директории может изменяться от версии к версии). В большинстве случаев (и особенно при тестировании) можно использовать как раз этот файл без каких-либо изменений. Если же вы планируете более плотно поработать с сертификатами, следует поподробнее ознакомиться с содержимым файла конфигурации. В нем есть несколько полезных параметров, например, местонахождение серийных номеров и списка отозванных сертификатов (Certificate Revocation List). Я не будут рассказывать обо всех опциях (если по-честному, с некоторыми из них я не сильно знаком). В большинстве случаев вы можете воспользоваться настройками по умолчанию.
Однако некоторые записи из раздела [ CA_default ] ссылаются на директории и файлы, которые, в случае их отсутствия, могут привести к проблемам при развертывании центра сертификации, и вы должны создать все необходимые файлы и папки перед тем, как подписывать CSR. В составе OpenSSL идет простая утилита CA.pl, которая упрощает весь процесс (на самом деле просто создается структура директорий, на которые ссылается файл openssl.cnf). За создание папок отвечает следующая секция:
Этого вполне достаточно, чтобы развернуть простейший центр сертификации. В любой момент, в файле 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) будет размещен в конечных пунктах, где будут утверждаться подписанные сертификаты (к примеру, веб сервера, которые сконфигурированы для запроса клиентских сертификатов).
Подпишите запрос. Перед этим вы, возможно, захотите обратить внимание на содержимое директории с сертификатами для того, чтобы понимать механику процесса подписания сертификата.
$ ls
ca.cnf certs index.txt serial
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 у подписанного сертификата:
Причина в содержимом раздела [ policy ], который находится в конфигурационном файле. Там я указал, чтобы выводился только атрибут commonName. Если бы я заходил отобразить другие атрибуты, то указал бы их отдельно:
Важно отметить, что поле subject подписанного сертификата необязательно будет совпадать с полем subject у запроса. Идентичным является лишь публичный ключ.
В этой минимальной конфигурации нашего центра сертификации отсутствуют другие важные возможности. Например, я не добавил поддержку аннулирования сертификатов. В данном случае моей целью было продемонстрировать вам на наглядном примере, как происходит процесс подписи, а не показать стабильное рабочее решение готового центра сертификации.
Подписание сертификата с начальной прошлой датой
При работе с сертификатами я столкнулся с проблемой, связанной с часовыми поясами. По умолчанию при подписании сертификата используется часовой пояс сервера. Бывали случаи, когда сертификат, созданный в часовом поясе восточном побережья, не устанавливался на сервере, находящимся на западном. Конечно, проблема не столь критична, но слегка раздражает. В OpenSSL команда ca позволяет указать начальную дату задним числом:
$ openssl ca -in csr.pem -startdate 140529000000Z
Передача информации для поля subject через командную строку
Если у вас уже есть некоторый опыт по созданию тестовых сертификатов (или даже отправки запроса в центр сертификации), то, возможно, вы заметили, что немного раздражает постоянно указывать поля country, state, locality, и т. д. Вы можете передать эту информацию через командную строку при помощи следующего скрипта:
