воскресенье, 27 ноября 2016 г.

Как создавать и администрировать цепочки сертификатов X.509, часть I

Перевод: How to create and administer X.509 Certificate chains, Part I
Автор: Дитер Клюнтер (Dieter Klünter)

Сертификаты X.509 широко используются для обеспечения безопасной передачи данных и проверки целостности. Первая часть описывает создание частного удостоверяющего центра и сертификатов узла, а вторая часть имеет дело с администрированием сертификатов. Третья часть позволит вам создать собственные инструменты администрирования на основе Bash и Perl. Приведённые ниже примеры основаны на OpenSSL. В этой части мы опишем шаги, необходимые для генерации:
  • корневого ключа для подписания,
  • частного удостоверяющего центра,
  • ключа узла и частного подписанного сертификата,
  • ключа пользователя и частного подписанного сертификата.
Если у вас имеется доступ к доверенному общедоступному удостоверяющему центру, вы можете пропустить шаги инструкции по созданию своего собственного удостоверяющего центра и перейти к инструкции по созданию сертификата узла или пользователя.

Создание удостоверяющего центра

Для подписания сертификатов нужно сначала обзавестись корневым ключом для подписания.
Важно! Этот корневой ключ нужно оберегать
Сначала приготовим файл с паролем:
$ touch myPassfile
$ chmod 0600 myPassfile
$ echo 'secret' > myPassfile
Теперь создадим корневой ключ для подписания:
$ openssl genrsa \
  -des3 \
  -passout file:myPassfile \
  -out privateRoot.key \
  2048
Эта команда создаст ключ для подписания с именем privateRoot.key размером 2048 бит, защищённый паролем. На странице руководства genrsa(1) можно найти дополнительную информацию о доступных параметрах.

Перед созданием удостоверяющего центра и цепочки сертификатов нужно предпринять ряд шагов, которые облегчат дальнейшие действия.
  • Файл конфигурации с параметрами для инициирования удостоверяющего центра, myCA.conf
  • Файл конфигурации с параметрами для инициирования сертификата узла, host.conf
  • Файл конфигурации с дополнительными параметрами X.509 для инициирования удостоверяющего центра, myCA.ext
  • Файл конфигурации с дополнительными параметрами X.509 для инициирования сертификата узла, host.ext
  • Последовательный файл для административных нужд, myCA.serial
Для создания последовательного файла просто выполните следующие команды:
$ touch myCA.serial
$ chmod 0644 myCA.serial
$ echo '00' > myCA.serial
Теперь подготовим необходимые файлы конфигурации для инициации удостоверяющего центра.

myCA.conf:
[req]
default_bits                   = 2048
distinguished_name             = req_DN
string_mask                    = nombstr

[req_DN]
countryName                    = "1. Название страны (двухбуквенный код)"
countryName_default            = DE
countryName_min                = 2
countryName_max                = 2
stateOrProvinceName            = "2. Название штата или провинции (полное название)"
#stateOrProvinceName_default =
localityName                   = "3. Название местности (например, город)"
localityName_default           = Гамбург
0.organizationName             = "4. Название организации (например, компания)"
0.organizationName_default     = Моя организация
organizationalUnitName         = "5. Название подразделения (например, отдел)"
organizationalUnitName_default = Центр сертификации
commonName                     = "6. Простое имя (например, название центра сертификации)"
commonName_max                 = 64
commonName_default             = Мой собственный центр сертификации
emailAddress                   = "7. Адрес электронной почты (например, имя@полное_доменное_имя)"
emailAddress_max               = 40
emailAddress_default           = admin@example.com
myCA.ext:
extensions            = x509v3

[x509v3]
basicConstraints      = CA:true,pathlen:0
crlDistributionPoints = URI:http://example.com/ca/myca.crl
nsCertType            = sslCA,emailCA,objCA
nsCaPolicyUrl         = "http://example.com/ca/policy.html"
nsCaRevocationUrl     = "http://example.com/ca/myca.crl"
nsComment             = "Мой собственный центр сертификации"
Для облегчения администрирования любой удостоверяющий центр должен предоставлять информацию о точках распространения, политике URL и URL списка отозванных сертификатов.

Чтобы создать запрос на сертификат, нужно предоставить некоторую информацию удостоверяющему центру, для чего надо создать myCA.conf. В этом файле конфигурации задаются значения по умолчанию, что позволяет изменять значения в соответствии с требованиями. Создадим запрос на подпись сертификата (Certificate Signing Request) на основе предоставленной информации:
$ openssl req \
  -config myCA.conf \
  -new \
  -key privateRoot.key \
  -passin file:myPassfile \
  -out myPrivateCA.csr
Для подписания этого запроса на сертификат приготовим файл конфигурации с дополнительными параметрами удостоверяющего центра myCA.ext, как это было описано выше.
$ openssl x509 \
  -days 3650 \
  -extfile myCA.ext \
  -signkey privateRoot.key \
  -CAserial myCA.serial \
  -passin file:myPassfile \
  -in myPrivateCA.csr \
  -req \
  -out myPrivateCA.crt
Теперь у нас есть удостоверяющий центр в формате PEM, который можно использовать для подписания сертификатов узлов и пользователей.

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

Веб-сервер, SMTP-сервер, IMAP-сервер, LDAP-сервер и многие другие требуют безопасный транспортный слой (Transport Layer Security), проверку целостности клиентских приложений и служебных узлов. Чтобы включить это требование, сертификат узла должен быть соответствующим образом подписан удостоверяющим центром. В этой главе описано создание:
  • приватного ключа узла
  • сертификата узла
  • файла конфигурации host.conf
  • файл конфигурации host.ext
Сначала приготовим файл host.conf.

host.conf:
[req]
default_bits                   = 2048
distinguished_name             = req_DN
string_mask                    = nombstr

[req_DN]
countryName                    = "1. Название страны (двухбуквенный код)"
countryName_default            = DE
countryName_min                = 2
countryName_max                = 2
stateOrProvinceName            = "2. Название штата или провинции (полное название)"
#stateOrProvinceName_default =
localityName                   = "3. Название местности (например, город)"
localityName_default           = Гамбург
0.organizationName             = "4. Название организации (например, компания)"
0.organizationName_default     = Моя организация
organizationalUnitName         = "5. Название подразделения (например, отдел)"
organizationalUnitName_default = Мой сервер
commonName                     = "6. Простое имя (например, название центра сертификации)"
commonName_max                 = 64
commonName_default             = host.example.com
emailAddress                   = "7. Адрес электронной почты (например, имя@полное_доменное_имя)"
emailAddress_max               = 40
emailAddress_default           = admin@example.com
host.ext:
extensions       = x509v3

[x509v3]
nsCertType       = server
keyUsage         = digitalSignature,nonRepudiation,keyEncipherment
extendedKeyUsage = msSGC,nsSGC,serverAuth
subjectAltName   = DNS:ldap.example.com

Атрибут типа commonName принимает в качестве значения полное имя узла. Атрибут типа subjectAltName позволяет указать несколько псевдонимов узлов, разделённых запятыми.

Сначала создадим приватный ключ узла:
$ touch hostPassfile
$ chmod 0600 hostPassfile
$ echo 'secret' > hostPassfile
$ openssl genrsa \
  -des3 \
  -passout file:hostPassfile \
  -out myHost.key \
  2048
Совет. Если вы не хотите использовать ключ узла, защищённый паролем, воспользуйтесь такой командой:
$ openssl genrsa -out myHost.key 2048
Следующая команда создаст запрос на подпись сертификата:
$ openssl req \
  -config host.conf \
  -new \
  -key myHost.key \
  -passin file:hostPassfile \
  -out MyHost.csr
И наконец, можно подписать сертификат узла:
$ openssl x509 \
  -days 1825 \
  -extfile host.ext \
  -CA myPrivateCA.crt \
  -CAkey privateRoot.key
  -passin file:myPassfile \
  -CAserial myCA.serial \
  -in MyHost.csr \
  -req \
  -out myHost.crt
Теперь у нас есть сертификат узла, ключ сертификата узла и удостоверяющий центр. Далее мы подготовим сертификат пользователя.

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

Обычно сертификаты пользователя используются для аутентификации и подписания электронных писем. Как и в прошлый раз, для создания ключа пользователя и сертификата пользователя нужны те же шаги. Дополнительно в файл pkcs12 можно поместить полную цепочку сертификатов. Как и в случае сертификатов узлов, нужны несколько подготовительных шагов:
  • файл user.conf
  • файл user.ext
  • ключ пользователя
  • сертификат пользователя
Сначала создадим файл user.conf.

user.conf:
[req]
default_bits                   = 2048
distinguished_name             = req_DN
string_mask                    = nombstr

[req_DN]
countryName                    = "1. Название страны (двухбуквенный код)"
countryName_default            = DE
countryName_min                = 2
countryName_max                = 2
stateOrProvinceName            = "2. Название штата или провинции (полное название)"
#stateOrProvinceName_default =
localityName                   = "3. Название местности (например, город)"
localityName_default           = Гамбург
0.organizationName             = "4. Название организации (например, компания)"
0.organizationName_default     = Моя организация
organizationalUnitName         = "5. Название подразделения (например, отдел)"
organizationalUnitName_default = Люди
commonName                     = "6. Простое название (например, название центра сертификации)"
commonName_max                 = 64
commonName_default             = Пол Смит
emailAddress                   = "7. Адрес электронной почты (например, имя@полное_доменное_имя)"
emailAddress_max               = 40
emailAddress_default           = paul@example.com

Этот набор данных создаст сертификат с выделенным именем:
dn: cn=Пол Смит,ou=Люди,o=Моя организация,c=DE
user.ext:
extensions = x509v3

[x509v3]
nsCertType = client,email,objsign
keyUsage   = digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
Сначала создадим файл с приватным паролем и с приватным ключом:
$ touch userPassfile
$ chmod 0600 userPassfile
$ echo 'secret' > userPassfile
$ openssl genrsa \
  -des3 \
  -passout file:userPassfile \
  -out myUser.key \
  2048
Далее создадим запрос на подписание сертификата пользователя:
$ openssl req \
  -config user.conf \
  -new \
  -key myUser.key \
  -passin file:userPassfile \
  -out MyUser.csr
И наконец, подпишем сертификат пользователя:
$ openssl x509 \
  -days 1825 \
  -extfile user.ext \
  -CA myPrivateCA.crt \
  -CAkey privateRoot.key
  -passin file:myPassfile \
  -CAserial myCA.serial \
  -in MyUser.csr \
  -req \
  -out myUser.crt
Теперь у нас есть правильная цепочка сертификатов, которая позволит нам создать архив pkcs12:
$ openssl pkcs12 \
  -export \
  -in myUser.crt \
  -inkey myUser.key \
  -passin file:userPassfile \
  -CAfile myPrivateCA.crt \
  -name MyUsercertificate \
  -out myUser.pkcs12
В части II будет рассмотрено администрирование сертификатов, обслуживание серийного файла и файла индекса.

Примечание переводчика: Вторая часть пока не опубликована автором, поэтому пока не будет и её перевода. Зато я нашёл другое более подробное руководство по администрированию собственного удостоверяющего центра на основе OpenSSL. Перевод этого руководства будет опубликован в дальнейших заметках этого блога. Следите за обновлениями.

воскресенье, 20 ноября 2016 г.

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

Перевод: Encrypt and decrypt files to public keys via the OpenSSL Command Line
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Получение публичного ключа
  2. Создание случайного файла пароля
  3. Шифрование файла случайным ключом
  4. Шифрование случайного ключа файлом публичного ключа
  5. Расшифровывание случайного ключа при помощи файла своего приватного ключа
  6. Расшифровывание большого файла случайным ключом
Этот небольшой рецепт показывает, как использовать openssl из командной строки для шифрования файла публичным ключом и расшифровывания файла. Сначала мы создадим случайный ключ, зашифруем этот случайный ключ публичным ключом другого человека и с помощью этого случайного ключа зашифруем сам файл, используя симметричное шифрование.

Из-за особенностей алгоритма RSA, с его помощью невозможно шифровать большие файлы. Если создать ключ из n бит, то шифруемый файл не должен быть больше чем (n минус 11) бит. Наиболее эффективное использование RSA - шифрование случайного пароля, с последующим шифрованием файла паролем с помощью алгоритма симметричного шифрования. Если файл больше, чем размер ключа, то команда шифрования завершится ошибкой:
RSA operation error: 020:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:.\crypto\rsa\rsa_pk1.c:151:
Создадим случайный файл и используем его в качестве ключа для шифрования большого файла алгоритмом симметричного шифрования. Этот случайный файл выполнит роль пароля, который мы сообщим. Большой файл зашифруем маленьким файлом, выступающим в роли пароля. Затем отправим зашифрованный файл и зашифрованный ключ получателю, а он сможет расшифровать ключ своим приватным ключом и использовать этот ключ для расшифровывания большого файла.

Для работы с ключами RSA используются следующие команды:
  • openssl genrsa: Создание приватных ключей RSA.
  • openssl rsa: Управление приватными ключами RSA (включая создание публичного ключа из приватного).
  • openssl rsautl: Шифрование и расшифровывание файлов ключами RSA.
Ключ - это просто строка случайных байтов. Воспользуемся строкой из 128 байтов, из которых в результате кодирования base64 получится 175 символов. Поскольку 175 символов - это 1400 бит, ключ получится достаточно маленьким, чтобы можно было зашифровать его при помощи RSA.

Получение публичного ключа

Попросите получателя отправить вам его сертификат или публичный ключ. Если он отправил сертификат, можно извлечь из него публичный ключ с помощью следующей команды:
openssl rsa -in certificate.pem -out publickey.pem -outform PEM -pubout
Создание случайного файла пароля

Воспользуемся следующей командой, чтобы создать случайный ключ:
openssl rand -base64 128 -out key.bin
Делайте это при каждом шифровании файла. Каждый раз используйте новый ключ!

Шифрование файла случайным ключом

Воспользуемся следующей командой, чтобы зашифровать большой файл случайным ключом:
openssl enc -aes-256-cbc -salt -in largefile.pdf -out largefile.pdf.enc -pass file:./bin.key
Размер файла вырастет ненамного:
$ ls -larth
-rw-r--r-- 1 user group 40M Nov 9 21:14 Linux-Voice-Issue-020.pdf
-rw-r--r-- 1 user group 40M Nov 9 22:03 Linux-Voice-Issue-020.pdf.enc
Однако, он зашифрован:
$ file Linux-Voice-Issue-020.pdf
Linux-Voice-Issue-020.pdf: PDF document, version 1.4

$ file Linux-Voice-Issue-020.pdf.enc
Linux-Voice-Issue-020.pdf.enc: data
Шифрование случайного ключа файлом публичного ключа

Воспользуемся следующей командой для шифрования файла случайного ключа публичным ключом получателя:
openssl rsautl -encrypt -inkey publickey.pem -pubin -in key.bin -out key.bin.enc
Теперь можно без опаски отправить получателю key.bin.enc и largefile.pdf.enc.

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

Расшифровывание случайного ключа при помощи файла своего приватного ключа

Если нужно расшифровать файл, зашифрованный описанным способом, воспользуйтесь следующей командой, указав ей свой приватный ключ (соответствующий публичному ключу, которым был зашифрован случайный ключ) для расшифровывания случайного ключа:
openssl rsautl -decrypt -inkey privatekey.pem -in key.bin.enc -out key.bin
В результате получим расшифрованный случайный ключ, которым зашифрован полученный файл.

Расшифровывание большого файла случайным ключом

Как только был получен случайный ключ, можно расшифровать расшифрованным ключом зашифрованный файл:
openssl enc -d -aes-256-cbc -in largefile.pdf.enc -out largefile.pdf -pass file:./bin.key
В результате получим расшифрованный большой файл.

воскресенье, 13 ноября 2016 г.

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

Перевод: Sign and verify text/files to public keys via the OpenSSL Command Line
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Создание пары ключей
  2. Подписание файла
  3. Проверка подписи
  4. Подпись
В этом небольшом руководстве рассматривается, как использовать OpenSSL из командной строки для подписания файла и как проверить подпись этого файла. Это делается для того, чтобы доказать владение ключом или чтобы доказать, что файл не был изменён с тех пор, как был подписан. Руководство пригодно и для небольших текстовых файлов, и для больших фотографий, и для документов, и файлов PDF.

Создание пары ключей

Сначала создадим новую пару ключей. Можно использовать существующую пару. Измените тему в следующей команде и выполните её, чтобы создать самозаверенную пару ключей:
openssl req -nodes -x509 -sha256 -newkey rsa:4096 -keyout "$(whoami)s Sign Key.key" -out "$(whoami)s Sign Key.crt" \
-days 365 -subj "/C=NL/ST=Zuid Holland/L=Rotterdam/O=Sparkling Network/OU=IT Dept/CN=$(whoami)s Sign Key"
Также создадим небольшой текстовый файл для тестирования процесса подписания:
echo "Здравствуй, мир!" > sign.txt
Подписание файла

Воспользуемся следующей командой, чтобы подписать файл. На самом деле мы одной командой openssl посчитаем хэш файла по алгоритму sha256 и подпишем его:
openssl dgst -sha256 -sign "$(whoami)s Sign Key.key" -out sign.txt.sha256 sign.txt
В результате получим файл sign.txt с его содержимым и файл sign.txt.sha256 с подписанным хэшем этого файла.

Можно разместить этот файл и публичный ключ ($(whoami)s Sign Key.crt) в интернете или в другом месте. Храните приватный ключ ($(whoami)s Sign Key.key) в безопасности и секретности.

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

Для проверки подписи нужен публичный ключ, относящийся к сертификату. Его можно получить из сертификата с помощью следующей команды:
openssl x509 -in "$(whoami)s Sign Key.crt"
Можно избежать этого этапа, объединив два этапа в одной команде. Следующая команда проверяет файл с помощью подписи хэша:
openssl dgst -sha256 -verify <(openssl x509 -in "$(whoami)s Sign Key.crt" -pubkey -noout) -signature sign.txt.sha256 sign.txt
Если содержимое не было изменено с момента подписания, вывод команды будет таким:
Verified OK
Если проверка завершилась неудачно, это означает, что хэш файла не соответствует подписанному хэшу. Весьма вероятно, что файл был изменён или подделан. Результат неудачной проверки выглядит следующим образом:
Verification Failure
Подпись

Чтобы получить текстовую версию подписи (файл содержит двоичные данные), можно воспользоваться командой base64. Текстовую версию вместе с файлом проще разместить в интернете:
base64 sign.txt.sha256 > sign.txt.sha256.txt
Для обратного преобразования в формат, пригодный для использования в openssl, воспользуйтесь командой base64 -d:
base64 -d sign.txt.sha256.txt > sign.txt.sha256

воскресенье, 6 ноября 2016 г.

OpenSSL: Ручная проверка сертификата по OCSP

Перевод: OpenSSL: Manually verify a certificate against an OCSP
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Получение сертификата с OCSP
  2. Получение цепочки сертификатов
  3. Посылка запроса OCSP
  4. Отозванный сертификат
  5. Другие ошибки
  6. Источники
В этой статье показано, как вручную проверить сертификат на OCSP-сервере. OCSP означает Online Certificate Status Protocol - протокол интерактивного статуса сертификата - и является одним из способов проверки актуальности сертификата. Это альтернатива для CRL, Certificate Revocation List - списка отозванных сертификатов.

По сравнению с CRL:
  • Поскольку ответ OCSP содержит меньше информации по сравнению с обычным CRL, OCSP может более эффективно использовать ресурсы сети и клиента.
  • При использовании OCSP клиентам не нужно разбирать CRL самостоятельно, что упрощает реализацию клиента. Однако это компенсируется практической необходимостью поддерживать кэш. На практике эти соображения имеют малое значение, потому что приложения полагаются на сторонние библиотеки, реализующие все функции X.509.
  • OCSP предоставляет информацию об определённом сетевом узле, использующим определённый сертификат в определённое время. OCSP не предоставляет шифрование, поэтому третья сторона может перехватить эту информацию.
Подробности об OCSP можно найти на Википедии.

Если нужно вручную проверить сертификат по CRL, обратитесь к соответствующей статье.

Воспользуемся OpenSSL. Я использую такую версию:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Получение сертификата с OCSP

Для начала, нам нужен сам сертификат веб-сайта. В качестве примера возьмём сайт Википедия. Получить его сертификат можно при помощи следующей команды:
openssl s_client -connect wikipedia.org:443 2&t;&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p'
Сохраним вывод команды в файл, например, wikipedia.pem:
openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > wikipedia.pem
Теперь проверим, есть ли в сертификате URI OCSP:
openssl x509 -noout -ocsp_uri -in wikipedia.pem
http://ocsp.digicert.com
Если вывод команды пуст, значит у сертификата нет URI OCSP. Этот сертификат нельзя проверить по OCSP.

Получение цепочки сертификатов

Вместе с проверяемым сертификатом нужно отправить цепочку сертификатов. Для этого нужно получить цепочку сертификатов для проверяемого домена, wikipedia.org. С помощью опции -showcerts команды openssl s_client можно увидеть все сертификаты в цепочке:
openssl s_client -connect wikipedia.org:443 -showcerts 2>&1 < /dev/null
Команда выдаст много информации, но нас интересует только следующее:
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
MIIGWDCCBUCgAwIBAgIQCl8RTQNbF5EX0u/UA4w/OzANBgkqhkiG9w0BAQUFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTA4MDQwMjEyMDAwMFoXDTIyMDQwMzAwMDAwMFowZjEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTElMCMGA1UEAxMcRGlnaUNlcnQgSGlnaCBBc3N1cmFuY2Ug
Q0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL9hCikQH17+NDdR
CPge+yLtYb4LDXBMUGMmdRW5QYiXtvCgFbsIYOBC6AUpEIc2iihlqO8xB3RtNpcv
KEZmBMcqeSZ6mdWOw21PoF6tvD2Rwll7XjZswFPPAAgyPhBkWBATaccM7pxCUQD5
BUTuJM56H+2MEb0SqPMV9Bx6MWkBG6fmXcCabH4JnudSREoQOiPkm7YDr6ictFuf
1EutkozOtREqqjcYjbTCuNhcBoz4/yO9NV7UfD5+gw6RlgWYw7If48hl66l7XaAs
zPw82W3tzPpLQ4zJ1LilYRyyQLYoEt+5+F/+07LJ7z20Hkt8HEyZNp496+ynaF4d
32duXvsCAwEAAaOCAvowggL2MA4GA1UdDwEB/wQEAwIBhjCCAcYGA1UdIASCAb0w
ggG5MIIBtQYLYIZIAYb9bAEDAAIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3
LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH
AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQBy
AHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj
AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAg
AEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQ
AGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBt
AGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBj
AG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBl
AHIAZQBuAGMAZQAuMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYIKwYBBQUHAQEEKDAm
MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgY8GA1UdHwSB
hzCBhDBAoD6gPIY6aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0SGln
aEFzc3VyYW5jZUVWUm9vdENBLmNybDBAoD6gPIY6aHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0SGlnaEFzc3VyYW5jZUVWUm9vdENBLmNybDAfBgNVHSME
GDAWgBSxPsNpA/i/RwHUmCYaCALvY2QrwzAdBgNVHQ4EFgQUUOpzidsp+xCPnuUB
INTeeZlIg/cwDQYJKoZIhvcNAQEFBQADggEBAB7ipUiebNtTOA/vphoqrOIDQ+2a
vD6OdRvw/S4iWawTwGHi5/rpmc2HCXVUKL9GYNy+USyS8xuRfDEIcOI3ucFbqL2j
CwD7GhX9A61YasXHJJlIR0YxHpLvtF9ONMeQvzHB+LGEhtCcAarfilYGzjrpDq6X
dF3XcZpCdF/ejUN83ulV7WkAywXgemFhM9EZTfkI7qA5xSU1tyvED7Ld8aW3DiTE
JiiNeXf1L/BXunwH1OH8zVowV36GEEfdMR/X/KLCvzB8XSSq6PmuX2p0ws5rs0bY
Ib4p1I5eFdZCSucyb6Sxa1GDWL4/bcf72gMhy2oWGU4K8K2Eyl2Us1p292E=
-----END CERTIFICATE-----
Как можно увидеть, это номер 1. Номер 0 - это сертификат Википедии, он у нас уже есть. Если у проверяемого сайта больше сертификатов в цепочке, они все будут отображены. Сохраните их все в том порядке, в котором их выведет OpenSSL (первый - который непосредственно выпустил сертификат вашего сервера, затем тот, который выпустил этот сертификат и т.д. с корневым или самым корневым в конце файла) в файл с именем chain.pem.

Отправка запроса OCSP

Теперь у нас есть все данные, необходимые для выполнения запроса OCSP. С помощью следующей команды OpenSSL можно отправить запрос OCSP и получить текстовый результат:
openssl ocsp -issuer chain.pem -cert wikipedia.pem -text -url http://ocsp.digicert.com
Результаты:
OCSP Request Data:                                                   # Данные запроса OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Requestor List:                                                  # Список просителя
        Certificate ID:                                              # Идентификатор сертификата
          Hash Algorithm: sha1                                       # Алгоритм хэширования: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 # Хэш имени выпустившего сертификат: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7  # Хэш ключа выпустившего сертификат: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F            # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:                                              # Расширения запроса
        OCSP Nonce:                                                  # Текущий OCSP
            0410DA634F2ADC31DC48AE89BE64E8252D12
OCSP Response Data:                                                  # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                           # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                               # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Responder Id: 50EA7389DB29FB108F9EE50120D4DE79994883F7           # Идентификатор ответчика: 50EA7389DB29FB108F9EE50120D4DE79994883F7
    Produced At: Apr 9 08:45:00 2014 GMT                             # Создано: 9 апреля 2014 года в 08:45:00 по Гринвичу
    Responses:                                                       # Ответы:
    Certificate ID:                                                  # Идентификатор сертификата:
      Hash Algorithm: sha1                                           # Алгоритм хэширования: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96     # Хэш имени эмитента: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7      # Хэш ключа эмитента: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F                # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: good                                                # Статус сертификата: хороший
    This Update: Apr 9 08:45:00 2014 GMT                             # Это обновление: 9 апреля 2014 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2014 GMT                            # Следующее обновление: 16 апреля 2014 года в 09:00:00 по Гринвичу

    Signature Algorithm: sha1WithRSAEncryption                       # Алгоритм подписи: sha1WithRSAEncryption
         56:21:4c:dc:84:21:f7:a8:ac:a7:b9:bc:10:19:f8:19:f1:34:
         c1:63:ca:14:7f:8f:5a:85:2a:cc:02:b0:f8:b5:05:4a:0f:28:
         50:2a:4a:4d:04:01:b5:05:ef:a5:88:41:d8:9d:38:00:7d:76:
         1a:aa:ff:21:50:68:90:d2:0c:93:85:49:e7:8e:f1:58:08:77:
         a0:4e:e2:22:98:01:b7:e3:27:75:11:f5:b7:8f:e0:75:7d:19:
         9b:74:cf:05:dc:ae:1c:36:09:95:b6:08:bc:e7:3f:ea:a2:e3:
         ae:d7:8f:c0:9d:8e:c2:37:67:c7:5b:d8:b0:67:23:f1:51:53:
         26:c2:96:b0:1a:df:4e:fb:4e:e3:da:a3:98:26:59:a8:d7:17:
         69:87:a3:68:47:08:92:d0:37:04:6b:49:9a:96:9d:9c:b1:e8:
         cb:dc:68:7b:4a:4d:cb:08:f7:92:67:41:99:b6:54:56:80:0c:
         18:a7:24:53:ac:c6:da:1f:4d:f4:3c:7d:68:44:1d:a4:df:1d:
         48:07:85:52:86:59:46:d1:35:45:1a:c7:6b:6b:92:de:24:ae:
         c0:97:66:54:29:7a:c6:86:a6:da:9f:06:24:dc:ac:80:66:95:
         e0:eb:49:fd:fb:d4:81:6a:2b:81:41:57:24:78:3b:e0:66:70:
         d4:2e:52:92
wikipedia.pem: good                                                  # wikipedia.pem: хороший
    This Update: Apr 9 08:45:00 2014 GMT                             # Это обновление: 9 апреля 2014 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2014 GMT                            # Следующее обновление: 16 апреля 2014 года в 09:00:00 по Гринвичу
Если вы хотите получить более общий вывод, пропустите опцию -text. В большинстве случаев она нужна только при решении проблем с OCSP.

Вот как выглядит статус хорошего сертификата:
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digicert.com
wikipedia.pem: good                                                              # wikipedia.pem: хороший
    This Update: Apr 9 08:45:00 2014 GMT                                         # Это обновление: 9 апреля 2014 года в 08:45:00 по Гринвичу
    Next Update: Apr 16 09:00:00 2014 GMT                                        # Следующее обновление: 16 апреля 2014 года в 09:00:00 по Гринвичу
Отозванный сертификат

Если у вас есть отозванный сертификат, его так же можете проверить способом, описанным выше. Ответ выглядит следующим образом:
Response verify OK                            # Ответ проверки успешен
test-revoked.pem: revoked                     # test-revoked.pem: отозван
    This Update: Apr 9 03:02:45 2014 GMT      # Это обновление: 9 апреля 2014 года в 03:02:45 по Гринвичу
    Next Update: Apr 10 03:02:45 2014 GMT     # Следующее обновление: 10 апреля 2014 года в 03:02:45 по Гринвичу
    Revocation Time: Mar 25 15:45:55 2014 GMT # Время отзыва: 25 марта 2014 года в 14:45:55 по Гринвичу
Вы можете проверить этот сертификат и цепочку на странице проверки отозванных сертификатов Verisign: https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html

Другие ошибки

Если отправить этот запрос к другому OCSP, который не выпускал проверяемый сертификат, должна произойти ошибка авторизации:
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://rapidssl-ocsp.geotrust.com
Responder Error: unauthorized (6)                                                         # Ошибка ответа: не авторизован (6)
Опция -text покажет больше информации:
OCSP Request Data:                                                   # Данные запроса OCSP
    Version: 1 (0x0)                                                 # Версия: 1 (0x0)
    Requestor List:                                                  # Список просителя:
        Certificate ID:                                              # Идентификатор сертификата
          Hash Algorithm: sha1                                       # Алгоритм хэширования: sha1
          Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96 # Хэш имени выпустившего сертификат: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
          Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7  # Хэш ключа выпустившего сертификат: 50EA7389DB29FB108F9EE50120D4DE79994883F7
          Serial Number: 0114195F66FAFF8FD66E12496E516F4F            # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Request Extensions:                                              # Расширения запроса
        OCSP Nonce:                                                  # Текущий OCSP
            041015BB718C43C46C41122E841DB2282ECE
Responder Error: unauthorized (6)                                    # Ошибка ответа: не авторизован (6)
Некоторые OCSP настроены по-другому и выдают такую ошибку:
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.digidentity.eu/L4/services/ocsp
Response Verify Failure                                                                                          # Ответ проверки неудачен
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
140735308649312:error:2706B06F:OCSP routines:OCSP_CHECK_IDS:response contains no revocation data:ocsp_vfy.c:269:
wikipedia.pem: ERROR: No Status found.                                                                           # wikipedia.pem: ОШИБКА: Статус не найден.
Если добавить опцию -text, можно увидеть ответ, но в нём не будет данных:
OCSP Response Data:                                                   # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                            # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                                # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                  # Версия: 1 (0x0)
    Responder Id: C = NL, O = Digidentity B.V., CN = Digidentity OCSP # Идентификатор ответчика: C = NL, O = Digidentity B.V., CN = Digidentity OCSP
    Produced At: Apr 9 12:02:00 2014 GMT                              # Сформирован: 9 апреля 2014 года в 12:02:00 по Гринвичу
    Responses:                                                        # Ответы
    Request Extensions:                                               # Расширения запроса
OCSP Nonce:                                                           # Текущий OCSP
    0410EB540472EA2D8246E88F3317B014BEEF
Signature Algorithm: sha256WithRSAEncryption                          # Алгоритм подписи: sha256WithRSAEncryption
Другие OCSP возвращают статус "неизвестно":
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp.quovadisglobal.com/
Response Verify Failure                                                                            # Ответ проверки неудачен
140735308649312:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:152:
wikipedia.pem: unknown                                                                             # wikipedia.pem: неизвестно
    This Update: Apr 9 12:09:18 2014 GMT                                                           # Это обновление: 9 апреля 2014 года в 12:09:18 по Гринвичу
Опция -text покажет больше информации:
OCSP Response Data:                                                                                         # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                                                                  # Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                                                                      # Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                                                                        # Версия: 1 (0x0)
    Responder Id: C = CH, O = QuoVadis Limited, OU = OCSP Responder, CN = QuoVadis OCSP Authority Signature # Идентификатор ответчика: C = CH, O = QuoVadis Limited, OU = OCSP Responder, CN = QuoVadis     OCSP Authority Signature
    Produced At: Apr 9 12:09:10 2014 GMT                                                                    # Сформирован: 9 апреля 2014 года в 12:09:10 по Гринвичу
    Responses:                                                                                              # Ответы
    Certificate ID:                                                                                         # Идентификатор сертификата:
      Hash Algorithm: sha1                                                                                  # Алгоритм хэширования: sha1
      Issuer Name Hash: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96                                            # Хэш имени эмитента: ED48ADDDCB7B00E20E842AA9B409F1AC3034CF96
      Issuer Key Hash: 50EA7389DB29FB108F9EE50120D4DE79994883F7                                             # Хэш ключа эмитента: 50EA7389DB29FB108F9EE50120D4DE79994883F7
      Serial Number: 0114195F66FAFF8FD66E12496E516F4F                                                       # Серийный номер: 0114195F66FAFF8FD66E12496E516F4F
    Cert Status: good                                                                                       # Статус сертификата: неизвестно
    This Update: Apr 9 12:09:10 2014 GMT                                                                    # Это обновление: 9 апреля 2014 года в 12:09:10 по Гринвичу

    Response Extensions:                                                                                    # Расширения ответа
Источники