Что такое CSR и как его получить?

Что такое gpg

gpg — это инструмент шифрования и электронного подписывания. В его работе используется ассиметричное шифрование, основанное на двух ключах: приватный и публичный. Приватный ключ иногда называют секретным. А публичный ключ называют открытым.

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

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

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

• вы шифруете свои сообщения публичным ключом вашего собеседника и отправляете ему
• он с помощью своего приватного ключа читает эти сообщения
• ваш собеседник шифрует свои сообщения вашим публичным ключом и отправляет вам
• вы с помощью своего приватного ключа читаете свои сообщения
• и так далее

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

Итак, gpg — это OpenPGP часть GNU Privacy Guard (GnuPG). Этот инструмент обеспечивает цифровое шифрование и службы подписи используя стандарт OpenPGP. gpg имеет функции полного управления ключами, а также все приблуды, которые вы можете ожидать от реализации OpenPGP.

Что такое csr и как его получить?

Как выпустить самоподписанный ssl сертификат и заставить ваш браузер доверять ему

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2021 года.

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

Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.
Сначала сформируем закрытый ключ:

openssl genrsa -out rootCA.key 2048

Затем сам сертификат:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Нужно будет ввести

страну

,

город

,

компанию

и т.д. В результате получаем два файла:

rootCA.key

и

rootCA.pem

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

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

if [ -z "$1" ]
then
  echo "Please supply a subdomain to create a certificate for";
  echo "e.g. mysite.localhost"
  exit;
fi

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

if [ -f device.key ]; then
  KEY_OPT="-key"
else
  KEY_OPT="-keyout"
fi

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

DOMAIN=$1
COMMON_NAME=${2:-$1}

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME"
NUM_OF_DAYS=999

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (

страна

,

город

,

компания

и т.д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr

Формируем файл сертификата

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

v3.ext

. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%
DNS.2 = *.%%DOMAIN%%

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

v3.ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

cat v3.ext | sed s/%%DOMAIN%%/$COMMON_NAME/g > /tmp/__v3.ext

Выпускаем сертификат:

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext

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

mv device.csr $DOMAIN.csr
cp device.crt $DOMAIN.crt

# remove temp file
rm -f device.crt;

Скрипт готов. Запускаем его:

./create_certificate_for_domain.sh mysite.localhost

Получаем два файла:

mysite.localhost.crt

и

device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.

Про сертификаты:  SSL из PHP: socket и cURL / Хабр

Делитесь в комментариях, используете ли вы https для локальной разработки?

Максим Ковтун,
Руководитель отдела разработки

Как генерировать сертификаты в openssl

На самом деле, приватный ключ веб-сервера и приватный ключ Центр Сертификации (CA) по своей природе ничем не отличаются — они генерируются одной и той же командой. Но Центр Сертификации (CA) имеет особый статус постольку:

1. Его приватный ключ используется для подписи сертификатов (поэтому он называется корневым, хотя в физическом смысле не отличается от приватного ключа сервера)
2. Его публичный ключ (сертификат) добавлен на компьютеры всех пользователей в качестве доверенного
3. Цифровая подпись в сертификате не предназначена для проверки третьей стороной, поскольку сертификат является самоподписанным. Единственное отличие самоподписанного сертификата из Центр Сертификации (CA) от того, который вы можете сгенерировать сами, в том, что он у вас размещён среди доверенных (в операционной системе или в браузере). Вы можете самостоятельно созданный самоподписанный сертификат разместить среди доверенных, и он будет иметь точно такую же силу как и корневой сертификат из Центр Сертификации (CA)

Вернёмся к процедуре подписи, а фактически создания сертификата сервера — создаваемый сертификат должен быть криптографически связан с приватным ключом сервера. Но приватный ключ должен быть известен исключительно его владельцу (серверу). Выходом из данной ситуации является использования уже упомянутого Certificate Signing Request (CSR), то есть «запроса на подпись сертификата».

В учебных целях вы можете создать свои корневые ключи и даже свой «Центр Сертификации (CA)». Затем создадим пару приватный и публичный ключ сервера. Используя ключ сервера мы создадим запрос на подпись сертификата (CSR). Приватным ключом CA мы подпишем (создадим) сертификат для сервера.

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

Как добавить корневой сертификат в доверенные в linux в веб браузеры

Chrome, Chromium, Firefox и созданные на их основе веб браузеры доверяют корневым сертификатам, установленным на уровне системы. То есть вам достаточно добавить в доверенные CA сертификат как это показано в предыдущем разделе.

Причём эти браузеры хотя и используют NSS, они игнорируют общесистемные сертификаты NSS, которые можно добавить в файл /etc/pki/nssdb!

Тем не менее приложения, которые используют NSS (такие как Firefox, Thunderbird, Chromium, Chrome) хранят свои списки доверенных сертификатов в файлах cert9.db. Чтобы добавить свой сертификат в каждый из этих файлов можно использовать скрипт.

Сохранить следующий код в файл CAtoCert9.sh:

#!/bin/bash

certfile="root.cert.pem"
certname="My Root CA"

for certDB in $(find ~/ -name "cert9.db")
do
	certdir=$(dirname ${certDB});
	certutil -A -n "${certname}" -t "TCu,Cu,Tu" -i ${certfile} -d sql:${certdir}
done

В этом файле измените значение certfile на имя файла вашего сертификата и значение certname на имя вашего сертификата, сохраните и закройте файл.

Затем запустите его следующим образом:

bash ./CAtoCert9.sh

В результате в домашней папке пользователя будут найдены все файлы cert9.db и в каждый из них будет добавлен указанный CA сертификат.

Вы можете добавить CA сертификаты в графическом интерфейсе каждого браузера.

• В настройках Chrome: Конфиденциальность и безопасность → Безопасность → Настроить сертификаты → Центры сертификации
• В настройках Chromium: Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации

Нажмите кнопку «Импорт»:

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

• В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Нажмите кнопку «Импортировать»:

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

Как пользоваться openssl (команды openssl)

Команды OpenSSL не столько сложные, сколько запутанные.

Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.

Синтаксис использования команд OpenSSL:

openssl КОМАНДА ОПЦИИ

Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.

Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:

man openssl-КОМАНДА
# ИЛИ
man КОМАНДА

Например:

man openssl-req
man openssl-x509
man openssl-genpkey
man openssl-enc
man openssl-rsa
# ИЛИ
man req
man x509
man genpkey
man enc
man rsa

При этом если по аналогии попытаться использовать в командной строке openssl-req или req, то такие команды будет не найдены (нужно использовать openssl req …).

Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.

На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.

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

• genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
• req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
• x509 — утилита для подписи сертификатов и для показа свойств сертификатов
• rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
• enc — различные действий с симметричными шифрами
• pkcs12 — создаёт и парсит файлы PKCS#12
• crl2pkcs7 — программа для конвертирования CRL в PKCS#7
• pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
• verify — программа для проверки цепей сертификатов
• s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
• ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
• rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
• rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
• smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME

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

openssl list -commands

Пример вывода:

asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dhparam           
dsa               dsaparam          ec                ecparam           
enc               engine            errstr            gendsa            
genpkey           genrsa            help              list              
nseq              ocsp              passwd            pkcs12            
pkcs7             pkcs8             pkey              pkeyparam         
pkeyutl           prime             rand              rehash            
req               rsa               rsautl            s_client          
s_server          s_time            sess_id           smime             
speed             spkac             srp               storeutl          
ts                verify            version           x509

Общесистемные корневые ca сертификаты

Если вы задаётесь вопросом, в какой папке хранятся сертификаты в Windows, то правильный ответ в том, что в Windows сертификаты хранятся в реестре. Причём они записаны в виде бессмысленных бинарных данных. Чуть ниже будут перечислены ветки реестра, где размещены сертификаты, а пока давайте познакомимся с программой для просмотра и управления сертификатами в Windows.

В Windows просмотр и управление доверенными корневыми сертификатами осуществляется в программе Менеджер Сертификатов.

Чтобы открыть Менеджер Сертификатов нажмите Win r, введите в открывшееся поле и нажмите Enter:

certmgr.msc

Перейдите в раздел «Доверенные корневые центры сертификации» → «Сертификаты»:

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

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

Чтобы просмотреть список сертификатов с помощью PowerShell:

Get-ChildItem cert:LocalMachineroot | format-list

Чтобы найти определённый сертификат выполните команду вида (замените «HackWare» на часть искомого имени в поле Subject):

Get-ChildItem cert:LocalMachineroot | Where {$_.Subject -Match "HackWare"} | format-list

Теперь рассмотрим, где физически храняться корневые CA сертификаты в Windows. Сертификаты хранятся в реестре Windows в следующих ветках:

Сертификаты уровня пользователей:

Сертификаты уровня компьютера:

• HKEY_LOCAL_MACHINESoftwareMicrosoftSystemCertificates — содержит настройки для всех пользователей компьютера
• HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificates — как и предыдущее расположение, но это соответствует сертификатам компьютера, развёрнутым объектом групповой политики (GPO (Group Policy))

Сертификаты уровня служб:

• HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyServicesServiceNameSystemCertificates — содержит настройки сертификатов для всех служб компьютера

Сертификаты уровня Active Directory:

• HKEY_LOCAL_MACHINESoftwareMicrosoftEnterpriseCertificates — сертификаты, выданные на уровне Active Directory.

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

Пользовательские сертификаты (файлы):

Компьютерные сертификаты (файлы):

• C:ProgramDataMicrosoftCryptoRSAMachineKeys

Рассмотрим теперь где хранятся корневые CA сертификаты веб-браузеров.

Откуда берутся сертификаты?

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

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

   

2. Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
3. Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

И подписываем.

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

Конвертируем связку ключей из проприетарного формата в PKCS12.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

Смотрим на результат:

Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
     MD5:  B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
     SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
     SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D

Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB   92 44 9D 95 47 94 E4 97  0.X..v...D..G...
0010: C8 1E F1 92                                        ....
]
]

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

subjectKeyIdentifier EXTENSION ::= {
    SYNTAX SubjectKeyIdentifier
    IDENTIFIED BY id-ce-subjectKeyIdentifier
}

SubjectKeyIdentifier ::= KeyIdentifier

Редактирования ключей gpg

Для редактирования ключа определённого пользователя выполните команду (замените ‘Alexey Miloserdov’ на желаемый идентификатор пользователя):

gpg --edit-key 'Alexey Miloserdov'

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

quit        выйти из этого меню
save        сохранить и выйти
help        показать данную справку
fpr         показать отпечаток ключа
grip        показать код ключа
list        вывести список ключей и идентификаторов пользователя
uid         выбрать идентификатор пользователя N
key         выбрать подключ N
check       проверка подписей
sign        подписать выбранные идентификаторы пользователя [* описание команд см. ниже]
lsign       локально подписать выбранные идентификаторы пользователя
tsign       подписать выбранные идентификаторы пользователя подписью доверия
nrsign      подписать выбранные идентификаторы пользователя без возможности отзыва
adduid      добавить идентификатор пользователя
addphoto    добавить фотоидентификатор
deluid      удалить выбранные идентификаторы пользователя
addkey      добавить подключ
addcardkey  добавить ключ на криптографическую карту
keytocard   переместить ключ на криптографическую карту
bkuptocard  переместить архивный ключ на криптографическую карту
delkey      удалить выбранные подключи
addrevoker  добавить ключ отзыва
delsig      удалить подписи с выбранных идентификаторов пользователя
expire      сменить срок действия ключа или выбранных подключей
primary     пометить выбранный идентификатор пользователя как первичный
pref        список предпочтений (экспертам)
showpref    список предпочтений (подробный)
setpref     установить список предпочтений для выбранных идентификаторов пользователя
keyserver   установить URL предпочтительного сервера ключей для выбранных идентификаторов пользователя
notation    установить замечание для выбранных идентификаторов пользователя
passwd      сменить фразу-пароль
trust       изменить уровень доверия владельцу
revsig      отозвать подписи у выбранных идентификаторов пользователя
revuid      отозвать выбранные идентификаторы пользователя
revkey      отозвать ключ или выбранные подключи
enable      подключить ключ
disable     отключить ключ
showphoto   показать выбранные фотоидентификаторы
clean       сжать непригодные идентификаторы пользователей и удалить непригодные подписи из ключа
minimize    сжать непригодные идентификаторы пользователей и удалить все подписи из ключа

* У команды 'sign' может быть приставка 'l' (локальные подписи, lsign),
  't' (подписи доверия, tsign), 'nr' (неотзываемые, 
  nrsign) или любое их сочетание (ltsign, tnrsign и т.д.).

Симметричное шифрование файлов в openssl

Данный вид шифрования выполняется командой enc. Кстати она также задействуется при создании ключей, если выбрано их шифрование — это шифрование выполняется с помощью enc.

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

openssl enc -ШИФР -in ДЛЯ-ШИФРОВАНИЯ -out ЗАШИФРОВАНЫЕ-ДАННЫЕ

Для расшифровки похожая команда, но с опцией -d, также ЗАШИФРОВАНЫЕ-ДАННЫЕ теперь являются входными, а на выходе РАСШИФРОВАННЫЕ-ДАННЫЕ:

openssl enc -ШИФР -d -in ЗАШИФРОВАНЫЕ-ДАННЫЕ -out РАСШИФРОВАННЫЕ-ДАННЫЕ

В качестве ШИФРА рекомендуют aes-256-cbc, а полный список шифров вы можете посмотреть командой:

openssl enc -list

Ещё настоятельно рекомендуется использовать опцию -iter ЧИСЛО. Она использует указанное ЧИСЛО итераций для пароля при получении ключа шифрования. Высокие значения увеличивают время, необходимое для взлома пароля брут-форсом зашифрованного файла.

Эта опция включает использование алгоритма PBKDF2 для получения ключа. Указывать можно высокие значения — десятки и сотни тысяч. В разделе «Как создать базу данных KeePass» при создании базы данных используется такой же алгоритм (первая версия), там для 1 секундной задержки я выставлял значение в 25 миллионов инераций.

Пример шифрования файла art.txt шифром aes-256-cbc, зашифрованные данные будут помещены в файл с именем art.txt.enc, при получении ключа шифрования используется десять миллионов итераций (на моём железе выполнение команды заняло несколько секунд):

openssl enc -aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

Введите, а затем подтвердите пароль для шифрования:

В результате будет создан зашифрованный файл art.txt.enc.

Для расшифровки файла art.txt.enc и сохранения данных в файл art-new.txt:

openssl enc -aes-256-cbc -d -in art.txt.enc -out art-new.txt -iter 10000000

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

В случае неудачной расшифровки будет показано примерно следующее:

bad decrypt
140381536523584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:583:

Возможные причины ошибки:

• неверный пароль
• неверный алгоритм для расшифровки
• неправильно указано количество итераций с опцией -iter
• неверно указан файл для расшифровки

Обратите внимание, что для расшифровки также нужно указать опцию -iter с тем же самым значением, которое было указано при шифровании. Конечно, можно не использовать опцию -iter при шифровании (а, следовательно, и при расшифровке), но в этом случае шифрование считается ненадёжным!

Не рекомендуется пропускать опцию. Если у вас слабое железо ИЛИ если файл будет расшифровываться на слабом железе, то вам необязательно использовать такие большие значения -iter — укажите хотя бы десятки или сотни тысяч (например, полмиллиона).

Предыдущие команды для шифрования и расшифровки могут запускаться чуть иначе:

openssl ШИФР

Например:

openssl aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

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

Зашифрованный файл представляет собой бинарные данные, которые не получится передать, например, в текстовом сообщении (в чате). Используя опцию -a (или её псевдоним -base64), можно закодировать зашифрованные данные в кодировку Base64:

openssl enc -aes-256-cbc -in art.txt -out art.txt.b64 -iter 10000000 -a

Содержимое полученного файла art.txt.b64 можно открыть любым текстовым редактором и переслать в мессенджере или в чате.

Для расшифровки также нужно указать опцию -a:

openssl enc -aes-256-cbc -d -in art.txt.b64 -out art-new.txt -iter 10000000 -a

Чтобы просто закодировать бинарный файл в кодировку base64:

openssl enc -base64 -in file.bin -out file.b64

Чтобы раскодировать этот файл:

openssl enc -base64 -d -in file.b64 -out file.bin

Чтобы зашифровать файл используя указанный ПАРОЛЬ в команде (не интерактивный режим):

openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt -pass pass:ПАРОЛЬ

Зашифровать файл, затем закодировать его с помощью base64 (например, его можно отправить по почте), используя AES-256 в режиме CTR и с получением производной ключа PBKDF2:

openssl enc -aes-256-ctr -pbkdf2 -a -in file.txt -out file.aes256

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

openssl enc -aes-256-ctr -pbkdf2 -d -a -in file.aes256 -out file.txt -pass file:<ФАЙЛ-С-ПАРОЛЕМ>

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.

Файлы gpg

Имеется несколько конфигурационных файлов для контроля определённых аспектов операций gpg. Если не сказано другое, ожидается что они размещены в домашней директории текущего пользователя.

gpg.conf

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

~/.gnupg

Это домашняя папка по умолчанию, которая используется если не установлено другое в переменной окружения GNUPGHOME или опцией –homedir.

~/.gnupg/pubring.gpg

Публичный киринг (public keyring). Следует иметь резервную копию этого файла

~/.gnupg/pubring.gpg.lock

Файл блокировки для публичного киринга.

~/.gnupg/pubring.kbx

Публичный киринг использует различные форматы. Этот файл поделён с gpgsm. Следует иметь резервную копию этого файла. Фактически, это база данных, где хранятся все ключи. Структуру этого файла можно посмотреть командой:

kbxutil ~/.gnupg/pubring.kbx

~/.gnupg/pubring.kbx.lock

Файл блокировки для ‘pubring.kbx’.

~/.gnupg/secring.gpg

Секретный киринг используемой GnuPG версией до 2.1. Он не используется GnuPG 2.1 и более поздними.

~/.gnupg/secring.gpg.lock

Файл блокировки для секретного киринга.

~/.gnupg/.gpg-v21-migrated

Файл, показывающий, что сделан переход на GnuPG 2.1.

~/.gnupg/trustdb.gpg

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

~/.gnupg/trustdb.gpg.lock

Файл блокировки для доверенной базы данных.

~/.gnupg/random_seed

Файл, используемый для сохранения состояния внутреннего пула случайных чисел.

~/.gnupg/openpgp-revocs.d/

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

Форматы ключей и сертификатов

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

Бинарный (DER) сертификат

Содержит сертификат X.509 в необработанном виде с использованием кодировки DER ASN.1.

ASCII (PEM) сертификат(ы)

Содержит сертификат DER в кодировке base64, в котором —–BEGIN CERTIFICATE—– используется в качестве заголовка, а —–END CERTIFICATE—– в качестве нижнего колонтитула. Обычно встречается только с одним сертификатом на файл, хотя некоторые программы допускают более одного сертификата в зависимости от контекста.

Двоичный (DER) ключ

Содержит закрытый ключ в необработанном виде с использованием кодировки DER ASN.1. OpenSSL создаёт ключи в своём собственном традиционном (SSLeay) формате. Существует также альтернативный формат, называемый PKCS#8 (определённый в RFC 5208), но он не используется широко. OpenSSL может конвертировать в и из формата PKCS#8 с помощью команды pkcs8.

ASCII (PEM) ключ

Содержит ключ DER в кодировке base64, иногда с дополнительными метаданными (например, алгоритм, используемый для защиты паролем).

Сертификат PKCS#7

Сложный формат, предназначенный для транспортировки подписанных или зашифрованных данных, определённый в RFC 2315. Он обычно встречается с расширениями .p7b и .p7c и может при необходимости включать всю цепочку сертификатов.

PKCS#12 (PFX) ключ и сертификат(ы)

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

Шифрование файлов и данных с gpg

Про шифрование в gpg нужно знать, что оно может быть:

• ассиметричным (шифруется публичным ключом, расшифровывается приватным)
• симметричным (шифруется и расшифровывается приватным ключом, шифруется и расшифровывается одной и той же парольной фразой)

Второе, что нужно знать: шифрование можно совмещать с подписыванием файла. Подписывание файла и проверку подписи мы рассмотрим далее. Также далее мы рассмотрим одновременное шифрование и подпись файла.

Третье: зашифровать можно одним или более публичными ключами.

Для шифрования файла используя симметричный метод с паролем используйте опцию -c (либо её длинный аналог –symmetric):

Следующая команда для шифрования файла test.php паролем в gpg:

gpg -c test.php

В результате шифрования будет создан файл с расширением .gpg (в данном случае это будет файл test.php.gpg).

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

• -e — означает шифрование данных
• -c — означает симметричное шифрование
• -r ‘id’ — означает зашифровать данные для пользователя с определённым id

Пример команды симметричного шифрования файла test.php для пользователя Alexey Miloserdov с возможностью его расшифровки приватным ключом ЛИБО для расшифровки паролем:

gpg -e -c -r 'Alexey Miloserdov' test.php

Точнее говоря, комбинирование двух опций -e и -c шифрует ключ сессии публичным ключом и симметричным шифром, поэтому для расшифровки может использоваться И приватный ключ, И пароль (на выбор). Если на другом компьютере, где вы расшифровываете файл, имеется ваш приватный ключ, то при расшифровке будет запрошен пароль приватного ключа. Если приватный ключ отсутствует, то будет запрошен пароль, который использовался при шифровании файла.

Для шифрования публичным ключом (-e), чтобы файл (test.php) мог расшифровать только владелец соответствующего парного приватного ключа (-r ‘Alexey Miloserdov’):

gpg -e -r 'Alexey Miloserdov' test.php

Вместо опции -r ‘Имя Адресата’ можно использовать опцию -R ‘Имя Адресата’ или её длинный аналог –hidden-recipient ‘Имя Адресата’. Она также шифрует файл для указанного адресата, но имя этого адресата шифруется.

Пример шифрования файла test.php публичным ключом пользователя Alexey Miloserdov, но с зашифрованным именем адресата.

gpg -e -R 'Alexey Miloserdov' test.php

Обратите внимание, что во всех случаях шифрования оригинальный файл остаётся!!! Вам самим нужно решать, что с ним делать, например, удалить его.

Чтобы каждый раз не вводить имя получателя, можно установить значение по умолчанию опцией –default-recipient. Также с ней в комплекте идут опции –default-recipient-self и –no-default-recipient.