Linux read pem certificate

Open SSL

Cryptography and SSL/TLS Toolkit


pem_password_cb, PEM_read_bio_PrivateKey, PEM_read_PrivateKey, PEM_write_bio_PrivateKey, PEM_write_bio_PrivateKey_traditional, PEM_write_PrivateKey, PEM_write_bio_PKCS8PrivateKey, PEM_write_PKCS8PrivateKey, PEM_write_bio_PKCS8PrivateKey_nid, PEM_write_PKCS8PrivateKey_nid, PEM_read_bio_PUBKEY, PEM_read_PUBKEY, PEM_write_bio_PUBKEY, PEM_write_PUBKEY, PEM_read_bio_RSAPrivateKey, PEM_read_RSAPrivateKey, PEM_write_bio_RSAPrivateKey, PEM_write_RSAPrivateKey, PEM_read_bio_RSAPublicKey, PEM_read_RSAPublicKey, PEM_write_bio_RSAPublicKey, PEM_write_RSAPublicKey, PEM_read_bio_RSA_PUBKEY, PEM_read_RSA_PUBKEY, PEM_write_bio_RSA_PUBKEY, PEM_write_RSA_PUBKEY, PEM_read_bio_DSAPrivateKey, PEM_read_DSAPrivateKey, PEM_write_bio_DSAPrivateKey, PEM_write_DSAPrivateKey, PEM_read_bio_DSA_PUBKEY, PEM_read_DSA_PUBKEY, PEM_write_bio_DSA_PUBKEY, PEM_write_DSA_PUBKEY, PEM_read_bio_Parameters, PEM_write_bio_Parameters, PEM_read_bio_DSAparams, PEM_read_DSAparams, PEM_write_bio_DSAparams, PEM_write_DSAparams, PEM_read_bio_DHparams, PEM_read_DHparams, PEM_write_bio_DHparams, PEM_write_DHparams, PEM_read_bio_X509, PEM_read_X509, PEM_write_bio_X509, PEM_write_X509, PEM_read_bio_X509_AUX, PEM_read_X509_AUX, PEM_write_bio_X509_AUX, PEM_write_X509_AUX, PEM_read_bio_X509_REQ, PEM_read_X509_REQ, PEM_write_bio_X509_REQ, PEM_write_X509_REQ, PEM_write_bio_X509_REQ_NEW, PEM_write_X509_REQ_NEW, PEM_read_bio_X509_CRL, PEM_read_X509_CRL, PEM_write_bio_X509_CRL, PEM_write_X509_CRL, PEM_read_bio_PKCS7, PEM_read_PKCS7, PEM_write_bio_PKCS7, PEM_write_PKCS7 — PEM routines



The PEM functions read or write structures in PEM format. In this sense PEM format is simply base64 encoded data surrounded by header lines.

For more details about the meaning of arguments see the PEM FUNCTION ARGUMENTS section.

Each operation has four functions associated with it. For brevity the term «TYPE functions» will be used below to collectively refer to the PEM_read_bio_TYPE(), PEM_read_TYPE(), PEM_write_bio_TYPE(), and PEM_write_TYPE() functions.

The PrivateKey functions read or write a private key in PEM format using an EVP_PKEY structure. The write routines use PKCS#8 private key format and are equivalent to PEM_write_bio_PKCS8PrivateKey().The read functions transparently handle traditional and PKCS#8 format encrypted and unencrypted keys.

PEM_write_bio_PrivateKey_traditional() writes out a private key in the «traditional» format with a simple private key marker and should only be used for compatibility with legacy programs.

PEM_write_bio_PKCS8PrivateKey() and PEM_write_PKCS8PrivateKey() write a private key in an EVP_PKEY structure in PKCS#8 EncryptedPrivateKeyInfo format using PKCS#5 v2.0 password based encryption algorithms. The cipher argument specifies the encryption algorithm to use: unlike some other PEM routines the encryption is applied at the PKCS#8 level and not in the PEM headers. If cipher is NULL then no encryption is used and a PKCS#8 PrivateKeyInfo structure is used instead.

PEM_write_bio_PKCS8PrivateKey_nid() and PEM_write_PKCS8PrivateKey_nid() also write out a private key as a PKCS#8 EncryptedPrivateKeyInfo however it uses PKCS#5 v1.5 or PKCS#12 encryption algorithms instead. The algorithm to use is specified in the nid parameter and should be the NID of the corresponding OBJECT IDENTIFIER (see NOTES section).

The PUBKEY functions process a public key using an EVP_PKEY structure. The public key is encoded as a SubjectPublicKeyInfo structure.

The RSAPrivateKey functions process an RSA private key using an RSA structure. The write routines uses traditional format. The read routines handles the same formats as the PrivateKey functions but an error occurs if the private key is not RSA.

The RSAPublicKey functions process an RSA public key using an RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey structure.

The RSA_PUBKEY functions also process an RSA public key using an RSA structure. However, the public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not RSA.

The DSAPrivateKey functions process a DSA private key using a DSA structure. The write routines uses traditional format. The read routines handles the same formats as the PrivateKey functions but an error occurs if the private key is not DSA.

The DSA_PUBKEY functions process a DSA public key using a DSA structure. The public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not DSA.

The Parameters functions read or write key parameters in PEM format using an EVP_PKEY structure. The encoding depends on the type of key; for DSA key parameters, it will be a Dss-Parms structure as defined in RFC2459, and for DH key parameters, it will be a PKCS#3 DHparameter structure. These functions only exist for the BIO type.

The DSAparams functions process DSA parameters using a DSA structure. The parameters are encoded using a Dss-Parms structure as defined in RFC2459.

The DHparams functions process DH parameters using a DH structure. The parameters are encoded using a PKCS#3 DHparameter structure.

The X509 functions process an X509 certificate using an X509 structure. They will also process a trusted X509 certificate but any trust settings are discarded.

The X509_AUX functions process a trusted X509 certificate using an X509 structure.

The X509_REQ and X509_REQ_NEW functions process a PKCS#10 certificate request using an X509_REQ structure. The X509_REQ write functions use CERTIFICATE REQUEST in the header whereas the X509_REQ_NEW functions use NEW CERTIFICATE REQUEST (as required by some CAs). The X509_REQ read functions will handle either form so there are no X509_REQ_NEW read functions.

The X509_CRL functions process an X509 CRL using an X509_CRL structure.

The PKCS7 functions process a PKCS#7 ContentInfo using a PKCS7 structure.


The PEM functions have many common arguments.

The bp BIO parameter (if present) specifies the BIO to read from or write to.

The fp FILE parameter (if present) specifies the FILE pointer to read from or write to.

The PEM read functions all take an argument TYPE **x and return a TYPE * pointer. Where TYPE is whatever structure the function uses. If x is NULL then the parameter is ignored. If x is not NULL but *x is NULL then the structure returned will be written to *x. If neither x nor *x is NULL then an attempt is made to reuse the structure at *x (but see BUGS and EXAMPLES sections). Irrespective of the value of x a pointer to the structure is always returned (or NULL if an error occurred).

Читайте также:  Заработок на создание тем для wordpress

The PEM functions which write private keys take an enc parameter which specifies the encryption algorithm to use, encryption is done at the PEM level. If this parameter is set to NULL then the private key is written in unencrypted form.

The cb argument is the callback to use when querying for the pass phrase used for encrypted PEM structures (normally only private keys).

For the PEM write routines if the kstr parameter is not NULL then klen bytes at kstr are used as the passphrase and cb is ignored.

If the cb parameters is set to NULL and the u parameter is not NULL then the u parameter is interpreted as a null terminated string to use as the passphrase. If both cb and u are NULL then the default callback routine is used which will typically prompt for the passphrase on the current terminal with echoing turned off.

The default passphrase callback is sometimes inappropriate (for example in a GUI application) so an alternative can be supplied. The callback routine has the following form:

buf is the buffer to write the passphrase to. size is the maximum length of the passphrase (i.e. the size of buf). rwflag is a flag which is set to 0 when reading and 1 when writing. A typical routine will ask the user to verify the passphrase (for example by prompting for it twice) if rwflag is 1. The u parameter has the same value as the u parameter passed to the PEM routine. It allows arbitrary data to be passed to the callback by the application (for example a window handle in a GUI application). The callback must return the number of characters in the passphrase or -1 if an error occurred.


The old PrivateKey write routines are retained for compatibility. New applications should write private keys using the PEM_write_bio_PKCS8PrivateKey() or PEM_write_PKCS8PrivateKey() routines because they are more secure (they use an iteration count of 2048 whereas the traditional routines use a count of 1) unless compatibility with older versions of OpenSSL is important.

The PrivateKey read routines can be used in all applications because they handle all formats transparently.

A frequent cause of problems is attempting to use the PEM routines like this:

this is a bug because an attempt will be made to reuse the data at x which is an uninitialised pointer.

These functions make no assumption regarding the pass phrase received from the password callback. It will simply be treated as a byte sequence.


These old PrivateKey routines use a non standard technique for encryption.

The private key (or other data) takes the following form:

The line beginning with Proc-Type contains the version and the protection on the encapsulated data. The line beginning DEK-Info contains two comma separated values: the encryption algorithm name as used by EVP_get_cipherbyname() and an initialization vector used by the cipher encoded as a set of hexadecimal digits. After those two lines is the base64-encoded encrypted data.

The encryption key is derived using EVP_BytesToKey(). The cipher’s initialization vector is passed to EVP_BytesToKey() as the salt parameter. Internally, PKCS5_SALT_LEN bytes of the salt are used (regardless of the size of the initialization vector). The user’s password is passed to EVP_BytesToKey() using the data and datal parameters. Finally, the library uses an iteration count of 1 for EVP_BytesToKey().

The key derived by EVP_BytesToKey() along with the original initialization vector is then used to decrypt the encrypted data. The iv produced by EVP_BytesToKey() is not utilized or needed, and NULL should be passed to the function.

The pseudo code to derive the key would look similar to:

The PEM read routines in some versions of OpenSSL will not correctly reuse an existing structure. Therefore, the following:

where x already contains a valid certificate, may not work, whereas:

is guaranteed to work.


The read routines return either a pointer to the structure read or NULL if an error occurred.

The write routines return 1 for success or 0 for failure.


Although the PEM routines take several arguments in almost all applications most of them are set to 0 or NULL.

Read a certificate in PEM format from a BIO:

Write a certificate to a BIO:

Write a private key (using traditional format) to a BIO using triple DES encryption, the pass phrase is prompted for:

Write a private key (using PKCS#8 format) to a BIO using triple DES encryption, using the pass phrase «hello»:

Read a private key from a BIO using a pass phrase callback:

Читайте также:  Аналоги картриджей hp 132

Skeleton pass phrase callback:



The old Netscape certificate sequences were no longer documented in OpenSSL 1.1.0; applications should use the PKCS7 standard instead as they will be formally deprecated in a future releases.

Copyright 2001-2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the OpenSSL license (the «License»). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at

1.1.1 manpages

This manpage

Please report problems with this website to webmaster at

Copyright © 1999-2021 The OpenSSL Project Authors. All Rights Reserved.


Как просмотреть содержимое ключей и сертификатов SSL

Просмотр содержимого ключей и сертификатов

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

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

  • rootCA.key — ключ CA
  • rootCA.crt — сертификат CA
  • — ключ сервера
  • — запрос за подпись сертификата сайта
  • — сертификат сайта

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.

Все эти файлы являются текстовыми:

Там мы увидим примерно следующее:

Если вам эти строки кажутся знакомыми на кодировку Base64, то вы совершенно правы — это она и есть. (Смотрите также «Как быстро узнать и преобразовать кодировку»).

Этот формат, называемый форматом PEM, расшифровывается как Privacy Enhanced Mail.

PEM — это текстовое представление реального двоичного ключа или сертификата в формате DER. Представляет собой двоичного формата DER в кодировке base64 и с дополнительными строками «——BEGIN PRIVATE KEY——», «——BEGIN CERTIFICATE——» и другими в начале файла и строками «——END PRIVATE KEY——», «——END CERTIFICATE——» в конце файла.

Мы можем хранить двоичную версию файла только с кодировкой DER, но наиболее распространенным способом является версия PEM.

Вы можете увидеть структуру приватного следующей командой:

Опция -in ИМЯ_ФАЙЛА указывает имя файла ввода для чтения ключа или стандартный ввод, если эта опция не указана. Если ключ зашифрован, будет запрошен пароль.

Опция -text печатает различные компоненты открытого или закрытого ключа в виде простого текста в дополнение к закодированной версии.

Любой формат ключа на самом деле является контейнером для набора длинных чисел. Все остальные данные можно считать «шумом».

Закрытый ключ содержит: модуль (modulus), частный показатель (privateExponent), открытый показатель (publicExponent), простое число 1 (prime1), простое число 2 (prime2), показатель степени 1 (exponent1), показатель степени 2 (exponent2) и коэффициент (coefficient).

Открытый ключ содержит только модуль (modulus) и открытый показатель (publicExponent).

Вы можете из влечь из файла ключей публичный ключ:

По умолчанию выводится закрытый ключ: с опцией -pubout вместо него будет выведен открытый ключ. Эта опция устанавливается автоматически, если ввод является открытым ключом.

Следующая команда покажет информацию о публичном ключе:

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

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

С такими же опциями, но уже используя команду req, можно изучить содержимое запроса на подпись сертификата:

При создании SSL сертификата мы создали две пары ключей (корневые и для домена), то есть это файлы rootCA.key и, но по своей технической сути они идентичны.

Что касается сертификатов, которых у нас тоже два (rootCA.crt и, то по своей природе они не являются одинаковыми: корневой сертификат является самоподписанным, а сертификат домена подписан приватным корневым ключом.

Информацию о содержимом сертификатов можно посмотреть командой x509 (остальные опции нам уже знакомы):

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

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

Вы увидите сертификаты (один или несколько), найдите по полю CN тот, который вас интересует, например, сертификат домена

И скопируйте содержимое начиная с ——BEGIN CERTIFICATE—— и заканчивая ——END CERTIFICATE——. Затем сохраните это в файл.

Вы также можете сохранить сертификат центра сертификации и изучить его:

К примеру, сертификат сайта я сохранил в файл, для просмотра информации о нём:

Issuer указывает на организацию, которая выдала (подписала) сертификат:

Validity — срок действия сертификата:

Subject: CN — домен (IP адрес) для которого предназначен сертификат:

Поддомены в группе X509v3 extensions → X509v3 Subject Alternative Name (подробности чуть позже):

Теперь бегло рассмотрим расширения X.509.

Расширение Basic Constraints используется для маркировки сертификатов как принадлежащих ЦС, давая им возможность подписывать другие сертификаты. В сертификатах, отличных от CA, это расширение будет либо пропущено, либо будет установлено значение CA, равное FALSE. Это расширение является критическим, что означает, что все программные сертификаты должны понимать его значение.

Читайте также:  End processes in linux

Расширения Key Usage (KU) и Extended Key Usage (EKU) ограничивают возможности использования сертификата. Если эти расширения присутствуют, то разрешены только перечисленные варианты использования. Если расширения отсутствуют, ограничений на использование нет. То, что вы видите в этом примере, типично для сертификата веб-сервера, который, например, не позволяет подписывать код:

Расширение CRL Distribution Points перечисляет адреса, по которым можно найти информацию о списке отзыва сертификатов (CRL) ЦС. Эта информация важна в случаях, когда сертификаты необходимо отозвать. CRL — это подписанные CA списки отозванных сертификатов, публикуемые через регулярные промежутки времени (например, семь дней).

Примечание: возможно, вы заметили, что местоположение CRL не использует защищённый сервер, и вам может быть интересно, является ли ссылка небезопасной. Не является. Поскольку каждый CRL подписан центром сертификации, который его выпустил, браузеры могут проверить его целостность. В том же случае, если бы CRL были доступны по TLS (адрес включал бы в себя протокол HTTPS), то браузеры могут столкнуться с проблемой «курицы и яйца», в которой они хотят проверить статус отзыва сертификата, используемого сервером, доставляющим сам CRL!

Расширение Certificate Policies используется для указания политики, в соответствии с которой был выпущен сертификат. Например, именно здесь можно найти индикаторы расширенной проверки (EV). Индикаторы представлены в форме уникальных идентификаторов объектов (OID) и являются уникальными для выдающего ЦС. Кроме того, это расширение часто содержит один или несколько пунктов CPS, которые обычно являются веб-страницами или документами PDF.

Расширение Authority Information Access (AIA) обычно содержит две важные части информации. Во-первых, он перечисляет адрес ответчика CA OCSP, который можно использовать для проверки отзыва сертификатов в режиме реального времени. Расширение также может содержать ссылку, где находится сертификат эмитента (следующий сертификат в цепочке). В наши дни серверные сертификаты редко подписываются непосредственно доверенными корневыми сертификатами, а это означает, что пользователи должны включать в свою конфигурацию один или несколько промежуточных сертификатов. Ошибки легко сделать, и сертификаты будут признаны недействительными. Некоторые клиенты (например, Internet Explorer) будут использовать информацию, представленную в этом расширении для исправления неполной цепочки сертификатов, но многие клиенты этого не сделают.

Расширения Subject Key Identifier и Authority Key Identifier устанавливают уникальные идентификаторы ключа субъекта и ключа авторизации соответственно. Значение, указанное в расширении Authority Key Identifier сертификата, должно соответствовать значению, указанному в расширении Subject Key Identifier в выдающем сертификате. Эта информация очень полезна в процессе построения пути сертификации, когда клиент пытается найти все возможные пути от конечного (серверного) сертификата до доверенного корня. Центры сертификации часто используют один закрытый ключ с несколькими сертификатами, и это поле позволяет программному обеспечению надёжно определять, какой сертификат может быть сопоставлен с каким ключом. В реальном мире многие цепочки сертификатов, предоставляемые серверами, недействительны, но этот факт часто остаётся незамеченным, поскольку браузеры могут находить альтернативные пути доверия.

Наконец, расширение Subject Alternative Name используется для перечисления всех имен хостов, для которых действителен сертификат. Это расширение раньше было необязательным; если его нет, клиенты возвращаются к использованию информации, представленной в Common Name (CN), которое является частью поля «Subject». Если расширение присутствует, то содержимое поля CN игнорируется во время проверки.

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

Чтобы показать издателя сертификата используйте опцию -issuer:

Опция -fingerprint вычисляет и выводит дайджест DER-кодированной версии всего сертификата. Это обычно называют «отпечатком». Из-за характера дайджестов сообщений, отпечаток сертификата является уникальным для этого сертификата, и два сертификата с одинаковым отпечатком могут считаться одинаковыми. Для сертификатов обычно не нужно сверять сертификаты по отпечаткам, но это имеет смысл при использовании самоподписанных сертификатов (например, получении сертификата для VNC сессии, когда нет другого способа проверить, что сертификат не был подменён при пересылке). В этом случае можно сверить отпечаток сертификата, например, по телефону или электронной почте.

Для показа отпечатка сертификата:

Чтобы вывести сертификат в виде строки символов в стиле C — char, используйте опцию -C:

Чтобы вывести расширения сертификата в текстовой форме, используйте опцию -ext. Несколько расширений можно перечислить через запятую, например «subjectAltName,subjectKeyIdentifier«. Чтобы посмотреть весь список расширений:

Пример команды для вывода альтернативных имён в домене:

Пример информации об альтернативных именах домена:

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

Для вывода адресов респондентов OCSP, если они присутствуют в сертификате, укажите опцию -ocsp_uri:

Для показа дат из сертификата имеются следующие опции:

  • -startdate: Распечатывает дату начала сертификата, то есть дату notBefore (не ранее).
  • -enddate: Распечатывает дату истечения срока действия сертификата, то есть дату notAfter (не позднее).
  • -dates: Распечатывает даты начала и окончания срока действия сертификата.

Для вывода имени subject укажите опцию -subject:

Чтобы показать имя subject сертификата в форме RFC2253 используйте сочетание опций -subject -nameopt RFC2253:

Пример вывода имени subject сертификата в форме схемы на терминале, поддерживающем UTF8:

Опция -serial выводит серийный номер:

Чтобы извлечь публичный ключ из сертификата используйте опцию -pubkey:

Для глубокого понимания OpenSSL смотрите также полное руководство: «OpenSSL: принципы работы, создание сертификатов, аудит».


Поделиться с друзьями