что такое ssl, tls, установка и настройка сертификата

Что такое ssl, tls

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2022 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

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

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

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

Что нужно сделать чтобы установить ssl-сертификат

В зависимости от используемого хостинга или сервера часть шагов может отличаться или отсутствовать, но в целом классический процесс получения и установки сертификата сводится к следующим шагам:

  1. приобрести SSL-сертификат;
  2. сгенерировать CSR запрос на сертификат;
  3. выпустить SSL-сертификат;
  4. установить SSL-сертификат на хостинг или сервер;
  5. внести изменения в настройки сайта.

[ ca ]

Раздел [ca] является обязательным. Заморачиваться с ним не будем и скажем ему, что хотим свою секцию по умолчанию.

[ ca ] 
default_ca = CA_default

[ ca_default ]

В секции [CA_default] зададим значения по умолчанию. Сначала пропишем пути основных директорий

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге
# (чтоб не редактировать в ста местах)
dir = /root/ca/RootCA
certs = $dir/certs
new_certs_dir = $certs
private = $dir/certs
crl_dir = $dir/crl
serial = $dir/serial 
database = $dir/index.txt
RANDFILE = $dir/private/.rand
  • dir – это исключительно наша переменная, для того, чтоб сэкономить нам время. Тут мы укажем пусть до основной директории того ЦС, для которого конфигурация будет предназначена;
  • certs – эта переменная для сертификатов, ей мы указываем нашу папку;
  • new_certs_dir – аналогично certs (в разных версиях OpenSSL разные переменные для сертификатов), поэтому указываем обе;
  • private – в эту переменную передаем место нашей приватной директории, в описании директорий, мы уже говорили, что тут храним приватные ключи;
  • crl_dir – как уже говорили, тут будет путь к директории отозванных сертификатов;
  • serial – указываем наш файл serial;
  • database – текстовая база данных, наш index.txt;
  • RANDFILE – случайный файл для случайных данных.
Похожее:  Настройка цифрового телевидения - Медиа Холдинг ТВК


Идем дальше и укажем теперь определенные параметры

# Сертификат и ключ, которым будет подписан другой сертификат,
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key = $private/RootCA.key.pem
certificate = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber = $dir/crlnumber
crl = $crl_dir/RootCA.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

# используемый алгоритм хеширования
default_md = sha256

name_opt = ca_default
cert_opt = ca_default

default_days = 365
preserve = no
policy = policy_root

policy
policy — в разных конфигурациях мы укажем разные значения. У нас их будет несколько: policy_root, policy_intermediate_person, policy_intermediate_server, policy_intermediate_code.
policy_root — будет в конфигурации для корневого сертификата, и у него будет заданы жесткие правила для подписи промежуточных.
policy_intermediate — а эта секция правил будет в конфигурации промежуточных, и правила подписи будут не такими строгими.

Параметры:

Напишем политики, о которых мы сказали в примечании

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

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

[ req ]

Параметры из раздела [req] применяются при создании сертификатов или запросов на подпись сертификата.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha256

# Расширение при использовании опции -x509.
x509_extensions = root_ca


Что можно сказать тут:

[ req_distinguished_name ]

Как мы уже сказали, тут перечислим поля, которые нам нужны для сертификата.

[ req_distinguished_name ]
countryName = Country Name (2 letter code) (C)
countryName_min = 2
countryName_max = 2
countryName_default = RU

stateOrProvinceName = State or Province Name (S)
stateOrProvinceName_default = Krasnoyarskiy kray

localityName = Locality Name (L)
localityName_default = Norilsk

0.organizationName = Organization Name (O)
0.organizationName_default = CertService

organizationalUnitName = Organizational Unit Name (OU) organizationalUnitName_default = CertService. IT-Department.

commonName = Common Name (CN)
#commonName_default = CertService.info

emailAddress = Email Address
emailAddress_max = 60
#emailAddress_default = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

С этим все, теперь идем дальше.

Ssl certificate problem: certificate has expired

Что делать, если при запросах curl вылезает ошибка:

Ssl-авторизация на сайте | блог валерия леонтьева

Что такое SSL, TLS, установка и настройка сертификатаВозникла задача: дать пользователю возможность авторизации на сайте в защищенном режиме. Т.е. так, чтобы его пароль не могли перехватить через канал связи. Какие есть варианты решения задачи, как решают эту задачу другие? Об этом чуть подробнее.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

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

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

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

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

Бесплатные сертификаты ssl/tls от let’s encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

  1. Они бесплатные;
  2. Подойдут большинству проектов;
  3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

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

Видео установки и настройки ssl сертификата в хостинге beget

Если Вы хотите установить SSL, TLS сертификат на сайт, который расположен в Beget, Вам пригодится следующая видеоинструкция:

Выпуск ssl-сертификата

Теперь, когда есть запрос, на основании него можно выпустить сертификат.

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

После отправки запроса подтвердите владение доменом. Может быть доступно от одного до четырех способов подтверждения:

Генератор конфигурационных файлов ssl

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

Генерация csr запроса на сертификат

CSR (Certificate Signing Request) – это зашифрованный запрос на получение сертификата, включает в себя информацию о домене и организации.

CSR может быть сгенерирован одним из способов:

  1. Автоматически в процессе заказа SSL-сертификата.
  2. Онлайн, через CSR генератор, например у или .
  3. Самостоятельно на собственном веб-сервере.

В независимости от способа, в результате вы должны получить 2 файла (или их текстовое содержание) — файл запроса (domain.csr) и файл приватного ключа (private.key). Файл запроса потребуется для генерации сертификата. А приватный ключ понадобится в дальнейшем, его вместе с сертификатом нужно будет установить на хостинг или сервер.

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

Все данные запроса должны заполняться на английском языке.

Генерация csr запроса на собственном сервере

Потребуется криптографический пакет с открытым исходным кодом – . Он входит в состав большинства UNIX-подобных операционных систем.

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

Подключитесь к серверу по SSH и перейдите в домашнюю директорию.

cd ~

Сгенерируйте закрытый ключ.

openssl genrsa -out private.key 4096

В команде выше:

  • private.key – выходной файл, который будет содержать ключ;
  • 4096 – размер ключа, резже 2048.

На запрос «Enter pass phrase for private.key» укажите пароль для защиты закрытого ключа, а затем «Verifying – Enter pass phrase for private.key» – подтвердите его, повторив ввод пароля еще раз.

Закрытый ключ будет создан и сохранен в файл под именем private.key.

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

Далее сгенерируйте CSR запрос.

openssl req -new -key private.key -out domain.csr -sha256

В команде выше:

  • private.key – созданный на предыдущем этапе закрытый ключ;
  • domaine.csr – выходной файл с CSR запросом.

На запрос «Enter pass phrase for private.key» введите пароль от закрытого ключа.

Далее последовательно латинскими символами укажите следующие данные:

CSR запрос на сертификат будет сохранен в файле domain.csr в виде закодированного текста.

Проверить корректность введенных данных можно, выполнив следующую команду.

openssl req -noout -text -in domain.csr

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

less private.key

или

less domain.csr

Для выхода нажмите клавишу Q.

Для конечных сертификатов

Клиентские (для аутентификации и почты)

Для корневого сертификата

Для корневого сертификата у нас секция будет называться root_ca.

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
  • subjectKeyIdentifier – идентификатор субъекта. Может быть шестнадцатеричной строкой (hex), либо хешем (hash);
  • authorityKeyIdentifier – этот параметр допускает всего два значения keyid и issuer. Keyid – копирует идентификатор ключевого слова из родительского, если не получается получить и стоит always, то вернется ошибка. Issuer копирует issuer(подписанта) и серийный номер из сертификата, которым подписан. Он работает, только в том случае, если не работает keyid;
  • basicConstraints – CA – если true, то разрешает быть issuer’ом, false – нет (для уточнения: issuer – эмитет (подписант), т.е. может подписывать сертификаты);
  • keyUsage – что может делать сертификат;

Значение ключа keyUsage|Описание
— — serverAuth Аутентификация веб-сервера SSL / TLS.
clientAuth Аутентификация веб-клиента SSL / TLS.
codeSigning Подписание кода.
emailProtection Защита электронной почты (S / MIME).
timeStamping Доверенная отметка времени.
msCodeInd Microsoft Индивидуальная подмена кода (аутентификация).
msCodeCom Microsoft Подписание коммерческого кода (аутентификация).
msCTLSign Microsoft Доверенный лист подписей.
msSGC Microsoft Сервер криптографической защиты.
msEFS Microsoft Шифрование файловой системы.
nsSGC Netscape Server Gated Crypto.

Для промежуточных сертификатов

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

Важное замечание:
Параметр basicConstraints содержит «pathlen:0». pathlen указывает максимальное количество ЦС, которые могут появляться ниже этого в цепочке. Поэтому, если у вас есть ЦС с нулевой точкой, он может использоваться только для подписывания сертификатов конечных пользователей, а не для дальнейших ЦС.

То есть, если вы хотите создать промежуточные сертификаты отделам, а потом пользователям, то pathlen должен будет быть равен 1, и также рекомендую создать расширение для таких сертификатов с параметром равным нулю.

Как настроить поддержку backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

Как усилить безопасность ssl, tls

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.Чтобы добиться заветного A , нужно правильно настроить NGINX.Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

Как установить ssl-сертификат в панели управления ispmanager

Войдите в панель управления ISPmanager.

Перейдите в раздел «SSL-сертификаты» и нажмите «Создать».

Укажите тип сертификата «Существующий» и нажмите «Далее».

На открывшейся странице заполните поля:

  • Имя SSL-сертификата – любое имя латиницей, под ним сертификат будет отображаться в панели управления;
  • SSL-сертификат – содержимое файла SSL-сертификата;
  • Ключ SSL-сертификата – приватный ключ сертификата;
  • Цепочка SSL-сертификатов – последовательно укажите сначала корневой сертификат, а затем с новой строки без пробела – промежуточный.

Затем нажмите Завершить.

В разделе «SSL-сертификаты» появится добавленный сертификат.

Как установить ssl-сертификат на 1c-bitrix

Воспользуйтесь официальными инструкциями от 1С-Битрикс:

Как установить ssl-сертификат на сервер с apache

Понадобится файл SSL-сертификата, назовите его domain.crt и приватный ключ, который был получен на этапе генерации CSR запроса на сертификат, переименуйте его в domain.key.

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

Все 3 файла загрузите на сервер в директорию /etc/ssl/

Откройте конфигурационный файл Apache сайта, для которого устанавливается сертификат. Если сайт один, конфигурационный файл скорее всего будет одним из указанных ниже:

Как установить ssl-сертификат на сервер с nginx

Объедините три сертификата (SSL-сертификат, корневой и промежуточный) в один файл. Для этого с помощью блокнота или другого редактора создайте текстовый документ с именем domain.crt и поочередно поместите в него содержимое каждого из сертификатов (без лишних пробелов и пустых строк).

-----BEGIN CERTIFICATE-----
#SSL-сертификат#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#Корневой сертификат#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#Промежуточный сертификат (один или несколько)#
-----END CERTIFICATE-----

Так же понадобится приватный ключ, который был получен на этапе генерации CSR запроса на сертификат. Переименуйте его в domain.key.

Оба файла загрузите на сервер в директорию /etc/ssl/ или /etc/nginx/ssl/

Отредактируйте виртуальный хост сайта, для которого устанавливается сертификат. Файл /etc/nginx/sites-available/site.conf или или другой, в зависимости от особенностей сервера.

Как установить ssl-сертификат на хостинг

Найдите раздел SSL панели управления хостингом.

Если сертификат куплен у того же хостинг-провайдера где размещен ваш сайт, скорее всего нужно будет лишь связать сертификат с доменом (хостингом), например как на скриншоте ниже для хостинг-провайдера .

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

Аналогичным образом процедура выглядит для других хостеров. На скриншоте ниже скриншот с примером для Hostland.

Подробные инструкции можно найти у своего хостинг провайдера.

Подготовка и тестирование конфигурации ssl, tls

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час).

И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки.

  • Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
  • Ошибка валидации имеет лимит 60 раз в час.

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

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

Если статья помогла или понравилась, пожалуйста поделитесь ей в соцсетях.

Приобретение ssl-сертификата

Итак, вы знаете, что такое SSL и определились в выборе сертификата, далее его нужно приобрести.

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

Рекомендую хостинги:

  • (промокод на скидку для заказа домена или хостинга: 2229-CC0A-AC4D-C31B)
  • (месяц бесплатно)

На этапе покупки укажите тип сертификата и домен для которого он приобретается. Затем оплатите сертификат.

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

Работаем с сертификатами


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

openssl genrsa -aes256 -out /root/ca/RootCA/private/RootCA.key.pem 4096 chmod 400 /root/ca/RootCA/private/RootCA.key.pem

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

openssl req -config /root/ca/config/RootCA.cnf 
-key /root/ca/RootCA/private/RootCA.key.pem 
-new -x509 -days 7300 -sha256 -extensions root_ca 
-out /root/ca/RootCA/certs/RootCA.cert.pem
chmod 444 /root/ca/RootCA/certs/RootCA.cert.pem

Проверяем валидность сертификата

openssl x509 -noout -text -in /root/ca/RootCA/certs/RootCA.cert.pem

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

#Создаем приватный ключ 
openssl genrsa -aes256 
-out /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 4096
chmod 400 /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem
#Создаем запрос
openssl req -config /root/ca/config/PersonIntermediateCA.cnf -new -sha256 
-key /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 
-out /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem #Создаем подписанный сертификат
openssl ca -config /root/ca/config/RootCA.cnf -extensions intermediate_ca 
-days 3650 -notext -md sha256 
-in /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem 
-out /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem

Using configuration from /root/ca/config/RootCA.cnf
Enter pass phrase for /root/ca/RootCA/private/RootCA.key.pem: secret

Check that the request matches the signature
Signature ok
Certificate Details:
...
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

chmod 444 /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem


Проверяем валидацию

openssl verify -CAfile /root/ca/RootCA/certs/RootCA.cert.pem  /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem
#result: /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem: OK

Идем дальше и создаем certificate chain

certificate chain — эта цепочка нам нужна, когда у клиента нет корневого, или промежуточного сертификата.

Если в AD мы ничего не добавили, то клиенту нужна связка конечный промежуточный корневой.
Если мы добавим в AD только корневой сертификат, то certificate chain нам нужен в связке конечный промежуточный.
Если в AD добавлены и промежуточный сертификаты, то certificate chain нам не нужен

cat /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem

cat /root/ca/CodeIntermediateCA/certs/CodeIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem cat

/root/ca/ServerIntermediateCA/certs/ServerIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem

Расширения

Следующие несколько секций — это расширения, которые могут использоваться при создании сертификатов. К примеру, при передаче аргумента командой -extensions root_ca будет применяться секция [ root_ca ].

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

Если сертификаты нужно создавать на регулярной основе — можно воспользоваться скриптом

Для корректной работы скрипта требуется наличие установленных программ: mail-client/mailx (mail — консольный клиент для отправки почтовых сообщений, app-arch/rar (архиватор), app-arch/sharutils (перекодировщик двоичных файлов в текстовый вид для почтовых вложений).

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

Клиент (используем -extensions

Структура директорий на сервере ca

Наша основная директория /root/ca. А вот у нее внутри уже видим следующее:

Типы ssl-сертификатов

Существует несколько типов SSL-сертификатов.

Сертификат с проверкой домена (Domain Validation), например, DomainSSL или AlphaSSL. Самый простой и дешевый тип SSL-сертификатов. Подтверждает только домен. Не содержит информации о владельце, поэтому не предназначен для оказания коммерческих услуг на сайте. Физические лица могут использовать только этот тип сертификатов, но он доступен и для юридических лиц.

Сертификат с проверкой домена и организации (Organization Validation), например, OrganizationSSL. Подтверждает не только домен, но и его принадлежность компании. Центр авторизации проверит ее существование, а пользователь сможет увидеть ее название на сайте в информации о сертификате, кликнув на «замок» рядом с адресной строкой браузера.

Сертификат с расширенной проверкой организации (Extended Validation) – например, ExtendedSSL. Считается самым надёжным и предназначен для крупных организаций. При его оформлении центр сертификации проведет расширенную проверку налоговой и коммерческой деятельности компании.

Еще один термин, который встретится при выборе сертификата – WildCard. Он означает поддержку поддоменов. Один SSL-сертификат с WildCard сможет работать и на основном домене, и на поддоменах без ограничений на их количество.

При заказе сертификатов Extended Validation или Organization Validation, центр сертификации может запросить следующие виды документов:

  • Свидетельство ИНН / КПП;
  • Свидетельство ОГРН;
  • Приказ о назначении директора;
  • Свидетельство о регистрации доменного имени;
  • Устав организации (первые 3 и последние 3 страницы);
  • Счета на оплату телефонных разговоров с номера компании за последние 3 месяца, с обязательным указанием в счетах названия и номера телефона организации и названия организации-поставщика услуг.

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

Установка ssl-сертификата

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

Установка сертификата ssl, tls от let’s encrypt

Вводим команду в консоль Putty:

Уходим в консоль


Базовую конфигурацию мы подготовили, теперь можно и в консоль идти 🙂

Создаем рабочие директории

mkdir -p /root/ca/config
mkdir -p /root/ca/{RootCA,PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/{certs,crl,newcerts,private}
mkdir -p /root/ca/{PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/csr

Выставим всем private права 400

chmod 400 /root/ca/RootCA/private
chmod 400 /root/ca/PersonIntermediateCA/private
chmod 400 /root/ca/ServerIntermediateCA/private
chmod 400 /root/ca/CodeIntermediateCA/private


Создаем файлы конфигурации

touch /root/ca/config/RootCA.cnf
touch /root/ca/config/PersonIntermediateCA.cnf cp
touch /root/ca/config/ServerIntermediateCA.cnf cp 
touch /root/ca/config/CodeIntermediateCA.cnf
RootCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/RootCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/RootCA.key.pem
certificate       = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/RootCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_root

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

PersonIntermediateCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/PersonIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/PersonIntermediateCA.key.pem
certificate       = $certs/PersonIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/PersonIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_person

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ user_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "Client certificates"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment 
extendedKeyUsage = clientAuth, emailProtection

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

ServerIntermediateCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/ServerIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/ServerIntermediateCA.key.pem
certificate       = $certs/ServerIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/ServerIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_server

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
# Серверный
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

CodeIntermediateCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/CodeIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/CodeIntermediateCA.key.pem
certificate       = $certs/CodeIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/CodeIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_code

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ code_cert ]
# Для подписи кода
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Code Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = digitalSignature
extendedKeyUsage = codeSigning, msCodeInd, msCodeCom

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Создадим наши недо-базы данных

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

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