воскресенье, 25 декабря 2016 г.

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

Перевод: Sign server and client certificates
Автор: Джэми Нгуен (Jamie Nguyen)

Подпишем сертификаты при помощи нашего промежуточного удостоверяющего центра. Подписанные сертификаты можно использовать в различных целях, например, для установки безопасных подключений к веб-серверу или аутентификации клиентов, подключающихся к сервису.
Замечание. Шаги, описанные ниже, описаны с точки зрения удостоверяющего центра. Сторонние пользователи, однако, вместо этого могут создавать свои собственные приватные ключи и запросы на подпись сертификата, не предоставляя вам свои собственные приватные ключи. Они предоставят вам их запрос на сертификат, а вы отдадите им обратно подписанный сертификат. В этом случае пропустите команды genrsa и req.
Создание ключа

Наши пары ключей для корневого и промежуточного удостоверяющих центров имеют длину 4096 бит. Сертификаты сервера и клиента обычно истекают через один год, поэтому можно безопасно использовать 2048-битные ключи.
Замечание. Хотя 4096-битные ключи немного более безопасны, чем 2048-битные, они замедляют рукопожатие TLS и значительно увеличивают нагрузку на процессор во время рукопожатия. По этой причине большинство веб-сайтов используют 2048-битные ключи.
Если вы создаёте криптографическую пару ключей для использования веб-сервером (например, Apache), нужно будет вводить этот пароль при каждой перезагрузке веб-сервера. Возможно вы захотите пропустить опцию -aes256, чтобы создать ключ без пароля.
# cd /root/ca
# openssl genrsa -aes256 \
  -out intermediate/private/www.example.com.key.pem 2048
# chmod 400 intermediate/private/www.example.com.key.pem
Создание сертификата

Используйте приватный ключ для создания запроса на подпись сертификата (CSR). Информация из запроса не обязательно должна совпадать с промежуточным удостоверяющим центром. Для сертификатов серверов поле общего имени Common Name должно быть полным доменным именем (например, www.example.com), а для сертификатов пользователей им может быть уникальный идентификатор (например, адрес электронной почты). Отметим, что поле общего имени Common Name не может быть таким же, как у сертификата корневого или промежуточного удостоверяющего центра.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
  -key intermediate/private/www.example.com.key.pem \
  -new -sha256 -out intermediate/csr/www.example.com.csr.pem
Enter pass phrase for www.example.com.key.pem: secretpassword            # Введите ключевую фразу для www.example.com.key.pem: секретныйпароль
You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена
into your certificate request.                                           # в ваш запрос сертификата.
-----
Country Name (2 letter code) [XX]:US                                     # Название страны (двухбуквенный код) [XX]:US
State or Province Name []:California                                     # Название штата или провинции []:Калифорния
Locality Name []:Mountain View                                           # Название местности []:Маунтин Вью
Organization Name []:Alice Ltd                                           # Название организации []:ООО Алиса
Organizational Unit Name []:Alice Ltd Web Services                       # Название подразделения []:Веб-сервисы ООО Алиса
Common Name []:www.example.com                                           # Общее имя []:www.example.com
Email Address []:                                                        # Адрес электронной почты []:
Чтобы создать сертификат, воспользуемся промежуточным удостоверяющим центром для подписи запроса на сертификат. Если сертификат будет использоваться на сервере, воспользуемся расширением server_cert. Если сертификат будет использоваться для аутентификации пользователя, воспользуемся расширением usr_cert. Сертификаты обычно выдаются сроком на один год, но удостоверяющие центры обычно для удобства дают несколько дополнительных дней.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
  -extensions server_cert -days 375 -notext -md sha256 \
  -in intermediate/csr/www.example.com.csr.pem \
  -out intermediate/certs/www.example.com.cert.pem
# chmod 444 intermediate/certs/www.example.com.cert.pem
Файл intermediate/index.txt должен содержать строку, ссылающуюся на этот новый сертификат.
V 160420124233Z 1000 unknown ... /CN=www.example.com
Проверка сертификата
# openssl x509 -noout -text \
  -in intermediate/certs/www.example.com.cert.pem
Эмитент - промежуточный удостоверяющий центр. Поле субъекта ссылается на сам сертификат.
Signature Algorithm: sha256WithRSAEncryption                 # Алгоритм подписания: sha256WithRSAEncryption
    Issuer: C=GB, ST=England,                                #     Эмитент: C=GB, ST=Англия,
            O=Alice Ltd, OU=Alice Ltd Certificate Authority, #              O=ООО Алиса, OU=Удостоверяющий центр ООО Алиса,
            CN=Alice Ltd Intermediate CA                     #              CN=Промежуточный удостоверяющий центр ООО Алиса
    Validity                                                 #     Действительность
        Not Before: Apr 11 12:42:33 2015 GMT                 #         Не ранее: 11 апреля 2015 года в 12:42:33 по Гринвичу
        Not After : Apr 20 12:42:33 2016 GMT                 #         Не позднее: 20 апреля 2016 года 12:42:33 по Гринвичу
    Subject: C=US, ST=California,                            #     Субъект: C=US, ST=Калифорния, L=Маунтин Вью,
             O=Alice Ltd, OU=Alice Ltd Web Services,         #              O=ООО Алиса, OU=Веб-сервисы ООО Алиса,
             CN=www.example.com
    Subject Public Key Info:                                 #     Информация публичного ключа субъекта:
        Public Key Algorithm: rsaEncryption                  #         Алгоритм публичного ключа: rsaEncryption
            Public-Key: (4096 bit)                           #             Публичный ключ: (4096 бит)
В выводе также показаны расширения X509v3. При создании сертификата было использовано одно из двух расширений: server_cert или usr_cert. Опции из соответствующего раздела конфигурации будут отражены в выводе.
X509v3 extensions:                                                                                   # Расширения X509v3:
    X509v3 Basic Constraints:                                                                        #     Базовые ограничения X509v3:
        CA:FALSE
    Netscape Cert Type:                                                                              #     Тип сертификата Netscape:
        SSL Server                                                                                   #         SSL-сервер
    Netscape Comment:                                                                                #     Комментарий Netscape
        OpenSSL Generated Server Certificate                                                         #         Сертификат сервера, созданный OpenSSL
    X509v3 Subject Key Identifier:                                                                   #     Идентификатор ключа субъекта X509v3:
        B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5
    X509v3 Authority Key Identifier:                                                                 #     Идентификатор ключа подлинности X509v3:
        keyid:69:E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9
        DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA #         ИмяКаталога:/C=GB/ST=Англия/O=ООО Алиса/OU=Удостоверяющий центр ООО Алиса/CN=Корневой удостоверяющий центр ООО Алиса
        serial:10:00

    509v3 Key Usage: critical                                                                        #     Использование ключа X509v3: критичное
        Digital Signature, Key Encipherment                                                          #         Цифровая подпись, ключ шифрования
    X509v3 Extended Key Usage:                                                                       #     Расширенное использование ключа X509v3:
        TLS Web Server Authentication                                                                #         Аутентификация веб-сервера TLS
Воспользуемся ранее созданным файлом цепочки сертификата удостоверяющего центра (ca-chain.cert.pem), чтобы проверить, что этот новый сертификат обладает действительной цепочкой доверия.
# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
  intermediate/certs/www.example.com.cert.pem
www.example.com.cert.pem: OK
Установка сертификата

Теперь можно либо установить новый сертификат на сервер, либо передать сертификат клиенту. При установке на серверное приложение (например, Apache), нужно сделать доступными следующие файлы:
  • ca-chain.cert.pem
  • www.example.com.key.pem
  • www.example.com.cert.pem
Если вы подписали запрос на сертификат, полученный со стороны, у вас не будет доступа к приватному ключу, так что обратно вам нужно будет передать только файл цепочки (ca-chain.cert.pem) и сертификат (www.example.com.cert.pem).

воскресенье, 18 декабря 2016 г.

Создание промежуточной пары

Перевод: Create the intermediate pair
Автор: Джэми Нгуен (Jamie Nguyen)

Промежуточный удостоверяющий центр (CA) может подписывать сертификаты от имени корневого удостоверяющего центра. Корневой удостоверяющий центр подписывает промежуточный сертификат, формируя цепочку доверия.

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

Подготовка каталога

Файлы корневого удостоверяющего центра хранятся в /root/ca. Выберем другой каталог (/root/ca/intermediate) для хранения файлов промежуточного удостоверяющего центра.
# mkdir /root/ca/intermediate
Создадим такую же структуру каталогов, которая используется файлами корневого удостоверяющего центра. Удобно также создать каталог csr для хранения запросов на подпись сертификатов.
# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Добавим файл crlnumber в дерево каталогов промежуточного удостоверяющего центра. crlnumber используется для отслеживания списков отозванных сертификатов.
# echo 1000 > /root/ca/intermediate/crlnumber
Скопируем файл конфигурации промежуточного удостоверяющего центра из Приложения Б в /root/ca/intermediate/openssl.cnf. По сравнению с файлом конфигурации корневого удостоверяющего центра изменилось пять опций:
[CA_default]
dir         = /root/ca/intermediate
private_key = $dir/private/intermediate.key.pem
certificate = $dir/certs/intermediate.cert.pem
crl         = $dir/crl/intermediate.crl.pem
policy      = policy_loose
Создание промежуточного ключа

Создадим промежуточный ключ (intermediate.key.pem). Зашифруем промежуточный ключ 256-битным алгоритмом шифрования AES с использованием стойкого пароля.
# cd /root/ca
# openssl genrsa -aes256 \
  -out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: secretpassword             # Введите ключевую фразу для intermediate.key.pem: секретныйпароль
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword # Подтверждение - Введите ключевую фразу для intermediate.key.pem: секретныйпароль
# chmod 400 intermediate/private/intermediate.key.pem
Создание промежуточного сертификата

Используйте промежуточный ключ для создания запроса на подпись сертификата (CSR). Детали в целом совпадают со случаем для корневого удостоверяющего центра. Однако, поле общего имени - Common Name, должно быть другим.
Предупреждение! Удостоверьтесь, что вы указали файл конфигурации промежуточного удостоверяющего центра (intermediate/openssl.cnf).
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
  -key intermediate/private/intermediate.key.pem \
  -out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword               # Введите ключевую фразу для intermediate.key.pem: секретныйпароль
You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена
into your certificate request.                                           # в ваш запрос сертификата.
-----
Country Name (2 letter code) [XX]:GB                                     # Название страны (двухбуквенный код) [XX]:GB
State or Province Name []:England                                        # Название штата или провинции []:Англия
Locality Name []:                                                        # Название местности []:
Organization Name []:Alice Ltd                                           # Название организации []:ООО Алиса
Organizational Unit Name []:Alice Ltd Certificate Authority              # Название подразделения []:Удостоверяющий центр ООО Алиса
Common Name []:Alice Ltd Intermediate CA                                 # Общее имя []:Промежуточный удостоверяющий центр ООО Алиса
Email Address []:                                                        # Адрес электронной почты []:
Для создания промежуточного сертификата используйте корневой удостоверяющий центр с расширением v3_intermediate_ca, чтобы подписать запрос на подпись сертификата промежуточного удостоверяющего центра. Промежуточный сертификат должен быть действительным на более короткий период, чем корневой сертификат. Десять лет - вполне подходящее значение.
Предупреждение! В этот раз укажите файл конфигурации корневого удостоверяющего центра (/root/ca/openssl.cnf).
# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
  -days 3650 -notext -md sha256 \
  -in intermediate/csr/intermediate.csr.pem \
  -out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword # Введите ключевую фразу для ca.key.pem: секретныйпароль
Sign the certificate? [y/n]: y                   # Подписать сертификат? [д/н]: д
# chmod 444 intermediate/certs/intermediate.cert.pem
В файле index.txt инструмент ca (удостоверяющие центры) из OpenSSL размещает базу данных сертификатов. Не удаляйте этот файл и не редактируйте его вручную. Теперь он должен содержать строку, указывающую на промежуточный сертификат.
V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA # V 250408122707Z 1000 неизвестно ... /CN=Промежуточный удостоверяющий центр ООО Алиса
Проверка промежуточного сертификата

Как и в случае корневого сертификата, проверим, что данные промежуточного сертификата верны.
# openssl x509 -noout -text \
  -in intermediate/certs/intermediate.cert.pem
Проверим промежуточный сертификат корневым сертификатом. OK обозначает, что цепочка доверия не повреждена.
# openssl verify -CAfile certs/ca.cert.pem \
  intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
Создание файла цепочки сертификатов

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

Чтобы создать цепочку сертификата удостоверяющего центра, соединим вместе последовательно промежуточный и корневой сертификат. Этот файл в дальнейшем будет использоваться для проверки сертификатов, подписанных промежуточным удостоверяющим центром.
# cat intermediate/certs/intermediate.cert.pem \
  certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
Замечание. Файл цепочки сертификатов должен включать корневой сертификат, поскольку приложение клиента ещё не знает о нём. Возможно лучшее решение, если вы администрируете локальную сеть - установить корневой сертификат каждому клиенту, который будет подключаться. В этом случае файл цепочки должен содержать только промежуточный сертификат.

воскресенье, 11 декабря 2016 г.

Создание корневой пары

Перевод: Create the root pair
Автор: Джэми Нгуен (Jamie Nguyen)

Работа в качестве удостоверяющего центра (CA) подразумевает использование криптографических пар приватных ключей и публичных сертификатов. Самая первая криптографическая пара, которую мы создадим - это корневая пара. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует удостоверение удостоверяющего центра.

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

Замечание. Лучшей практикой считается создание корневой пары в безопасной среде. Лучше всего, если это будет полностью зашифрованный компьютер, постоянно отключенный от Интернета. Лучше даже изъять из него беспроводные карты и залить клеем Ethernet-порты.
Подготовка каталога

Выберем каталог (/root/ca) для хранения всех ключей и сертификатов.
# mkdir /root/ca
Создадим структуру каталогов. Файлы index.txt и serial выступают в роли плоской базы данных для отслеживания подписанных сертификатов.
# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Подготовка файла конфигурации

Нужно создать файл конфигурации, который будет использоваться OpenSSL. Скопируем файл конфигурации корневого удостоверяющего центра из Приложения А в файл /root/ca/openssl.cnf.

Раздел [ca] обязателен. Здесь мы сообщаем OpenSSL, что нужно использовать опции из раздела [CA_default].
[ca]
# `man ca`
default_ca = CA_default
Раздел [CA_default] содержит набор значений по умолчанию. Убедитесь, что указан выбранный ранее каталог (/root/ca).
[CA_default]
# Местонахождение каталогов и файлов
dir              = /root/ca
certs            = $dir/certs
crl_dir          = $dir/crl
new_certs_dir    = $dir/newcerts
database         = $dir/index.txt
serial           = $dir/serial
RANDFILE         = $dir/private/.rand

# Корневой ключ и корневой сертификат
private_key      = $dir/private/ca.key.pem
certificate      = $dir/certs/ca.cert.pem

# Настройки списков отозванных сертификатов
crlnumber        = $dir/crlnumber
crl              = $dir/crl/ca.crl.pem
crl_extensions   = crl_ext
default_crl_days = 30

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md       = sha256

name_opt         = ca_default
cert_opt         = ca_default
default_days     = 375
preserve         = no
policy           = policy_strict
Мы применим строгую политику policy_strict для всех подписей корневого удостоверяющего центра, потому что корневой удостоверяющий центр используется только для создания промежуточных удостоверяющих центров.
[policy_strict]
# Корневой удостоверяющий центр должен подписывать только соответствующие промежуточные сертификаты
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = match
stateOrProvinceName    = match
organizationName       = match
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional
Мы применим свободную политику policy_loose для всех подписей промежуточных удостоверяющих центров, потому что промежуточные удостоверяющие центры подписывают сертификаты серверов и клиентов, которые могут поступать от разнообразных сторонних лиц.
[policy_loose]
# Разрешим промежуточному удостоверяющему центру подписывать более широкий диапазон сертификатов
# Обратитесь к разделу ФОРМАТ ПОЛИТИКИ из `man ca`
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional
Опции из раздела [req] применяются при создании сертификатов или запросов на подпись сертификата.
[req]
# Опции утилиты `req` (`man req`)
default_bits       = 2048
distinguished_name = req_distinguished_name
string_mask        = utf8only

# SHA-1 устарел, поэтому используем вместо него SHA-2
default_md         = sha256

# Расширения, добавляемые при использовании опции -x509
x509_extensions    = v3_ca
Раздел [req_distinguished_name] объявляет информацию обычно требуемую в запросе на подпись сертификата. Можно указать дополнительные значения по умолчанию.
[req_distinguished_name]
# Обратитесь к https://en.wikipedia.org/wiki/Certificate_signing_request
countryName                     = Название страны (двухбуквенный код)
stateOrProvinceName             = Название штата или провинции
localityName                    = Название местности
0.organizationName              = Название организации
organizationalUnitName          = Название подразделения организации
commonName                      = Общее имя
emailAddress                    = Адрес электронной почты

# На выбор, можно указать несколько значений по умолчанию
countryName_default             = GB
stateOrProvinceName_default     = England
localityName_default            =
0.organizationName_default      = Alice Ltd
#organizationalUnitName_default =
#emailAddress_default           =
Следующие несколько разделов - это расширения, которые могут быть применены при подписывании сертификатов. Например, передача аргумента командной строки -extensions v3_ca применит опции из набора в разделе [v3_ca].

При создании корневого сертификата применим расширение v3_ca.
[v3_ca]
# Расширения для типичного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign
При создании промежуточного сертификата применим расширение v3_ca_intermediate. pathlen:0 гарантирует, что у промежуточного удостоверяющего центра не будет дочерних промежуточных удостоверяющих центров.
[v3_intermediate_ca]
# Расширения для типичного промежуточного удостоверяющего центра (`man x509v3_config`)
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints       = critical, CA:true, pathlen:0
keyUsage               = critical, digitalSignature, cRLSign, keyCertSign
Расширение usr_cert будем применять при подписании клиентских сертификатов, которые будут использоваться для аутентификации удалённых пользователей.
[usr_cert]
# Расширения для клиентских сертификатов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = client, email
nsComment              = "Сертификат клиента создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage       = clientAuth, emailProtection
Применим расширение server_cert при подписании сертификатов серверов, например, используемых веб-серверами.
[server_cert]
# Расширения для сертификатов серверов (`man x509v3_config`)
basicConstraints       = CA:FALSE
nsCertType             = server
nsComment              = "Сертификат сервера создан OpenSSL"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage               = critical, digitalSignature, keyEncipherment
extendedKeyUsage       = serverAuth
Расширение crl_ext применяется автоматически при создании списков отозванных сертификатов.
[crl_ext]
# Расширение для списков отозванных сертификатов (`man x509v3_config`)
authorityKeyIdentifier = keyid:always
Применим расширение ocsp при подписании сертификата для протокола интерактивного статуса сертификата (Online Certificate Status Protocol - OCSP).
[ocsp]
# Расширение для подписи сертификатов OCSP (`man ocsp`)
basicConstraints       = CA:FALSE
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer
keyUsage               = critical, digitalSignature
extendedKeyUsage       = critical, OCSPSigning
Создание корневого ключа

Создадим корневой ключ (ca.key.pem) и сохраним его в полной безопасности. Злоумышленник, заполучивший корневой ключ, сможет выпускать доверенные сертификаты. Зашифруйте корневой ключ при помощи 256-битного шифрования AES и сильного пароля.
Замечание. Используйте 4096 бит для всех корневых и промежуточных ключей удостоверяющих центров. Вы по-прежнему сможете подписывать сертификаты серверов и клиентов более короткой длины.
# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
Enter pass phrase for ca.key.pem: secretpassword             # Введите ключевую фразу для ca.key.pem: секретныйпароль
Verifying - Enter pass phrase for ca.key.pem: secretpassword # Проверка - Введите ключевую фразу для ca.key.pem: секретныйпароль
# chmod 400 private/ca.key.pem
Создание корневого сертификата

Воспользуемся корневым ключом (ca.key.pem) для создания корневого сертификата (ca.cert.pem). Примем срок действия корневого сертификата достаточно длинным, например - двенадцать лет. По истечении срока действия корневого сертификата все сертификаты, подписанные этим удостоверяющим центром, станут недействительными.
Предупреждение! При каждом использовании утилиты req нужно указывать используемый файл конфигурации с помощью опции -config, в противном случае OpenSSL будет использовать файл по умолчанию /etc/pki/tls/openssl.cnf.
# cd /root/ca
# openssl req -config openssl.cnf \
  -key private/ca.key.pem \
  -new -x509 -days 7300 -sha256 -extensions v3_ca \
  -out certs/ca.cert.pem
Enter pass phrase for ca.key.pem: secretpassword                         # Введите ключевую фразу для ca.key.pem: секретныйпароль
You are about to be asked to enter information that will be incorporated # У вас будет запрошена информация, которая будет вставлена
into your certificate request.                                           # в ваш запрос сертификата.
-----
Country Name (2 letter code) [XX]:GB                                     # Название страны (двухбуквенный код) [XX]:GB
State or Province Name []:England                                        # Название штата или провинции []:Англия
Locality Name []:                                                        # Название местности []:
Organization Name []:Alice Ltd                                           # Название организации []:ООО Алиса
Organizational Unit Name []:Alice Ltd Certificate Authority              # Название подразделения []:Удостоверяющий центр ООО Алиса
Common Name []:Alice Ltd Root CA                                         # Общее имя []:Корневой удостоверяющий центр ООО Алиса
Email Address []:                                                        # Адрес электронной почты []:
# chmod 444 certs/ca.cert.pem
Проверка корневого сертификата
# openssl x509 -noout -text -in certs/ca.cert.pem
В выводе будут отображены:
  • используемый алгоритм подписания,
  • даты действия сертификата,
  • битовая длина публичного ключа,
  • эмитент, который подписал этот сертификат,
  • субъект, который относится к этому сертификату.
Эмитент и субъект идентичны в случае самозаверенного сертификата. Отметим, что все корневые сертификаты являются самозаверенными.
Signature Algorithm: sha256WithRSAEncryption                  # Алгоритм подписания: sha256WithRSAEncryption
    Issuer: C=GB, ST=England,                                 #     Эмитент: C=GB, ST=Англия,
            O=Alice Ltd, OU=Alice Ltd Certificate Authority,  #              O=ООО Алиса, OU=Удостоверяющий центр ООО Алиса,
            CN=Alice Ltd Root CA                              #              CN=Корневой удостоверяющий центр ООО Алиса
    Validity                                                  #     Действительность
        Not Before: Apr 11 12:22:58 2015 GMT                  #         Не ранее: 11 апреля 2015 года в 12:22:58 по Гринвичу
        Not After : Apr 6 12:22:58 2035 GMT                   #         Не позднее: 6 апреля 2035 года 12:22:58 по Гринвичу
    Subject: C=GB, ST=England,                                #     Субъект: C=GB, ST=Англия,
             O=Alice Ltd, OU=Alice Ltd Certificate Authority, #              O=ООО Алиса, OU=Удостоверяющий центр ООО Алиса,
             CN=Alice Ltd Root CA                             #              CN=Корневой удостоверяющий центр ООО Алиса
    Subject Public Key Info:                                  #     Информация публичного ключа субъекта:
        Public Key Algorithm: rsaEncryption                   #         Алгоритм публичного ключа: rsaEncryption
            Public-Key: (4096 bit)                            #             Публичный ключ: (4096 бит)
В выводе также отображаются расширения X509v3. Мы применили расширение v3_ca, поэтому в выводе должны отобразиться опции из [v3_ca].
X509v3 extensions:                                    # Расширения X509v3:
    X509v3 Subject Key Identifier:                    #     Идентификатор ключа субъекта X509v3:
        38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
    X509v3 Authority Key Identifier:                  #     Идентификатор ключа подлинности X509v3:
        keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31

    X509v3 Basic Constraints: critical                #     Базовые ограничения X509v3: критично
        CA:TRUE
    X509v3 Key Usage: critical                        #     Использование ключа X509v3: критичное
        Digital Signature, Certificate Sign, CRL Sign #         Цифровая подпись, подписание сертификата, подписание списка отозванных сертификатов

воскресенье, 4 декабря 2016 г.

Удостоверяющий центр OpenSSL

Перевод: OpenSSL Certificate Authority
Автор: Джэми Нгуен (Jamie Nguyen)

В этом руководстве рассматривается работа с вашим собственным удостоверяющим центром (CA - Certificate Authority) при помощи инструментов командной строки OpenSSL. С его помощью можно решать такие задачи как выпуск сертификатов серверов для защиты веб-сайта в локальной сети или выпуск сертификатов клиентов для их аутентификации на сервере.

Введение

воскресенье, 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:                                                                                    # Расширения ответа
Источники

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

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

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

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

Больше о CRL можно прочитать на Википедии.

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

Воспользуемся OpenSSL. Я использую такую версию:
$ openssl version
OpenSSL 1.0.2 22 Jan 2015
Получение сертификата с CRL

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

openssl s_client -connect wikipedia.org:443 2>&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 CRL:
openssl x509 -noout -text -in wikipedia.pem | grep -A 4 'X509v3 CRL Distribution Points'
X509v3 CRL Distribution Points: # Точки распространения X509v3 CRL
    Full Name:                                                                           # Полное имя
      URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
Если ничего не выведено, значит у сертификата нет URI CRL. Его нельзя проверить по CRL.

Скачиваем CRL:
wget -O crl.der http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
CRL имеет двоичный формат DER. Команде OpenSSL нужен файл в формате PEM (base64-кодированный DER), поэтому преобразуем его:
openssl crl -inform DER -in crl.der -outform PEM -out crl.pem
Получение цепочки сертификатов

Кроме проверяемого сертификата нужна цепочка сертификатов. Поэтому нужно получить цепочку сертификатов для проверяемого домена - 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.

Можно использовать следующую команду для сохранения всех сертификатов, выведенных командой OpenSSL, в файл с именем chain.pem. Обратитесь к этой статье за более подробной информацией.
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect wikipedia.org:443 -showcerts -tlsextdebug -tls1 2>&1 < /dev/null \
                         | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
  echo $certificate | tee -a chain.pem ; \
done; \
IFS=$OLDIFS
Объединение CRL и цепочки

Команде openssl для проверки нужны цепочка сертификатов и CRL в формате PEM, соединённые вместе. Можно пропустить CRL, но тогда проверка по CRL не будет выполнена, произойдёт проверка только сертификата по цепочке.
cat chain.pem crl.pem > crl_chain.pem
Проверка OpenSSL
Теперь у нас есть все данные, необходимые для проверки сертификата.
$ openssl verify -crl_check -CAfile crl_chain.pem wikipedia.pem
wikipedia.pem: OK
Результат показывает, что сертификат действительный.

Отозванный сертификат

Если имеется отозванный сертификат, его так же можете проверить способом, описанным выше. Ответ будет выглядеть следующим образом:
$ openssl verify -crl_check -CAfile crl_chain.pem revoked-test.pem
revoked-test.pem: OU = Domain Control Validated, OU = PositiveSSL, CN = xs4all.nl
error 23 at 0 depth lookup:certificate revoked                                    # ошибка 23 на 0 глубине поиска: сертификат отозван
Имея сертификат и цепочку, эти проверки можно выполнить странице Verisign для проверки отозванных сертификатов: https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.

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

Команды OpenSSL для преобразования сертификатов на своём компьютере

Перевод: SSL Converter

Воспользуйтесь этим преобразователем SSL для преобразования сертификатов SSL между различными форматами, такими как pem, der, p7b и pfx.

Разные платформы и устройства требуют преобразовывать сертификаты SSL в разные форматы. Например, Windows-сервер экспортирует и импортирует файлы .pfx, а сервер Apache использует отдельные файлы PEM (.crt, .cer). Чтобы воспользоваться преобразователем SSL, просто выберите файл сертификата и его текущий тип (произойдёт попытка определить тип по расширению файла), затем выберите тип, в который нужно преобразовать сертификат и нажмите Преобразовать сертификат. Подробности о различных типах сертификатов SSL и о том, как можно преобразовать сертификаты на своём компьютере с помощью OpenSSL, смотрите ниже.

Формат PEM

Формат PEM - наиболее распространённый формат сертификатов, выпускаемых удостоверяющими центрами. Сертификаты PEM обычно имеют расширения .pem, .crt, .cer и .key. Это ASCII-файлы с информацией, закодированной в Base64, и содержащие выражения "-----BEGIN CERTIFICATE-----" и "-----END CERTIFICATE-----". Сертификаты сервера, промежуточные сертификаты и приватные ключи могут быть записаны в формате PEM.

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

Формат DER

Формат DER - это просто двоичный вид сертификата, в отличие от PEM, который закодирован в символы ASCII. Иногда встречается расширение файла .der, но чаще у файла бывает расширение .cer. Чтобы узнать, имеет ли этот файл формат DER или PEM, можно открыть его в текстовом редакторе и поискать выражения BEGIN и END. Все типы сертификатов и приватных ключей могут быть представлены в формате DER. Обычно DER используется на платформе Java. Инструмент для преобразования SSL умеет преобразовывать в формат DER только сертификаты. Если нужно преобразовать в формат DER приватный ключ, воспользуйтесь командами OpenSSL, приведёнными на этой странице.

Формат PKCS#7/P7B

Формат PKCS#7 или P7B обычно сохраняется в виде ASCII, закодированным в Base64, и имеет расширение .p7b или .p7c. Сертификаты P7B содержат выражения "-----BEGIN PKCS7-----" и "-----END PKCS7-----". Файл P7B содержит только сертификаты и цепочки сертификатов, но не приватные ключи. Некоторые платформы поддерживают файлы P7B, в том числе Microsoft Windows и Java Tomcat.

Формат PKCS#12/PFX

Формат PKCS#12 или PFX - это двоичный формат для хранения сертификата сервера, промежуточных сертификатов и приватного ключа в одном зашифрованном файле. Файлы PFX обычно имеют расширение .pfx или .p12. Файлы PFX обычно используются на компьютерах под управлением Windows для импорта и экспорта сертификатов и приватных ключей.

При преобразовании файла PFX в формат PEM, OpenSSL поместит все сертификаты и приватный ключ в один файл. Для этого нужно открыть файл в текстовом редакторе и скопировать каждый сертификат и приватный ключ (включая выражения BEGIN/END) в отдельные текстовые файлы и сохранить их под именами certificate.cer, CACert.cer и privateKey.key соответственно.

Команды OpenSSL для преобразования сертификатов SSL на своём компьютере

Настоятельно рекомендуется преобразовывать файлы .pfx на своём компьютере с помощью OpenSSL. Это позволит сохранить приватный ключ в тайне. Воспользуйтесь следующими командами OpenSSL для преобразования сертификата SSL в различные форматы на своём компьютере:

Преобразование PEM с помощью OpenSSL
  • Преобразование PEM в DER:
    openssl x509 -outform der -in certificate.pem -out certificate.der
  • Преобразование PEM в P7B:
    openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
  • Преобразование PEM в PFX:
    openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Преобразование DER с помощью OpenSSL
  • Преобразование DER в PEM:
    openssl x509 -inform der -in certificate.cer -out certificate.pem
Преобразование P7B с помощью OpenSSL
  • Преобразование P7B в PEM:
    openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
  • Преобразование P7B в PFX:
    openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
    openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
Преобразование PFX с помощью OpenSSL
  • Преобразование PFX в PEM:
    openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

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

Наиболее часто используемые команды OpenSSL

Перевод: The Most Common OpenSSL Commands

Одна из наиболее многофункциональных утилит SSL - это OpenSSL, которая является реализацией протокола SSL с открытым исходным кодом. Существуют версии OpenSSL почти для каждой платформы, включая Windows, Linux и Mac OS X. OpenSSL чаще всего используется для создания запросов на подпись сертификата и приватных ключей для множества различных платформ, включая Apache. Однако, есть ещё сотни различных функций, которые позволяют увидеть информацию из запроса на сертификат или из сертификата, сравнить хэш MD5 сертификата и приватного ключа (чтобы убедиться в том, что они соответствуют друг другу), проверить, что сертификат веб-сайта установлен правильно, преобразовать сертификат в другой формат. Скомпилированную версию OpenSSL для Windows можно найти здесь.

Если вам не хочется разбираться с OpenSSL, то многое из этого можно сделать при помощи наших инструментов для сертификатов SSL. Ниже мы привели наиболее часто используемые команды OpenSSL:

Общие команды OpenSSL

Эти команды позволят вам сгенерировать запрос на подпись сертификата, сертификат, приватный ключ и решить другие задачи.
  • Создание нового приватного ключа и запроса на подпись сертификата:
    openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
  • Создание самозаверяющего сертификата (за дополнительной информацией обратитесь к статье Как создать и установить самозаверяющий сертификат в Apache):
    openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
  • Создание запроса на подпись сертификата для существующего приватного ключа:
    openssl req -out CSR.csr -key privateKey.key -new
  • Создание запроса на подпись сертификата на основе имеющегося сертификата:
    openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
  • Удаление ключевой фразы из приватного ключа:
    openssl rsa -in privateKey.pem -out newPrivateKey.pem
Проверка при помощи OpenSSL

Если нужно проверить информацию в сертификате, в запросе на подпись сертификата или в приватном ключе, воспользуйтесь следующими командами. Также можно проверить запрос на подпись сертификата и проверить сертификат с помощью наших интерактивных инструментов.
  • Проверка запроса на подпись сертификата:
    openssl req -text -noout -verify -in CSR.csr
  • Проверка приватного ключа:
    openssl rsa -in privateKey.key -check
  • Проверка сертификата:
    openssl x509 -in certificate.crt -text -noout
  • Проверка файла PKCS#12 (.pfx или .p12):
    openssl pkcs12 -info -in keyStore.p12
Отладка с помощью OpenSSL

При получении сообщения об ошибке, что приватный ключ не соответствует сертификату или что сертификат, установленный на веб-сайт, не заслуживает доверия, попробуйте одну из следующих команд. Если нужно проверить, правильно ли установлен этот сертификат SSL, попробуйте также наш инструмент для проверки SSL.
  • Проверить, что хэш MD5 публичного ключа соответствует указанному в запросе на подпись сертификата или в приватном ключе:
    openssl x509 -noout -modulus -in certificate.crt | openssl md5
    openssl rsa -noout -modulus -in privateKey.key | openssl md5
    openssl req -noout -modulus -in CSR.csr | openssl md5
  • Проверить подключение SSL. Должны отобразиться все сертификаты (включая промежуточные):
    openssl s_client -connect www.paypal.com:443
Преобразование с помощью OpenSSL

Эти команды позволяют преобразовать сертификаты и ключи в различные форматы, совместимые с определёнными типами серверов и программного обеспечения. Например, можно преобразовать обычный файл PEM, который используется с Apache, в файл PFX (PKCS#12) и использовать его с Tomcat или IIS. Воспользуйтесь нашим инструментом для преобразования SSL, чтобы преобразовать сертификаты без помощи OpenSSL.
  • Преобразование файла DER (.crt .cer .der) в PEM:
    openssl x509 -inform der -in certificate.cer -out certificate.pem
  • Преобразование файлов PEM в DER:
    openssl x509 -outform der -in certificate.pem -out certificate.der
  • Преобразование файла PKCS#12 (.pfx .p12), содержащего приватный ключ и сертификат, в PEM:
    openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes
    Можно добавить опцию -nocerts, чтобы вывести только приватный ключ, или опцию -nokeys, чтобы вывести только сертификат.
  • Преобразование файла сертификата и приватного ключа PEM в PKCS#12 (.pfx .p12):
    openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt