Как создать свой корневой сертификат
Перейти к содержимому

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

  • автор:

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

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

На 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=$

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

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 это будет выглядеть так:

nginx ssl

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

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

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

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

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

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

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

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

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

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

  • .pem, .crt, .cer — готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей организаци;
  • .key — закрытый или открытый ключ;
  • .csr — запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, об организации и домене, которую вы указали.

Для генерации мы воспользуемся OpenSSL.

1. Создаем закрытый «корневой» ключ:

openssl genrsa -out rootCA.key
  • genrsa — создать закрытый ключ RSA
  • -out — выходной файл

Получим файл: rootCA.key

2. Создаем корневой сертификат с использованием сгенерированого ключа:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
  • rootCA.key — ключик, который мы сгенеририровали на прошлом шаге
  • 1024 — количество дней, сколько будет действовать корневой сертификат
  • rootCA.pem — файл корневого сертификата
  • days — количество дней действия

Получим файл: rootCA.pem

3. Создаем запрос на сертификат (CSR)

CSR — обычно это та информация, которая отправляется в УЦ, но в нашем случае мы подписываем сертификат самостоятельно.

openssl req -new -key rootCA.key -out org.csr
  • req — создать запрос на подпись
  • new — новый запрос
  • key — путь к закрытому ключу
  • out — выходной файл
  • Country name [Страна]: RU
  • State or Province [Край или область]: Murmanskaya obl. [можно пропустить]
  • Locality Name [Населенный пункт]: Umba
  • Organization Name: Gazeta Rassvet
  • Organization Unit Name: Redaction
  • Common Name: [обычно указывается адрес сайта] rassvet-gazete.ru
  • email: [можно пропустить]

Получим файл org.csr — содержащий информацию, необходимую для выпуска сертификата.

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

openssl x509 -req -in org.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out org.crt -days 365 -sha256
  • req — создать запрос на подпись
  • in — вводимый файл запроса
  • CA — файл корневого сертификата
  • CAkey — ключ корневого сертификата
  • out — выходной crt-файл
  • days — количество дней действия

Как создать самоподписанный SSL сертификат в Windows?

date

05.12.2022

user

itpro

directory

PowerShell, Windows 10, Windows 11, Windows Server 2019, Windows Server 2022

comments

комментариев 10

Большинству администраторов Windows, знакомых с темой PKI, известна утилита MakeCert.exe, с помощью которой можно создать самоподписанный сертификат. Эта утилита включена в состав Microsoft .NET Framework SDK и Microsoft Windows SDK. В современных версиях Windows 11/10/8.1 и Windows Server 2022/2019/2016/2012R2 вы можете создать самоподписанный сертификат с помощью встроенных командлетов PowerShell без использования дополнительных утилит.

New-SelfSignedCertificate: создать самоподписанный SSL сертификат в PowerShell

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

управление самоподписанными сертфикатми встроенным модулем powershell pki

Самоподписанные SSL сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Совет. Не забывайте, что вы можете использования полноценные бесплатные SSL сертификаты от Let’s Encrypt. Например, вы можете SSL сертификат Let’s Encrypt и привязать его к сайту IIS.

Для создания сертификата нужно указать значения -DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и -CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).

Чтобы создать новый SSL сертификат для DNS имени test.contoso.com (указывается FQDN имя) и поместить его в список персональных сертификатов компьютера, выполните команду:

New-SelfSignedCertificate -DnsName test.contoso.com -CertStoreLocation cert:\LocalMachine\My

New-SelfSignedCertificate командлет создать SSL сертификат в Windows

Команда вернет отпечаток нового сертификата (Thumbprint), Subject и EnhancedKeyUsageList. По умолчанию такой сертификат можно использовать для аутентификации клиента Client Authentication (1.3.6.1.5.5.7.3.2) или сервера Server Authentication (1.3.6.1.5.5.7.3.1).

Если вы запустите эту команду в PowerShell без прав администратор, появится ошибка:

New-SelfSignedCertificate : CertEnroll::CX509Enrollment::_CreateRequest: Access denied. 0x80090010 (-2146893808 NTE_PERM)

Если вы указали нестандартный криптографический провайдер CSPs (например, с помощью параметров -KeyAlgorithm «ECDSA_secP256r1» -Provider ‘Microsoft Smart Card Key Storage Provider’ ), убедитесь, что он установлен на компьютере (по умолчанию используется CSP Microsoft Enhanced Cryptographic Provider). Иначе появится ошибка:

New-SelfSignedCertificate: CertEnroll::CX509Enrollment::_CreateRequest: Provider type not defined. 0x80090017 (-2146893801 NTE_PROV_TYPE_NOT_DEF).

По-умолчанию генерируется самоподписанный сертификат со следующим параметрами:

  • Криптографический алгоритм: RSA;
  • Размер ключа: 2048 бит;
  • Допустимые варианты использования ключа: Client Authentication и Server Authentication;
  • Сертификат может использоваться для: Digital Signature, Key Encipherment ;
  • Срок действия сертификата: 1 год.
  • Криптопровадер: Microsoft Software Key Storage Provider

Данная команда создаст новый сертификат и импортирует его в персональное хранилище компьютера. Откройте оснастку certlm.msc и проверьте, что в разделе Personal хранилища сертификатов компьютера появился новый сертификат.

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

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

вывести параметры самоподписанного сертификата из powershell

Get-ChildItem -Path «Cert:\LocalMachine\My» | Where-Object Thumbprint -eq 76360EAA92D958ECF2717261F75D426E6DB5B4D1 | Select-Object *

PSPath : Microsoft.PowerShell.Security\Certificate::LocalMachine\My\76360EAA92D958ECF2717261F75D426E6 DB5B4D1 PSParentPath : Microsoft.PowerShell.Security\Certificate::LocalMachine\My PSChildName : 76360EAA92D958ECF2717261F75D426E6DB5B4D1 PSDrive : Cert PSProvider : Microsoft.PowerShell.Security\Certificate PSIsContainer : False EnhancedKeyUsageList : DnsNameList : SendAsTrustedIssuer : False EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty PolicyId : Archived : False Extensions : FriendlyName : HasPrivateKey : True PrivateKey : System.Security.Cryptography.RSACng IssuerName : System.Security.Cryptography.X509Certificates.X500DistinguishedName NotAfter : 12/2/2023 3:41:18 PM NotBefore : 12/2/2022 3:21:18 PM PublicKey : System.Security.Cryptography.X509Certificates.PublicKey RawData : SerialNumber : 24682351DA9C59874573BA2B5BB39874 SignatureAlgorithm : System.Security.Cryptography.Oid SubjectName : System.Security.Cryptography.X509Certificates.X500DistinguishedName Thumbprint : 76360EAA92D958ECF2717261F75D426E6DB5B4D1 Version : 3 Handle : 2007435579936 Issuer : CN=test.contoso.com Subject : CN=test.contoso.com

Примечание. Срок действия такого самоподписанного сертификата истекает через 1 год с момента его создания. Можно задать другой срок действия сертификата с помощью атрибута NotAfter.Чтобы выпустить сертификат на 3 года, выполните следующие команды:

$todaydate = Get-Date
$add3year = $todaydate.AddYears(3)
New-SelfSignedCertificate -dnsname test.contoso.com -notafter $add3year -CertStoreLocation cert:\LocalMachine\My

Можно создать цепочку сертификатов. Сначала создается корневой сертификат (CA), а на основании него генерируется SSL сертификат сервера:

$rootCert = New-SelfSignedCertificate -Subject «CN=TestRootCA,O=TestRootCA,OU=TestRootCA» -KeyExportPolicy Exportable -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm ‘RSA’ -HashAlgorithm ‘SHA256’ -Provider «Microsoft Enhanced RSA and AES Cryptographic Provider»
New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -DnsName «test2.contoso.com» -Signer $rootCert -KeyUsage KeyEncipherment,DigitalSignature

Чтобы изменить длину ключа сертификата и алгоритм шифрования, нужно использовать параметры –KeyAlgorithm , –KeyLength и –HashAlgorithm . Например:

New-SelfSignedCertificate -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm «SHA256»

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

New-SelfSignedCertificate -Type Custom -Provider «Microsoft Platform Crypto Provider» .

Провайдер Microsoft Platform Crypto Provider использует Trusted Platform Module чип устройства для создания ассиметричного ключа.
$Params = @»DnsName» = «mylocalhostname»
«CertStoreLocation» = «Cert:\\CurrentUser\\My»
«KeyUsage» = «KeyEncipherment»,»DataEncipherment»,»KeyAgreement»
«Type» = «DocumentEncryptionCert»
>
New-SelfSignedCertificate @Params

Как сгенерировать SAN (SubjectAltName) сертификат с помощью PowerShell?

Командлет New-SelfSignedCertificate позволяет создать сертификат с несколькими различными именами Subject Alternative Names (SAN).

Примечание. Утилита Makecert.exe, в отличии от командлета New-SelfSignedCertificate, не умеет создавать сертификаты с SAN.

Если создается сертификат с несколькими именами, первое имя в параметре DnsName будет использоваться в качестве CN (Common Name) сертификата. К примеру, создадим сертификат, у которого указаны следующие имена:

  • Subject Name (CN): adfs1.contoso.com
  • Subject Alternative Name (DNS): web-gw.contoso.com
  • Subject Alternative Name (DNS): enterprise-reg.contoso.com

Команда создания сертификата будет такой:

New-SelfSignedCertificate -DnsName adfs1.contoso.com,web_gw.contoso.com,enterprise_reg.contoso.com -CertStoreLocation cert:\LocalMachine\My

Сертификат на несколько DNS имен

Также можно сгенерировать wildcard сертификат для всего пространства имен домена, для этого в качестве имени сервера указывается *.contoso.com.

New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname *.contoso.com

Вы можете привязать сертификат не только к DNS имени, но и к IP адресу. Для этого вместе параметр -DnsName нужно использовать -TextExtension. Например:

New-SelfSignedCertificate -TextExtension @(«2.5.29.17=IPAddress=10.10.2.3&DNS=TESTServer1&DNS=TESTServer1.local»)

Как вы видите, в поле Subject Alternative Name теперь содержится IP адрес.

сгенерировать ssl сертификат для ip адреса

Экспорт самоподписаного сертификата в Windows

Для экспорта полученного сертификата c закрытым ключом в pfx файл, защищенный паролем, нужно получить его отпечаток (Thumbprint). Сначала нужно указать пароль защиты сертификата и преобразовать его в формат SecureString. Значение Thumbprint нужно скопировать из результатов выполнения команды New-SelfSignedCertificate.

$CertPassword = ConvertTo-SecureString -String “YourPassword” -Force –AsPlainText

Export-PfxCertificate -Cert cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\test.pfx -Password $CertPassword

Export-PfxCertificate - экспорт сертификата в файл

Можно экспортировать открытый ключ сертификата:

Export-Certificate -Cert Cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\testcert.cer

Проверьте, что в указанном каталоге появился CER (PFX) файл сертификата. Если щелкнуть по нему правой клавишей и выбрать пункт меню Install Certificate, можно с помощью мастера импорта сертификатов добавить сертификат в корневые доверенные сертификаты компьютера.

установить cer/pfx сертификат с помощью powershell

Выберите Store location -> Local Machine, Place all certificates in the following store -> Trusted Root Certification Authorities.

импорт сертфиката в доверенные корневые сертфикаты компьютера

Можно создать сертификат и сразу импортировать его в доверенные корневые сертификаты компьютера командами:
$cert=New-SelfSignedCertificate …..
$certFile = Export-Certificate -Cert $cert -FilePath C:\certname.cer
Import-Certificate -CertStoreLocation Cert:\LocalMachine\AuthRoot -FilePath $certFile.FullName

Полученный открытый ключ или сам файл сертификата можно распространить на все компьютеры и сервера в домене с помощью GPO (пример установки сертификата на компьютеры с помощью групповых политик).

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

В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).

В версии PowerShell 5 командлет New-SelfSifgnedCertificate теперь можно использовать чтобы выпустить сертификат типа Code Signing.

Вы можете обновить версию PowerShell согласно инструкции.

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

$cert = New-SelfSignedCertificate -Subject «Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:\LocalMachine\My

Set-AuthenticodeSignature -FilePath C:\PS\test_script.ps1 -Certificate $cert

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

Ошибка UnknownError при подписывании PowerShell скрипта самоподписанным сертификатом

Move-Item -Path $cert.PSPath -Destination «Cert:\CurrentUser\Root»

Теперь вы можете использовать этот самоподписанный сертификат для подписи PowerShell скриптов, драйверов или приложений.

Создать самоподписанный SSL сертификат SHA-256 для IIS

Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с использованием алгоритма шифрования SHA-1. Такие сертификаты многими браузерами считаются недоверенными, поэтому они могут выдавать предупреждение о небезопасном подключении. Командлет New-SelfSignedCertificate позволяет создать более популярный тип сертификата с помощью алгоритма шифрования SHA-256.

сгенерировать самоподписанный сертификат в iis

Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.

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

Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.

Также можно привязать SSL сертификат к сайту IIS по его отпечатку:

New-IISSiteBinding -Name «Default Web Site» -BindingInformation «*:443:» -CertificateThumbPrint $yourCert.Thumbprint -CertStoreLocation «Cert:\LocalMachine\My» -Protocol https

Предыдущая статьяПредыдущая статья Следующая статья Следующая статья

Sysadminium

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

Оглавление скрыть

Введение

Само-подписанные ssl-сертификаты бывают нужны в некоторых случаях:

  • При работе с тестовыми веб-серверами. Когда вам всё равно требуется протокол https. Или не требуется, но вам просто хочется использовать https вместо http. То удобно иметь свой центр сертификации и для каждого тестового сайта выпускать ssl-сертификаты.
  • При работе с внутренними web-серверами. Если у компании есть свой внутренний сайт или веб-приложение. И этот сайт доступен только из внутренней сети компании. То, вероятно, вам захочется использовать протокол https вместо http. А так как доступ к сайту есть у ограниченного числа компьютеров, то на них можно добавить свой корневой ssl-сертификат. И тогда, эти компьютеры начнут доверять внутренним сайтам компании.

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

На этом скриншоте, браузер не доверяет сайту, но если нажать на кнопку «Дополнительные«, то вы всё равно сможете перейти на сайт:

Браузер не доверяет сертификату сайта

А на этом скриншоте браузер доверяет сайту. Об этом говорит то, что сайт открылся без предупреждений и замочек в адресной строке:

Браузер доверяет сертификату сайта

В этой статье я проделаю следующее:

  • На Debian 11 установлю apache2 и настрою его работу на https (с сертификатами по умолчанию для localhost).
  • Покажу что клиенты пока не доверяют этому сертификату.
  • Создам центр сертификации на этом же сервере. А именно:
    • создам закрытый корневой ключ и открытый корневой ключ (он же корневой сертификат);
    • с помощью этой пары ключей буду выпускать сертификаты для доменов;
    • установлю выпущенный корневой сертификат на компьютер клиента (на windows);
    • с помощью корневого ключа и сертификата, я выпущу ключ и сертификат для домена (для веб-сервера).

    Устанавливаю apache2

    Устанавливаю web-сервер apache2:

    $ sudo apt install apache2

    Настраиваю его работу по протоколу https:

    $ sudo a2enmod ssl $ sudo a2ensite default-ssl.conf $ sudo systemctl restart apache2

    Проверяю доверие к ssl-сертификату сайта, открыв его по https:

    Браузер Chrome не доверяет сертификату с которым работает сайт

    Как видите, доверия нет.

    Создаю центр сертификации

    Теория

    Протокол HTTPS это объединение протоколов HTTP + SSL/TLS. А протокол TLS это асинхронное шифрование. То есть создаётся пара ключей. И то, что один ключ может зашифровать, другой может расшифровать и наоборот. В протоколе HTTPS эти ключи не равнозначные:

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

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

    Корневая пара ключей обычно не подтверждает никакой домен. А используется для создания промежуточных сертификатов или сертификатов для доменов (для web-серверов).

    Обычно, когда создают ssl-сертификат для домена, то для безопасности отнимают у него право создания дочерних сертификатов.

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

    Сервер на котором создают корневые сертификаты, а затем с их помощью выпускают сертификаты для доменов называют — центр сертификации.

    Создаю корневой закрытый ключ

    Для создания ssl/tls сертификатов можно использовать утилиту openssl, она не требует админских прав.

    Создаю корневой закрытый ключ:

    $ openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc . +++++ . +++++ Enter PEM pass phrase: Verifying - Enter PEM pass phrase:

    Разберу эту команду:

    • genpkey — команда для создания закрытого ключа;
    • -algorithm RSA — алгоритм асинхронного шифрования, именно он используется для выделения открытого ключа из этого закрытого;
    • -out rootCA.key — получаемый файл закрытого ключа;
    • -aes-128-cbc — алгоритм симметричного шифрования, которым мы зашифруем файл закрытого ключа с помощью пароля. Пароль нужно будет ввести.

    Создаю корневой сертификат

    Теперь создаю корневой сертификат (открытый ключ):

    $ openssl req -x509 -new -key rootCA.key -sha256 -days 3650 -out rootCA.crt Enter pass phrase for rootCA.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Moscow Locality Name (eg, city) []:Moscow Organization Name (eg, company) [Internet Widgits Pty Ltd]:Sysadminium Organizational Unit Name (eg, section) []:. Common Name (e.g. server FQDN or YOUR name) []:Sysadminium
    • req — создаёт сертификаты или запросы на сертификаты;
    • -x509 — будем создавать сертификат а не запрос;
    • -new — создаём новый сертификат (нужно будет ввести значения некоторых полей в сертификате);
    • -key rootCA.key — используемый закрытый ключ, из которого нужно создать открытый;
    • -sha256 — алгоритм хеширования, чтобы создать подпись ключа;
    • -days 3650 — выпускаем сертификат на 10 лет (обратите внимание что закрытые ключи не имеют срока жизни а сертификаты имеют);
    • -out rootCA.crt — получаемый сертификат.

    Итак, я создал пару ключей:

    $ ls -l root* -rw-r--r-- 1 alex alex 1306 сен 9 11:26 rootCA.crt -rw------- 1 alex alex 1874 сен 9 11:19 rootCA.key

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

    Создаю файл порядковых номеров для выпуска сертификатов, в нём следует указать два нуля:

    $ nano rootCA.srl 00

    Дальше нужно передать корневой сертификат на клиентские компьютеры и установить его в доверенные корневые центры сертификации. Я забираю корневой сертификат по протоколу sftp, показывать этот процесс думаю не нужно.

    Установка корневого сертификата на Winows

    Устанавливаются сертификаты на Windows очень просто. Дважды щелкаем по сертификату и открывается окно с его свойствами. Дальше нажимаем на кнопку «Установить сертификат«:

    Установка сертификата на Windows 10

    Установить можно для текущего пользователя или для всего компьютера. Так как у меня это тестовая установка, я выберу «Текущий пользователь«:

    Установка сертификата на Windows 10 для Текущего пользователя

    После нажатия на кнопку «Далее» нужно выбрать «Поместить все сертификаты в следующее хранилище» и нажать кнопку «Обзор«:

    Установка сертификата на Windows 10. Выбор хранилища

    В открывшемся окне выбираем «Доверенные корневые центры сертификации«:

    Установка сертификата на Windows 10. Выбор хранилища

    Затем нажимаем кнопку «ОК«, «Далее» и «Готово«.

    И наконец, подтверждаем установку сертификата:

    Подтверждение установки корневого сертификата

    И затем нужно будет ещё раз нажать кнопку «ОК«.

    Если вы еще раз откроете свойства сертификата (двойным щелчком по нему), то увидите что система начала ему доверять:

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

    Создаю ключ и сертификат для домена

    Теперь, с помощью корневых ключей мы можем создать ключи для домена. У меня будет домен — site.sysadminium.ru.

    Утилита openssl не может без конфигурационного файла добавлять некоторые поля. А нам нужно будет в сертификат добавить поле subjectAltName. Без этого поля браузер Chrome не доверяет сертификату.

    Поэтому вначале я создаю следующий конфиг:

    $ nano sysadminium.cnf [ req ] default_bits = 2048 distinguished_name = req_distinguished_name req_extensions = req_ext [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = RU stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Moscow localityName = Locality Name (eg, city) localityName_default = Moscow organizationName = Organization Name (eg, company) organizationName_default = Sysadminium commonName = Common Name (eg, YOUR name or FQDN) commonName_max = 64 commonName_default = site.sysadminium.ru [ req_ext ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = DNS:site.sysadminium.ru

    В блоке [ req ] — настраивается команда req:

    • default_bits = 2048 — длина ключа по умолчанию.
    • distinguished_name = req_distinguished_namedistinguished_name — это поля в сертификате, например Common Name, organizationName и другие. Для этих полей мы создадим блок req_distinguished_name ниже.
    • req_extensions = req_ext — расширение для req, здесь мы можем добавить дополнительные поля в сертификат. А в этом параметре мы просто указываем что ниже будет блок req_ext с дополнительными полями.

    Блок [ req_distinguished_name ] — служит для конфигурации полей сертификата.

    А блок в блок [ req_ext ] — можно добавить некоторые расширяющие свойства сертификата:

    • basicConstraints = CA:FALSE — полученные сертификаты нельзя будет использовать как центр сертификации. Другими словами, забираем у сертификатов для доменов право создавать дочерние сертификаты.
    • keyUsage = nonRepudiation, digitalSignature, keyEncipherment — созданный ключ будет иметь следующие свойства: неотказуемость (если ключом что-то подписали то аннулировать подпись невозможно), цифровая подпись (сертификат можно использовать в качестве цифровой подписи), шифрование ключей (сертификат можно использовать для симметричного шифрования). Об этих свойствах на английском хорошо написано здесь.
    • subjectAltName = DNS:site.sysadminium.ru — а здесь указываем поле subjectAltName и его значение. Как я уже говорил, без этого поля браузер Chrome не доверяет сертификату.

    Создаю закрытый ключ для домена

    Теперь я создам закрытый ключ для домена:

    alex@deb-11:~$ openssl genpkey -algorithm RSA -out site.key . +++++ . +++++

    Создаю файл запроса для домена

    С помощью закрытого ключа для домена создаю файл запроса на сертификат:

    $ openssl req -new -key site.key -config sysadminium.cnf -reqexts req_ext -out site.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [RU]: State or Province Name (full name) [Moscow]: Locality Name (eg, city) [Moscow]: Organization Name (eg, company) [Sysadminium]: Common Name (eg, YOUR name or FQDN) [site.sysadminium.ru]:

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

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

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

    $ openssl x509 -req -days 730 -CA rootCA.crt -CAkey rootCA.key -extfile sysadminium.cnf -extensions req_ext -in site.csr -out site.crt
    • x509 — создание сертификата путём подписывания;
    • -req — если подписывать будем файл запроса, то нужно использовать эту опцию;
    • -days 730 — сертификат я делаю на 2 года;
    • -CA rootCA.crt -CAkey rootCA.key — указываю корневую пару ключей;
    • -extfile sysadminium.cnf — файл, содержащий расширения сертификатов. Без этой опции расширения из файла запроса не попадут в сертификат;
    • -in site.csr -out site.crt — файл запроса и файл сертификата.

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

    $ ls -l site.* -rw-r--r-- 1 alex alex 1257 сен 9 14:27 site.crt # сертификат -rw-r--r-- 1 alex alex 1098 сен 9 14:17 site.csr # запрос -rw------- 1 alex alex 1704 сен 9 14:15 site.key # ключ

    Перенастраиваю apache2

    Кинем сертификат и ключ в следующие каталоги:

    $ sudo cp site.crt /etc/ssl/certs/ $ sudo cp site.key /etc/ssl/private/

    И настроим apache2 на использование этих ключей:

    $ sudo nano /etc/apache2/sites-enabled/default-ssl.conf SSLCertificateFile /etc/ssl/certs/site.crt SSLCertificateKeyFile /etc/ssl/private/site.key

    Применим изменение конфига apache2:

    $ sudo systemctl reload apache2

    И проверим как открывается наш сайт с клиента на котором установлен наш корневой сертификат:

    Браузер доверяет сертификату сайта

    Как видим, браузер начал доверять нашему тестовому сайту.

    Смотрим на сертификат из Chrome

    Нажмите на замочек возле адреса сайта (он виден на скриншоте выше). Дальше нажмите на «Безопасное подключение» и на «Действительный сертификат«. Откроются свойства сертификата:

    Свойства сертификата из Chrome

    На вкладке «Подробнее» вы можете изучить и остальные свойства.

    Например, помните мы указывали алгоритм ассиметричного шифрования — RSA:

    Алгоритм подписи сертификатов

    А помните, мы создали файл для серийных номеров выпускаемых сертификатов и записали в нём «00». Давайте посмотрим на серийный номер нашего сертификата:

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

    Можем посмотреть на сам открытый ключ:

    Открытый ключ

    А в расширениях видно альтернативное имя, которое так нужно браузеру Chrome для доверия к сертификату:

    Альтернативное имя

    Раньше браузеры проверяли только CN:

    Common Name

    А сейчас, если есть альтернативное имя, то они даже не смотрят в параметр Common Name. А Chrome требует это поле и вообще перестал смотреть на Common Name.

    Настраиваю веб-сервер Nginx

    Ну и наконец я покажу как настроить Nginx на использование наших сертификатов.

    Для начала выключу apache2 и установлю nginx:

    $ sudo systemctl stop apache2.service $ sudo apt install nginx

    И настрою его. Нужно рас-комментировать и поменять значения некоторых полей:

    $ sudo nano /etc/nginx/sites-enabled/default listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl_certificate /etc/ssl/certs/site.crt; ssl_certificate_key /etc/ssl/private/site.key;
    $ sudo systemctl reload nginx

    И наконец, проверю доверие к ssl-сертификату сайта, обновив страничку в браузере.

    Браузер доверяет сертификату сайта

    Здесь apache2 создал свою индексную страничку, поэтому оба веб сервера (nginx и apache2) используют одну и туже страницу. Но как вы помните, я отключил apache2, так что у меня точно отвечает nginx.

    Итог

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

    • rootCA.key — корневой закрытый ключ. Используется для создания дочерних сертификатов. Обычно лежит на сервере центра сертификации и зашифрован с помощью пароля.
    • rootCA.srl — корневой сертификат. Используется для создания дочерних сертификатов. Его нужно распространить на все ваши компьютеры и установить в хранилище корневых сертификатов. Его тоже можно защитить паролем, но я этого не делал.
    • site.key — ключ для домена (для веб сервера). Его можно было сгенерировать на веб-сервере и не передавать на сервер центра сертификации. Но в моём примере был один сервер и для веб-сервера и для центра сертификации.
    • site.csr — файл запроса на сертификат для домена. Его также можно было сделать на веб-сервере и передать в центр сертификации, чтобы там выпустить сертификат.
    • site.crt — сертификат для домена (для веб сервера). Этот файл создаётся из файла запроса на сертификат с помощью пары корневых ключей.

    Также я показал, как использовать созданные сертификаты для настройки веб серверов: apache2 и nginx.

    Если вы интересуетесь настройками веб-серверов на Linux, то возможно вам также понравится эта статья:

    Создаём свой центр сертификации на Linux

    Имя статьи
    Создаём свой центр сертификации на Linux

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

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *