Как создать самозаверяющий SSL-сертификат для Nginx в Ubuntu 18.04

Анонс

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

Схема PKI остаётся той же, только изменяются компоненты:

В качестве CA вместо Let’s Encrypt, будет использоваться OpenSSL и CA Smallstep.

Как создать самозаверяющий SSL-сертификат для Nginx в Ubuntu 18.04

Практика Self-signed certificate

OpenSSL

Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии:

OpenSSL 1.1.1k FIPS 25 Mar 2021

Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.

Реализация TLS

Для нашего CA генерируем приватный ключ 2048-бит RSA. Администратор CA должен хранить его в секрете от всех:

openssl genrsa -out root_ca.key 2048

Далее для нашего CA генерируем X.509 сертификат на 365 дней (root_ca.crt) и подписываем его приватным ключом (root_ca.key). Получается самоподписанный сертификат, его можно и нужно будет скопировать на все компьютеры, между которыми необходимо организовать TLS соединение. При ответах на вопросы, которые будет задавать OpenSSL, можно указывать произвольные данные, CA я назвал «My CN»:

openssl req -x509 -new -key root_ca.key -days 365 -out root_ca.crt

Смотрим получившийся сертификат, убеждаемся, что данные в нем корректные:

openssl x509 -text -in root_ca.crt

openssl genrsa -out server.key 2048

openssl req -new -key server.key -subj "/CN=xx.xx.xx.xx/CN=server/CN=server.example.com" -out server.csr

Можно посмотреть получившийся запрос на сертификат и убедиться в его корректности:

openssl req -text -in server.csr

openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf

Файл openssl.cnf должен содержать список SAN (Subject Alternative Name) идентичный тому, что был в CSR запросе на сертификат:

[SAN]
subjectAltName = @alt_names
[alt_names]
IP.1 = xx.xx.xx.xx
DNS.1 = server
DNS.2 = server.example.com

Можно посмотреть на получившийся сертификат и убедиться в его корректности:

openssl x509 -text -in root_ca.crt

const fs = require('fs');
const https = require('https');
 
https
  .createServer(
    {
      requestCert: false,
      rejectUnauthorized: false,
      ca: fs.readFileSync('root_ca.crt'),
      cert: fs.readFileSync('server.crt'),
      key: fs.readFileSync('server.key')
    },
    (req, res) => {
      console.log("req.client.authorized: ", req.client.authorized)
      if (req.client.authorized) {
        const cert = req.socket.getPeerCertificate(false) // true - получить все сертификаты, false - последний
        console.log("cert: ", cert)
    }
      res.end('Hello, world!');
    }
  )
  .listen(9443);

Запускать данный скрипт будем с помощью Node.js. Если Node.js не установлен, то устанавливаем:

sudo yum groupinstall 'Development Tools'

sudo yum install nodejs

Проверяем, что Node и Npm установились успешно:

Проверяем сервер curl-ом:

При первом запросе возникнет ошибка:

curl: (60) SSL certificate problem: self signed certificate in certificate chain

Это значит, что самоподписанный корневой сертификат нашего CA (root_ca.crt) не находится в хранилище доверительных сертификатов. Процесс загрузки сертификатов в это хранилище специфичен для операционной системы. Приведу алгоритм для RH Linux:

Если сертификат не в PEM (текстовом) формате, то его надо сконвертировать в текстовой формат:

openssl x509 -in root_ca.crt -out root_ca.pem -outform PEM

Копируем сертификат в определенный каталог на сервере. ДляRH 7 и выше это каталог:

Выполняем команду обновления хранилища сертификатов:

Теперь curl проходит

на Windows есть специфика — в curl необходимо добавлять параметр «ssl-no-revoke», чтобы не проверялся список отозванных сертификатов:

При этом сервер выведет в консоль строку:

Это значит, что мы установили TLS соединение только с проверкой сертификата сервера, а не клиента. Переходим к mTLS.

Реализация mTLS

{
requestCert: true,
rejectUnauthorized: true,
}

Алгоритм генерации клиентских сертификатов аналогичен серверным.

Генерируем приватный ключ для клиента:

openssl genrsa -out client.key 2048

Генерируем запрос на сертификат CSR со списком CN:

openssl req -new -key client.key -subj "/CN=xx.xx.xx.xx/CN=client/CN=client.example.com" -out client.csr

Генерируем сертификат для клиента и подписываем его приватным ключом CA:

openssl x509 -req -in client.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out client.crt -days 365 -extensions SAN -extfile openssl.cnf

Файл openssl.cnf — такой же как и для сервера, только вместо «server» пишем «client».

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

То произойдет ошибка авторизации

curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Поэтому вызываем curl с дополнительными параметрами, в которых указываем ключ клиента и сертификаты клиента и СА:

Теперь запрос проходит, при этом сервер выведет в консоль следующую строку и далее содержимое полученного от клиента сертификата:

Это значит, что мы установили mTLS соединение с проверкой сертификата как сервера, так и клиента. Теперь установим mTLS из браузера.

Реализация mTLS в браузере

Для загрузки в браузер клиентский сертификат и приватный ключ надо сконвертировать в формат p12. Этот формат определяется стандартом PKCS #12 и является архивом для хранения нескольких объектов. В нашем случае файл будет хранить клиентский сертификат и его приватный ключ. Понятно, что приватный ключ — это чувствительная к разглашению информация и ее владелец не должен выкладывать p12 сертификат в открытый доступ. Для конвертации тоже используем OpenSSL:

openssl pkcs12 -inkey client.key -in client.crt -export -out client.p12

Импортируем client.p12 в браузер. Для этого, например в Chrome, идем в меню: Settings / Privacy and security / Manage certificates, в открывшемся окне нажимаем Import, выбираем наш файл client.p12 и место хранения «Personal». Видим, что клиентский сертификат, выданный нашим удостоверяющим центром «My CN», появился в хранилище персональных сертификатов:

Вызываем запрос заново, уже лучше, но браузер все равно пишет, что соединение не безопасно. Это из-за того, что клиентский сертификат выдан удостоверяющим центром «My CN», которого нет в списке доверительных CA (Trusted Root Certification Authorities).

Добавляем корневой сертификат нашего CA (root_ca.crt) в Trusted Root Certification Authorities. Делается с помощью того же вызова Import, что и для клиентского сертификата, но хранилище указываем Trusted Root Certification Authorities. Проверяем, что наш CA «My CN» появился в хранилище:

Дальнейшие вызовы проходят без запросов на подтверждение клиентского сертификата:

Если щелкнуть на замочке а адресной строке, то можно посмотреть сертификат сервера и убедиться, что мы взаимодействуем с правильным сервером (Issued to: server.example.com), сертификат которому выдан нашим удостоверяющим центром (Issued by: My CN) и время действия сертификата еще не прошло (Valid to: 31.05.2023):

Таким образом мы организовали mTLS соединение из браузера. Далее приведу для справки несколько дополнительных возможностей OpenSSL, которые могут пригодиться в процессе работы.

Дополнительные возможности OpenSSL

Конвертация форматов сертификатов

Конвертируем сертификат в der (бинарный формат):

openssl x509 -outform der -in client.crt -out client.der

Конвертируем сертификат в PEM (текстовой формат)

openssl x509 -inform der -in client.cer -out client.pem

Отладка с помощью OpenSSL

Проверка, что сертификат подписан определенным (root_ca.pem) удостоверяющим центром:

openssl verify -verbose -x509_strict -CAfile root_ca.pem server.crt

openssl s_server -accept 9443 -cert server.crt -key server.key

Запускаем OpenSSL client

openssl s_client -connect xx.xx.xx.xx:9443 -prexit -showcerts -state -status -tlsextdebug -verify 10

При вызове curl параметр:
- -k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation).
- —ssl-no-revoke — предотвращает проверку отозванных сертификатов

Практика CA Smallstep

Установка Smallstep и CLI step

CA Smallstep — это open source CA, который можно развернуть локально для автоматического получения X.509 сертификатов. На официальном сайте есть ряд инструкций по его установке и настройке. Для экспериментов я использовал вариант с docker:

Краткая выжимка из инструкции по установке на RH Linux. Сначала устанавливаем docker:

sudo yum -y update

sudo yum install -y yum-utils

sudo yum -y install docker-ce

sudo systemctl start docker

Проверяем корректность установки docker:

sudo docker run hello-world

sudo docker pull smallstep/step-ca

Инициализируем наш CA:

docker run -it -v step:/home/step smallstep/step-ca step ca init

должна вернуться строка:

На этом же или другом компьютере по инструкции устанавливаем утилиту CLI step. Краткая выжимка:

tar -xf step_linux_0.19.0_386.tar.gz

Копируем утилиту step в /usr/bin

Регистрируем CLI step для использования с нашим CA. Этот процесс называется «bootstrap». Значение параметра «ca-url» — это IP и порт, на котором запущен Smallstep CA, «fingerprint » — это сохраненное значение при инициализации CA:

Проверка связи с CA:

step ca health

должна вернуться строка:

Все готово для генерации ключей и сертификатов.

Генерация ключей и сертификатов

Также как и в случае с OpenSSL, сначала генерируем ключ и сертификат для сервера и установки TLS соединения, потом для клиента и установки mTLS.

В отличии от OpenSSL, CA Smallstep может одновременно сформировать приватный ключ сервера 2048-бит RSA (server.key) и запрос на сертификат (server.csr). В запросе явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx — это IP адрес сервера, для которого генерируется запрос:

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" server.csr server.key

Подписываем сертификат на нашем CA Smallstep:

step ca sign server.csr server.crt

Смотрим полученный сертификат:

step certificate inspect server.crt

Получаем с CA Smallstep его корневой сертификат:

step ca root root_ca.crt

Смотрим корневой сертификат:

step certificate inspect root_ca.crt

Проверяем сервер curl-ом:

Все нормально, теперь генерируем ключ и сертификат для клиента.

Аналогично серверу одновременно формируем приватный ключ клиента 2048-бит RSA (client.key) и запрос на сертификат (client.csr). Явно указываем, что пароль должен быть пустой (no-password), xx.xx.xx.xx — это IP адрес клиента, для которого генерируется запрос:

step certificate create --csr --no-password --insecure --kty=RSA --size=2048 "xx.xx.xx.xx" client.csr client.key

Подписываем сертификат на CA:

step ca sign client.csr client.crt

step certificate inspect client.crt

Получаем корневой сертификат CA:

step ca root root_ca.crt

Смотрим корневой сертификат:

step certificate inspect root_ca.crt

Копируем на клиента:
Для проверки вызываем curl с параметрами:

Отлично — mTLS тоже работает с выданными CA Smallstep сертификатами!

Дополнительные возможности CA Smallstep

С помощью CLI step можно проверить необходимость обновления сертификата:

step certificate needs-renewal server.crt

Если обновление не требуется возвращается строка:

certificate does not need renewal

Если требуется, то строка пустая и тогда необходимо обновить сертификат:

step ca renew server.crt server.key

При необходимости сертификат можно отозвать, в этом случае его невозможно будет продлить, только получить заново:

step ca revoke --cert server.crt --key server.key

Посмотреть все сертификаты в цепочке:

Читать также: Сертификат многодетным семьям на приобретение жилья спб горжилобмен

step certificate inspect server.crt --bundle

Запуск CLI step в режиме отладки:

STEPDEBUG=1 step /команда/

Заключение

В данной статье мы рассмотрели две возможности генерации ключей и сертификатов для клиента и сервера:

С помощью OpenSSL.
Используя CA Smallstep.

И двумя способами установили TLS и mTLS соединения:

С помощью curl.
Из браузера, загрузив в него клиентский и корневой сертификаты.

Теперь у нас есть понимание, как организовать свою систему PKI с помощью CA любого производителя, т.к. логика взаимодействия у всех аналогичная. Более того, большинство CA используют под капотом OpenSSL, оборачивая его в свой API.

Некоторое время назад я задался вопросом, можно ли наладить фабрику сертификатов, не прибегая к утилите openssl. Как подвести «под кнопку» весь процесс от генерации ключей до проверки подлинности. Забегая вперед, скажу, что пространство System.Security.Cryptography в этом плане является вполне самодостаточным. В статье я рассмотрю этапы создания сертификатов, экспорт в форматы pem и pkcs12, хранение сертификатов в файловой системе, а также проверку подлинности, используя только классы из System.Security.Cryptography.

Создание

В статье я буду рассматривать простую схему взаимодействия клиент-сервер, без удостоверяющего центра. Для взаимной проверки подлинности нам понадобится корневой самоподписанный сертификат caCert и два конечных clientCert и serverCert. Клиенты обмениваются своими сертификатами, проверяют подлинность корневым, успех. Создание сертификатов состоит из тех же этапов, как и любое руководство по openssl:

Генерируем ассиметричный ключ:
```
var rsaKey = RSA.Create(2048);
```
Описываем субъект сертификации:
```
string subject = "CN=myauthority.ru";
```
cn – “common name”, общепринятое имя организации, определяющее, какие имена хостов будет защищать сертификат. В общем случае строка может содержать дополнительные поля, разделенные косой чертой. Пример из MSDN «C = US/O = Microsoft/OU = WGA/CN = test«.
Создаем запрос на сертификат:
```
var certReq = new CertificateRequest(subject, rsaKey,HashAlgorithmName.SHA256,RSASignaturePadding.Pkcs1);
```
Режим Pkcs1 используется по умолчанию в openssl.
Дополнительно настраиваем запрос:
```
certReq.CertificateExtensions.Add(new X509BasicConstraintsExtension(true, false, 0, true)); 
certReq.CertificateExtensions.Add(new X509SubjectKeyIdentifierExtension(certReq.PublicKey, false));
```
Этими дополнениями мы указываем, что данный сертификат принадлежит центру сертификации, а также используем публичный ключ для создания SKI (идентификатора ключа субъекта).

Создаем сертификат на 5 лет:

var expirate = DateTimeOffset.Now.AddYears(5);
var caCert  = certReq.CreateSelfSigned(DateTimeOffset.Now, expirate);

Теперь создаем конечные сертификаты.

```
var clientKey = RSA.Create(2048);
string subject = "CN=10.10.10.*";
var clientReq = new CertificateRequest(subject, clientKey,HashAlgorithmName.SHA256,RSASignaturePadding.Pkcs1);
```
Здесь в качестве защищаемого объекта можно указать подсеть или конечный ip адрес, если доменное имя не используется.

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

clientReq.CertificateExtensions.Add(new X509BasicConstraintsExtension(false, false, 0, false));
clientReq.CertificateExtensions.Add(new X509KeyUsageExtension(X509KeyUsageFlags.DigitalSignature | X509KeyUsageFlags.NonRepudiation, false));
clientReq.CertificateExtensions.Add(new X509SubjectKeyIdentifierExtension(clientReq.PublicKey, false));

Назначаем сертификату серийный номер:
```
byte[] serialNumber = BitConverter.GetBytes(DateTime.Now.ToBinary());
```
Serial Number – уникальный идентификатор, назначенный каждому сертификату, выданному издателем. Рекомендуется использовать общедоступный счетчик, инициализированный на основе текущего времени.
Создаем сертификат на 5 лет:
```
var clientCert = clientReq.Create(caCert, DateTimeOffset.Now, expirate, serialNumber):
```
Время экспирации не должно выходить за границы корневого сертификата, иначе мы получим соответствующую ошибку. Теперь, если сравнить поля caCert.Subject и clientCert.Issuer, то они совпадают, как мы и ожидали.

Хранение

Теперь, когда у нас есть все сертификаты, необходимо их сохранить. В руководстве openssl обычно предлагается хранить сертификаты в формате pem, разбив их на открытую часть public.crt и private.key. Полученные на предыдущих этапах сертификаты являются экземплярами класса X509Certificate2, который имеет все необходимые для нас свойства и методы. Итак, чтобы получить открытую часть, необходимо закодировать содержимое сертификата в base64 и записать в файл:

StringBuilder builder = new StringBuilder();
builder.AppendLine("-----BEGIN CERTIFICATE-----");
builder.AppendLine(Convert.ToBase64String(clientCert.RawData, Base64FormattingOptions.InsertLineBreaks));
builder.AppendLine("-----END CERTIFICATE-----");
File.WriteAllText("public.crt", builder.ToString());

Также сохраним закрытый ключ:

string name = clientKey.SignatureAlgorithm.ToUpper();
StringBuilder builder = new StringBuilder();
builder.AppendLine($"-----BEGIN {name} PRIVATE KEY-----");
builder.AppendLine(Convert.ToBase64String(clientKey.ExportRSAPrivateKey(), Base64FormattingOptions.InsertLineBreaks));
builder.AppendLine($"-----END {name} PRIVATE KEY-----");
File.WriteAllText("private.key", builder.ToString());

Отмечу, что метод ExportRSAPrivateKey появился только в netcore 3.0, поэтому в предыдущих версиях могут возникнуть проблемы.

Еще один способ хранения сертификатов — формат pkcs12 или pfx, позволяющий уместить в одном файле открытую и закрытую часть. Класс X509Certificate2 содержит метод Export, принимающий в качестве аргумента необходимый нам ключ X509ContentType.Pkcs12 или X509ContentType.Pfx. Однако на этом этапе возникают трудности, поскольку загруженный обратно из файла сертификат неожиданно не содержит приватного ключа, о чем свидетельствует флаг cert.HasPrivateKey == false. Дело в том, что класс X509Certificate2 содержит внутреннюю метку, описывающую, куда и как экспортируется закрытый ключ. Эта метка инициализируется только с помощью конструктора и не может быть изменена после. Поэтому для создания файла p12 или pfx, необходимы дополнительные усилия:

var exportCert = new X509Certificate2(clientCert.Export(X509ContentType.Cert), (string)null, X509KeyStorageFlags.Exportable | X509KeyStorageFlags.PersistKeySet).CopyWithPrivateKey(clientKey);
File.WriteAllBytes("client.pfx", exportCert.Export(X509ContentType.Pfx));
File.WriteAllBytes("client.p12", exportCert.Export(X509ContentType.Pkcs12));

При желании можно использовать перегрузки метода Export с паролем.

Для работы с коллекциями сертификатов в .net core удобно использовать специализированное хранилище, реализуемого классом X509Store. Хранилище в простом случае инициализируется строковым именем:

X509Store store = new X509Store("test");
store.Open(OpenFlags.ReadWrite);
store.Add(cert);

Проверка

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/public.crt;
        ssl_certificate_key /etc/nginx/ssl/private.key;
        ssl_client_certificate /etc/nginx/ssl/caCert.crt;
        ssl_verify_client on;
}

SocketsHttpHandler handler = new SocketsHttpHandler();
handler.SslOptions.RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
 {
    X509Chain chain = new X509Chain(false);
    chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
    chain.ChainPolicy.VerificationFlags = X509VerificationFlags.AllowUnknownCertificateAuthority;
    chain.ChainPolicy.ExtraStore.Add(caCert);
    var serverСert = new X509Certificate2(certificate);
    return chain.Build(serverСert);
};
handler.SslOptions.ClientCertificates = new X509CertificateCollection() { clientCert };
HttpClient client = new HttpClient(handler);
var resp = await client.GetAsync…

Настройка построения цепочки заключается в отключении поиска сертификата в списке «отозванных» и допустимости «недоверенных» сертификатов.

Итог

В реализациях .net core для ОС Linux криптографические функции выполняются через взаимодействие с библиотеками OpenSSL. Поэтому принципиальной разницы между создаваемыми сертификатами нет. Есть библиотеки, такие как BouncyCastle, которые умеют гораздо больше и, возможно, удобнее, но лично мне не хочется использовать дополнительные зависимости ради 10 процентов функционала. Надеюсь, статья хоть немного упростит поиски информации для тех, кому предстоит разбираться в сложностях работы с X.509.

Введение:

Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.

Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.

Внимание! В статье для примера используются самоподписанные сертификаты!

Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:

cd /path/to/nginx/config/
mkdir ssl && cd ssl

Шаг 1. Создание собственного самоподписанного доверенного сертификата.

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

openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com -out ca.crt

Шаг 2. Сертификат сервера

Создадим сертификат для nginx и запрос для него

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

Подпишем сертификат нашей же собственной подписью

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата

openssl rsa -in server.key -out server.nopass.key

Конфиг nginx

listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;

keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;

Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:

400 Bad Request
No required SSL certificate was sent

Что ж, логично, в этом-то и вся соль!

Шаг 3. Создание клиентских сертификатов

3.1 Подготовка CA

Создадим конфиг
nano ca.config

со следующим содержимым:

[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов

database = $dir/index.txt # Файл с базой данных подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер сертификата (в шестнадцатеричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA

default_days = 365 # Срок действия подписываемого сертификата
default_crl_days = 7 # Срок действия CRL
default_md = md5 # Алгоритм подписи

policy = policy_anything # Название секции с описанием политики в отношении данных сертификата

[ policy_anything ]
countryName = optional # Поля optional - не обязательны, supplied - обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optional

Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле

mkdir db
mkdir db/certs
mkdir db/newcerts
touch db/index.txt
echo "01" > db/serial

3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)

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

openssl req -new -newkey rsa:1024 -nodes -keyout client01.key -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com -out client01.csr

В результате выполнения команды появятся два файла client01.key и client01.csr.

3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

openssl ca -config ca.config -in client01.csr -out client01.crt -batch

В результате выполнения команды появится файл клиентского сертификата client01.crt.

Для создания следующих сертификатов нужно повторять эти два шага.

3.4. Создание сертификата в формате PKCS#12 для браузера клиента

Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.

openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3

3.5 Подключение к полученному ssl cерверу с помощью curl

curl -k --key client.key --cert client1.crt --url "https://site.com"

Использована опция -k, потому что сертификат в примере самоподписанный

Использованное ПО

Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010

Полезные ссылки

Надеюсь, был кому-то полезен.

P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).

Примеры использования OpenSSL в Unix/Linux

При работе с SSL, нужно уметь работать с утилитой OpenSSL чтобы создавать, конвертировать, управляют SSL-сертификатами. В этой статье «Примеры использования OpenSSL в Unix/Linux» я буду говорить о примерах использования OpenSSL.

Некоторые из сокращений, связанных с сертификатами:

SSL – Secure Socket Layer (Безопасный уровень сокета).
CSR – Certificate Signing Request (Запрос на подпись сертификата).
TLS – Transport Layer Security (Транспортный уровень безопастности).
PEM – Privacy Enhanced Mail
DER – Distinguished Encoding Rules
SHA – Secure Hash Algorithm (Безопасный hash алгорит).
PKCS – Public-Key Cryptography Standards (Стандарты шифрования публичных ключей).

Создание нового приватного ключа (Private Key) и Certificate Signing Request (CSR).

# openssl req -out linux-notes.org.csr -newkey rsa:2048 -nodes -keyout linux-notes.org.key

Команда выше будет генерировать CSR и 2048-битный RSA ключ. Если вы собираетесь использовать этот сертификат в Apache или Nginx, то вам необходимо отправить этот CSR файл в службу сертификации и они дадут вам подписанный сертификат в «der» или «pem» формате. После чего вы настроите его на веб-сервере Apache или Nginx.

Так же, можно использовать такой вариант:

$ openssl req -new -newkey rsa:2048 -nodes -out linux-notes.org.csr -keyout linux-notes.org.key -subj "/C=US/ST=Wisconsin/L=Waukesha/O=IT Dept/OU=Linux Notes/CN=linux-notes.org"

Создание самоподписанного сертификата (Self-Signed Certificate).

# openssl req -x509 -sha256 -nodes -newkey rsa:2048 -keyout LN-selfsigned.key -out LN-cert.pem

Команда выше будет генерировать самоподписанный сертификат (self-signed) и 2048-битный RSA ключ. Я также использую алгорит шифрования — SHA256. Так как он считается наиболее безопасным в данный момент.

Замечание: По умолчанию, будет сгенерирован ключ толкьо на 1 месяц, если нужно создать на более длительное время — используйте опцию «–days», пример использования ниже.

Пример: Чтобы создать self-signed сертификат на 2 год, используйте:

# openssl req -x509 -sha256 -nodes -days 730 -newkey rsa:2048 -keyout LN-selfsigned.key -out LN-cert.pem

Проверка CSR файла.

# openssl req -noout -text -in linux-notes.org.csr

и вы получите информацию.

Проверка подписи (signature):

$ openssl req -in linux-notes.org.csr -noout -verify

Кем(кому) был выдан сертификат:

$ openssl req -inlinux-notes.org.csr -noout -subject

Показать открытый ключ (public key):

$ openssl req -inlinux-notes.org.csr -noout -pubkey

Создать приватный RSA ключ (Private Key).

Чтобы это сделать, выполните:

# openssl genrsa -out my_private_rsa.key 2048

Если вам просто нужно генерировать RSA закрытый ключ, вы можете использовать команду что выше. Я включил 2048 шифрование, для безопастности.

Удалить ключевую фразу (Passphrase) с ключа.

# openssl rsa -in linux-notes.org.key -check -out nopassphrase.key

Если вы установили ключевую фразу для ключа, то при каждом старте веб-сервера (Apache/Nginx) вы должны будите вводить пароль. Если это вас злит, вы можете с легкостью удалить passphrase с RSA ключа.

Проверка приватного ключа (Private Key)

# openssl rsa -in my_private.key -check

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

Проверка сертификата (Certificate).

Если вы хотите проверить данные сертификата( CN, OU, и т.д.), то вы можете использовать команду, которая даст вам сведения о сертификате:

# openssl x509 -in certfile.pem -text –noout

Команда довольна простая в использовании.

Проверка подписанного сертификата (Certificate Signer Authority).

# openssl x509 -in some_cert.pem -noout -issuer -issuer_hash

Можно узнать много полезного.

Создать тестовый SSL сервер.

Команда OpenSSL s_server реализует общий SSL/TLS-сервер. Она должна использоваться только для целей тестирования. В приведенном ниже примере данный сервер прослушивает соединения на порту 8080 и возвращает отформатированную HTML страницу статуса, который включает много информации о ciphers:

$ openssl s_server -key key.pem -cert cert.pem -accept 8080 -www

Проверить хеш вашего сертификата.

# openssl x509 -noout -hash -in my_cert.pem

Конвертирование сертификатов с DER в PEM формат.

# openssl x509 -inform der -in LN.der -out LN.pem

Как правило, при покупке SSL сертификатов, его отдают вам в формате .der и если вам нужно использовать его в веб-сервере или .pem формате, вы можете использовать команду выше, чтобы преобразовать такие сертификаты.

Конвертирование сертификатов с PEM в DER формат.

В случае, если вам необходимо изменить .pem формат в .der:

# openssl x509 -outform der -in linux-notes.pem -out linux-notes.der

Конвертирование CSR c DER в PEM формат.

$ openssl req -in csr.der -inform DER -out csr.pem -outform PEM

Конвертирование сертификата и приватного ключа в PKCS#12 фотмат.

# openssl pkcs12 –export –out sslcert.pfx –inkey key.pem –in sslcert.pem

Если вам необходимо использовать сертификат с приложением Java или с любым другим, кто принимает формат PKCS# 12.

Совет: Вы можете включить «chain certificate» используя «-chain» опцию:

# openssl pkcs12 -export -out my_cert.pfx -inkey my_key.pem -in your_cert.pem -chain the_cert.pem

Создание CSR используя приватный ключ (private key).

# openssl req -out some_cert.csr -key exists.key -new

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

Проверьте содержимое сертификата в PKCS12 формате.

# openssl pkcs12 -info -nodes -in my_certificate.p12

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

Конвертирование PKCS12 формата в PEM сертификат.

# openssl pkcs12 -in my_certificat.p12 -out the_certificat.pem

Получить SHA-1 отпечаток сертификата или CSR

Чтобы получить отпечаток SHA1 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:

$ openssl dgst -sha1 my_cert.der

Чтобы получить SHA1 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:

$ openssl dgst -sha1 the_csr.der

Получить MD5 отпечаток сертификата или CSR

Чтобы получить отпечаток MD5 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:

$ openssl dgst -md5 cert.der

Чтобы получить MD5 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:

$ openssl dgst -md5 my_csr.der

Тестирование SSL сертификата по URL.

# openssl s_client -connect linux-notes.org:443 -showcerts

Я использую это довольно часто для проверки SSL-сертификатов по URL с сервера. Это очень удобно для проверки некоторых деталей протокола, шифров и CERT.

Узнать версию OpenSSL

 # openssl version

Поверка PEM сертификата на завершение (Expiration Date).

# openssl x509 -noout -in cert.pem -dates

# openssl x509 -noout -in bestflare.pem -dates
notBefore=Jul 4 14:02:45 2015 GMT
notAfter=Aug 4 09:46:42 2015 GMT

Проверка завершения SSL сертификата (Expiration Date) по URL.

# openssl s_client -connect linux-notes.org:443 2>/dev/null | openssl x509 -noout -enddate

Проверить поддержку SSL версии V2/V3 по URL.

Проверка SSL версии V2:

# openssl s_client -connect linux-notes.org:443 -ssl2

Проверка SSL версии V3:

# openssl s_client -connect linux-notes.org:443 -ssl3

Проверка TLS 1.0:

# openssl s_client -connect linux-notes.org:443 -tls1

Проверка TLS 1.1:

# openssl s_client -connect linux-notes.org:443 -tls1_1

Проверка TLS 1.2:

# openssl s_client -connect linux-notes.org:443 -tls1_2

Проверка поддержки cipher для сайта по URL.

# openssl s_client -cipher 'ECDHE-ECDSA-AES256-SHA' -connect linux-notes.org:443

Какой алгоритм используется в сертификате (проверка).

$ openssl req -noout -text -in mycert.csr | grep 'Signature Algorithm'

Или, используя URL:

openssl s_client -connect linux-notes.org:443 < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"

Получить сертификат по URL

Команда что ниже, сохранит сертификат в файл прямо по URL сайта:

$ echo -n | openssl s_client -connect linux-notes.org:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > pem.cert

$ echo -n | openssl s_client -connect linux-notes.org:443 -servername linux-notes.org | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > pem.cert

Вот и все, много полезностей и все в одной статье «Примеры использования OpenSSL в Unix/Linux».

Настройка SSL сертификата для Apache

Зачем же нужен SSL сертификат?

С помощью SSL сертификата можно зашифровать вашу информацию на сайте сайта для защиты соединений. Так же, он может давать посетителям сайта информацию о идентификации на виртуального сервера.

Как и где можно получить SSL сертификат?

SSL сертификат можно купить или создать самим. Я именно буду использовать самоподписанный сертификат для своего сайта.

В своей статье «Настройка SSL сертификата для Apache», я расскажу как можно установить и настроить SSL сертификат для Apache. На готовых примерах, я покажу как это сделать. Я использую ОС: Debian 8 и CentOS 6/7.

Установка SSL сертификата для Apache

Для начала нужно установить Apache и модуль для него — mod_ssl. Если не знаете как установить apache, то можно ознакомится с материалом тут:

Установка Apache, PHP с suPHP на CentOS/RedHat/Fedora

Установка Apache mpm-itk на Unix/Linux

Установка Apache,PHP 5.5.11, MariaDB 5.5.37 на CentOS 6.5

Установка apache из исходников для FreeBSD (руководство по установке)

И так, apache уже установлен, но нужно еще установить и модуль для работы с SSL сертификатами.

Для CentOS/RHEL/Fedora, выполните команду:

# yum install mod_ssl

Для Debian/Ubuntu, выполните команду:

Данный модуль, уже идет с пакетом Apache, по этому, нужно его включить:

# a2enmod ssl

После включения SSL, необходимо перезапустить веб-сервер чтобы изменения вступили в силу, для этого, выполните команду:

# service apache2 restart

Создание нового каталога

# mkdir /etc/httpd/ssl

Т.к в Debian’s apache устанавливается в /etc/apache2, то для хранения сертификатов, я создам новую папку:

# mkdir /etc/apache2/ssl

После чего, можно приступать к генерации сертификата.

Создание самоподписанного сертификата

Сейчас, я создам самоподписанный сертификат который будет работать 365 дней ( 1 год). Все параметры, я опишу немного ниже.

Для CentOS/Fedora/RedHat, выполните команду:

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/apache.key -out /etc/httpd/ssl/apache.crt

Для Ubuntu/Debian, выполните команду:

# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/linux-notes.key -out /etc/apache2/ssl/linux-notes.crt

Теперь, рассмотрим что же выполняют некоторые опции:

openssl: Это утилита для создания и управления сертификатами, ключами и т.д.
req: Это субкоманда, которая создает подпись X.509 (CSR) для управления сертификатом. X.509 является открытым ключом, с помощью которого, можно создать свой самоподписанный сертификат.
-x509: Эта опция указывает, что мы хотим сгенерировать файл сертификата с собственной подписью вместо генерации запроса на сертификат.
-nodes: С этой опцией я создам ключ который будет зашифрован с помощью парольной фразы. Имея защищенный паролем ключ, я должен буду вводить вводить пароль каждый раз при перезапуске службы. Я нажну «ENETR» и оставлю пустой пароль.
-days 365: Это указывает, что сертификат будет действителен в течение одного года.
-newkey rsa:2048: Эта опция служит для создания сертификата и нового закрытого ключа. Это необходимо, так как я не создал секретный ключ заранее. RSA: 2048 сгенерирует ключ RSA с 2048 битным шифрованием.
-keyout: Этот параметр задаст выходной файла для файла секретного ключа, который создается.
-out: Этот параметр задаст выходной файла для сертификата, который я генерирую.

Входе генерации сертификата, нужно ввести некоторые данные:

Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:nvs
Locality Name (eg, city) [Default City]:Lugansk
Organization Name (eg, company) [Default Company Ltd]:linux-notes
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:linux-notes.org
Email Address []:solo.metal@bigmir.net

Чтобы не вводить это, можно задать нужные параметры при вводе команды, например:

# openssl req -nodes -newkey rsa:2048 -nodes -keyout /etc/apache2/ssl/linux-notes.key -out /etc/apache2/ssl/linux-notes.crt -subj "/C=UA/ST=Lugansk/L=Lugansk/O=linux-notes Ltd./OU=IT/CN=linux-notes.org"

Настройка SSL сертификата для Apache

И так, уже все есть, сертификат создан и можно приступать к настройке. Для этого, открываем виртуальный хост (если нет, можно создать новый):

Конфигурационный файл(ы) в RedHat’s можно создать:

# vim /etc/httpd/conf.d/linux-notes.org.conf

Конфигурационный файл(ы) в Debian’s можно создать:

# vim /etc/apache2/conf.d/linux-notes.org.conf

Мой конфиг выглядит следующим образом:

<IfModule mod_ssl.c>
 <VirtualHost linux-notes.local:443>
    ServerName linux-notes.local
    ServerAlias www.linux-notes.local
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error-linux-notes.local.log
    CustomLog ${APACHE_LOG_DIR}/access-linux-notes.local.log combined
    SSLEngine on
    SSLCertificateFile /etc/ssl/apache.pem
    SSLCertificateKeyFile /etc/ssl/apache.crt
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
       SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
       SSLOptions +StdEnvVars
    </Directory>
    BrowserMatch "MSIE [2-6]" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>
</IfModule>

Конфиг готов и осталось совсем немногое.

Можно создать перенаправление с 80-порта на 443-й, для этого, нужно прописать перенаправление:

<VirtualHost *:80>
  ServerName linux-notes.org
  RewriteEngine On
  RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>
<VirtualHost *:443>
  ServerName linux-notes.org
  DocumentRoot /var/www/linux-notes.org
  SSLEngine on
  SSLCertificateFile /etc/ssl/apache.pem
  SSLCertificateKeyFile /etc/ssl/apache.crt
  ErrorLog ${APACHE_LOG_DIR}/error-linux-notes.local.log
  CustomLog ${APACHE_LOG_DIR}/access-linux-notes.local.log combined
</VirtualHost>

Настройка вашего брандмауэра

После всех изменений, необходимо так же, пробросить порт (443) для работы веб-сервера (apache), для этого я добавн правило в IPtables:

# iptables -A INPUT -p tcp --dport 443 -j ACCEPT

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

# httpd -t

Это команда для RPM’s систем, для DEB’s систем найдите сами.

Теперь, когда я настроил SSL в виртуальном хосте, необходимо включить его:

# a2ensite linux-notes.org.conf

и после этого можно перезапускать апач:

# /etc/init.d/httpd restart

# service httpd restart

Открываем сайт, и смотрим что получилось:

 https://IP_or_HOST

Вот и все, все настроено и готово к использованию. Моя тема «Настройка SSL сертификата для Apache» завершена.

Для того чтобы настроить WEB-сервер с SSL шифрованием вам необходимо установить OpenSSL и mod_ssl. Для этого мы сделаем следующее:

# yum install mod_ssl openssl

Создадим самоподписанный сертификат

Нужно использовать OpenSSL для создания самоподписанного сертификата.
Чтобы создать ключ который будет использоваться в сертификате, мне понадобится права root:

Создим приватный ключ

# openssl genrsa -out ca.key 1024

Создим CSR (Certificate signing request)

# openssl req -new -key ca.key -out ca.csr

Создим самоподписанный ключ (допустим на 1 год — 365 дней)

# openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

После того как ключик(и) был сгенерирован, необходимо скопировать (положить в нужное место) его/их:

# cp ca.crt /etc/pki/tls/certs
# cp ca.key /etc/pki/tls/private/ca.key
# cp ca.csr /etc/pki/tls/private/ca.csr

Если Вы фанат текстового редактора «vi»:

# vi +/SSLCertificateFile /etc/httpd/conf.d/ssl.conf

Но я использую текстовый редактор «ee», по этому:

# ee /etc/httpd/conf.d/ssl.conf

В этом файлике нужно раскомментировать необходимые строки, в моем случае это:

SSLCertificateFile /etc/pki/tls/certs/ca.crt # путь к файлу ключа (Certificate Key File)
SSLCertificateKeyFile /etc/pki/tls/private/ca.key # путь к файлу приватных ключей

Сохраняемся и ребутнул Apache:

# /etc/init.d/httpd restart

У вас будет другой адрес, адрес(ServerName) который Вы прописывали в конфиге апача. После того как перейдете по своему адресу вам будет показано сообщение чтобы Вы подтвердили данный сертификат.

Если вы используете виртуальные хосты, то необходимо прописать сертификаты в них:

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
# Установка сертификата SSL в CentOS
<Directory /var/www/vhosts/test.com/httpsdocs>
AllowOverride All
</Directory>
DocumentRoot /var/www/vhosts/test.com/httpsdocs
ServerName test.com
</VirtualHost>

После чего нужно ребутнуть апачик:

# /etc/init.d/httpd restart

# iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# /sbin/service iptables save
# iptables -L -v

Установка сертификата SSL в CentOS выполнена. Коротко и понятно.

Как создать самозаверяющий SSL-сертификат для Nginx в Ubuntu 18.04 Некоторые службы и приложения в Linux могут использовать в своей работе сетевые соединения, защищаемые с помощью SSL/TLS. Иногда требуется, чтобы цифровой сертификат, используемый для защиты соединений и предоставляемый каким-то удалённым сервером из локальной сети, принимался локальной Linux-системой как доверенный. Для этого в Linux-систему может потребоваться добавить корневой сертификат Центра сертификации (ЦС), которым были выданы сертификаты, используемые для защиты соединений. Типичный пример, когда локальная Linux-система для механизмов аутентификации и авторизации подключается с помощью ldap-клиента (например OpenLDAP) к контроллеру домена Active Directory (AD) и контроллер домена предоставляет ldap-клиенту для защиты соединения сертификат, выданным локальным корпоративным ЦС.

Здесь мы рассмотрим простой пример того, как в Linux-систему добавить корневые сертификаты локального корпоративного ЦС.

О том, как «выуживать» корневые сертификаты ЦС, которыми подписаны сертификаты контроллеров домена AD, я приводил пример ранее. Если под руками есть доменная Windows-машина, то можно выгрузить корневой сертификат из оснастки управления сертификатами из раздела корневых сертификатов доверенных ЦС. Если корневой сертификат не один, а несколько (цепочка), то каждый корневой сертификат цепочки выгрузим в файл в кодировке Base-64, сразу присвоив им расширение PEM вместо CER

В результате такой выгрузки в нашем примере получится пара файлов AD-RootCA.pem (корневой сертификат ЦС верхнего уровня) и AD-SubCA.pem (корневой сертификат подчинённого ЦС). Скопируем полученные pem-файлы на наш Linux-сервер, например с помощью утилиты pscp, во временный каталог.

С:\Tools\PuTTy>pscp.exe С:\Temp\AD-*.pem linux-user@LINUX-SERVER:/tmp

Перейдём на консоль Linux-сервера и переместим файлы коневых сертификатов из временного каталога в каталог, который мы создадим специально для хранения наших корневых сертификатов и подправим на эти сертификаты права (если требуется)

# mkdir /etc/ssl/certs-corp-ca
# mv /tmp/AD-*.pem /etc/ssl/certs-corp-ca
# chown root:root /etc/ssl/certs-corp-ca/AD-*.pem
# ls -la /etc/ssl/certs-corp-ca

Теперь обработаем содержимое каталога с нашими сертификатами утилитой OpenSSL — c_rehash:

# c_rehash /etc/ssl/certs-corp-ca

Doing /etc/ssl/certs-corp-ca
AD-RootCA.pem => 36865f67.0
AD-RootCA.pem => bb8428b0.0
AD-SubCA.pem => e740e31e.0
AD-SubCA.pem => 536fc63e.0

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

# ls -la /etc/ssl/certs-corp-ca

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

# find -L /etc/ssl/certs-corp-ca -type l -exec rm {} +

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

В качестве примера рассмотрим клиента OpenLDAP, для которого можно указать созданный нами каталог в конфигурационном файле ldap.conf (/etc/ldap/ldap.conf) в дополнительной опции TLS_CACERTDIR, таким образом, чтобы эта опция шла после имеющейся по умолчанию опции TLS_CACERT (подробнее об этих опциях можно найти в man ldap.conf):

ldap.conf

...
# TLS certificates (needed for GnuTLS)
TLS_CACERT      etcsslcertsca-certificates.crt
 
# Corp CA root certificates storage
TLS_CACERTDIR   etcsslcerts-corp-ca

Примечание.

В Debian GNU/Linux параметр TLS_CACERTDIR может игнорироваться, о чём сказано в man ldap.conf.

В таком случае используйте для хранения доверенных корневых сертификатов отдельный файл (бандл, в который собраны все доверенные корневые сертификаты) и указывайте его расположение через параметр TLS_CACERT.

Собрать все нужные доверенные корневые сертификаты Центров сертификации в бандл можно простой склейкой содерживого PAM-файлов в колировке Base-64:

# mkdir /etc/ssl/certs-corp-ca-chain
# cd /etc/ssl/certs-corp-ca
# cat ./AD-RootCA.pem  ./AD-SubCA.pem > /etc/ssl/certs-corp-ca-chain/AD-Chain.pem
# cat /etc/ssl/certs-corp-ca-chain/AD-Chain.pem

Соответственно, применительно к ранее упомянутому клиенту OpenLDAP в Debian GNU/Linux настройка конфигурации будет такой:

ldap.conf

...
# TLS certificates (needed for GnuTLS)
TLS_CACERT      etcsslcerts-corp-ca-chainAD-Chain.pem
 
# Corp CA root certificates storage
#TLS_CACERTDIR   /etc/ssl/certs-corp-ca

Автор первичной редакции:
Алексей Максимов
Время публикации: 25.03.2017 17:36

Как создать самозаверяющий SSL-сертификат для Nginx в Ubuntu 18.04

Анонс

Практика Self-signed certificate

OpenSSL

Реализация TLS

Реализация mTLS

Реализация mTLS в браузере

Дополнительные возможности OpenSSL

Конвертация форматов сертификатов

Отладка с помощью OpenSSL

Практика CA Smallstep

Установка Smallstep и CLI step

Генерация ключей и сертификатов

Дополнительные возможности CA Smallstep

Заключение

Создание

Хранение

Проверка

Итог

Введение:

Шаг 1. Создание собственного самоподписанного доверенного сертификата.

Шаг 2. Сертификат сервера

Конфиг nginx

Шаг 3. Создание клиентских сертификатов

3.1 Подготовка CA

3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)

3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

3.4. Создание сертификата в формате PKCS#12 для браузера клиента

3.5 Подключение к полученному ssl cерверу с помощью curl

Использованное ПО

Полезные ссылки

Примеры использования OpenSSL в Unix/Linux

Создание нового приватного ключа (Private Key) и Certificate Signing Request (CSR).

Создание самоподписанного сертификата (Self-Signed Certificate).

Проверка CSR файла.

Создать приватный RSA ключ (Private Key).

Удалить ключевую фразу (Passphrase) с ключа.

Проверка сертификата (Certificate).

Проверка подписанного сертификата (Certificate Signer Authority).

Создать тестовый SSL сервер.

Проверить хеш вашего сертификата.

Конвертирование сертификатов с DER в PEM формат.

Конвертирование сертификатов с PEM в DER формат.

Конвертирование CSR c DER в PEM формат.

Конвертирование сертификата и приватного ключа в PKCS#12 фотмат.

Создание CSR используя приватный ключ (private key).

Проверьте содержимое сертификата в PKCS12 формате.

Конвертирование PKCS12 формата в PEM сертификат.

Получить SHA-1 отпечаток сертификата или CSR

Получить MD5 отпечаток сертификата или CSR

Тестирование SSL сертификата по URL.

Поверка PEM сертификата на завершение (Expiration Date).

Проверка завершения SSL сертификата (Expiration Date) по URL.

Проверить поддержку SSL версии V2/V3 по URL.

Проверка поддержки cipher для сайта по URL.

Какой алгоритм используется в сертификате (проверка).

Получить сертификат по URL

Настройка SSL сертификата для Apache

Установка SSL сертификата для Apache

Настройка SSL сертификата для Apache

Создадим самоподписанный сертификат

Оглавление

Добавить комментарий Отменить ответ