Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ Сертификаты

. Проверка правильности порядка установки CA сертификатов.

На данном сервере, где выполнялись работы с openssl, установим веб-сервер, подключим домен ukrnames.idua.org и установим для него SSL-сертификат.

Т.к. веб-сервер не имеет доступа к папке /etc/ssl/certs/ , то копируем ключ, сертификат и промежуточные сертификаты в новосозданную папку /var/www/ssl/

В файле конфигурации веб-сервера подключаем файлы SSL-сертификата. Но чтобы все корректно работало, нужно создать файл для промежуточных сертификатов (к примеру ca.pem) и внести в него с определенной последовательностью данные файлов промежуточных сертификатов (ca_1, ca_2, ca_3).

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

Получаем данные об издателе основного сертификата:

openssl x509 -in /var/www/ssl/server.crt -noout -text | grep Issuer:
Получаем вывод
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA

Теперь получим данные о промежуточных сертификатах ca_1, ca_2, ca_3 (нужно обращать внимание только на поля “Issuer:” и “Subject:”):

openssl x509 -in /var/www/ssl/ca_1 -noout -text | egrep "Subject:|Issuer:"
openssl x509 -in /var/www/ssl/ca_2 -noout -text | egrep "Subject:|Issuer:"
openssl x509 -in /var/www/ssl/ca_3 -noout -text | egrep "Subject:|Issuer:"

Получим вывод на экран:

Сопоставив данные сертификата и промежуточных сертификатов, можно сделать вывод, что после основного сертификата первым промежуточным должен идти сертификат ca_3, т.к. в поле “Subject:” раздел CN файла ca_3 совпадает с полем “Issuer:” разделом CN (CN=COMODO RSA Domain Validation Secure Server CA).

Далее смотрим на поле “Issure:” раздел CN файла ca_3 (CN=COMODO RSA Certification Authority). Ищем в выводах файлов ca_2 и ca_1 совпадение в полях “Subject:” . Совпадение найдено в файле ca_2, данный файл мы будем подключать вторым.

И методом исключения, файл ca_1 будет подключаться самым последним.

Выполняем команды для объединения всех файлов  промежуточных сертификатов(ca_1, ca_2, ca_3) в один (ca.pem):

 cat /var/www/ssl/ca_3 > /var/www/ssl/ca.pem
 cat /var/www/ssl/ca_2 >> /var/www/ssl/ca.pem
 cat /var/www/ssl/ca_1 >> /var/www/ssl/ca.pem

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

openssl s_client -connect ukrnames.idua.org:443

Получим вывод на экран правильной цепочки подключения сертификатов:

How to generate a self-signed ssl certificate using openssl?

Am I missing something? Is this the correct way to build a self-signed certificate?

It’s easy to create a self-signed certificate. You just use the openssl req command. It can be tricky to create one that can be consumed by the largest selection of clients, like browsers and command line tools.

It’s difficult because the browsers have their own set of requirements, and they are more restrictive than the IETF. The requirements used by browsers are documented at the CA/Browser Forums (see references below). The restrictions arise in two key areas: (1) trust anchors, and (2) DNS names.

Modern browsers (like the warez we’re using in 2021/2021) want a certificate that chains back to a trust anchor, and they want DNS names to be presented in particular ways in the certificate. And browsers are actively moving against self-signed server certificates.

Some browsers don’t exactly make it easy to import a self-signed server certificate. In fact, you can’t with some browsers, like Android’s browser. So the complete solution is to become your own authority.

In the absence of becoming your own authority, you have to get the DNS names right to give the certificate the greatest chance of success. But I would encourage you to become your own authority. It’s easy to become your own authority, and it will sidestep all the trust issues (who better to trust than yourself?).


This is probably not the site you are looking for!
The site’s security certificate is not trusted!

This is because browsers use a predefined list of trust anchors to validate server certificates. A self-signed certificate does not chain back to a trusted anchor.

The best way to avoid this is:

  1. Create your own authority (i.e., become a CA)
  2. Create a certificate signing request (CSR) for the server
  3. Sign the server’s CSR with your CA key
  4. Install the server certificate on the server
  5. Install the CA certificate on the client

Step 1 — Create your own authority just means to create a self-signed certificate with CA: true and proper key usage. That means the Subject and Issuer are the same entity, CA is set to true in Basic Constraints (it should also be marked as critical), key usage is keyCertSign and crlSign (if you are using CRLs), and the Subject Key Identifier (SKI) is the same as the Authority Key Identifier (AKI).

To become your own certificate authority, see *How do you sign a certificate signing request with your certification authority? on Stack Overflow. Then, import your CA into the Trust Store used by the browser.

Steps 2 — 4 are roughly what you do now for a public facing server when you enlist the services of a CA like Startcom or CAcert. Steps 1 and 5 allows you to avoid the third-party authority, and act as your own authority (who better to trust than yourself?).

The next best way to avoid the browser warning is to trust the server’s certificate. But some browsers, like Android’s default browser, do not let you do it. So it will never work on the platform.

The issue of browsers (and other similar user agents) not trusting self-signed certificates is going to be a big problem in the Internet of Things (IoT). For example, what is going to happen when you connect to your thermostat or refrigerator to program it? The answer is, nothing good as far as the user experience is concerned.

The W3C’s WebAppSec Working Group is starting to look at the issue. See, for example, Proposal: Marking HTTP As Non-Secure.


How to create a self-signed certificate with OpenSSL

The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request). They differ from other answers in one respect: the DNS names used for the self signed certificate are in the Subject Alternate Name (SAN), and not the Common Name (CN).

The DNS names are placed in the SAN through the configuration file with the line subjectAltName = @alternate_names (there’s no way to do it through the command line). Then there’s an alternate_names section in the configuration file (you should tune this to suit your taste):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# IP.1        = 127.0.0.1
# IP.2        = ::1

It’s important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can’t avoid using the Subject Alternate Name.

Про сертификаты:  Как найти файл эцп на компьютере

If you don’t do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.

Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That’s one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.


Create a self signed certificate (notice the addition of -x509 option):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes 
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Create a signing request (notice the lack of -x509 option):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes 
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

Print a self-signed certificate:

openssl x509 -in example-com.cert.pem -text -noout

Print a signing request:

openssl req -in example-com.req.pem -text -noout

Configuration file (passed via -config option)

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

You may need to do the following for Chrome. Otherwise Chrome may complain a Common Name is invalid (ERR_CERT_COMMON_NAME_INVALID). I’m not sure what the relationship is between an IP address in the SAN and a CN in this instance.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

There are other rules concerning the handling of DNS names in X.509/PKIX certificates. Refer to these documents for the rules:

RFC 6797 and RFC 7469 are listed, because they are more restrictive than the other RFCs and CA/B documents. RFCs 6797 and 7469 do not allow an IP address, either.

Tls и веб-сертификаты

Всем привет!

А мы вот запустили тихой сапой один из самых необычных для нас курсов — «Цифровая подпись в информационной безопасности». Несмотря на всё мы вроде справились и людей привлекли, посмотрим, что получится. А сегодня мы разберём оставшийся интересный материал и посмотрим вкратце, как работает TLS, а также в чем разница между недоверенным и доверенным веб-сертификатами.

Перевод — dzone.com/articles/a-look-at-tls-transport-layer-security
Автор — Arun Pandey

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

Почти во всех протоколах связи есть три основных части: шифрование данных, аутентификация и целостность данных.

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

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

Краткий обзор Криптосистемы с Открытым Ключом и Симметричных Криптосистем

Криптосистема с открытым ключом, являющаяся разновидностью Асимметричного Шифрования, использует открытый-закрытый ключ. Так открытый ключ B используется для шифрования данных A (B поделился открытым ключом с A), а после получения зашифрованных данных B расшифровывает их, используя собственный закрытый ключ.

В Симметричных Криптосистемах используется один и тот же ключ и для расшифровки, и для шифрования, поэтому секретный ключ у A и B будет один и тот же. И это является большим недостатком.

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

Доверенные vs. Недоверенные Сертификаты

Цифровые сертификаты бывают двух категорий. Доверенные сертификаты подписываются Центром Сертификации (Certificate Authority, кратко — CA), в то время как недоверенные сертификаты — самоподписанные.

Доверенные Сертификаты

Доверенные сертификаты находятся в веб-браузере и подписываются CA. Это необходимо для обеспечения наивысшего уровня надежности. Предположим, сайт “xyz.com” хочет получить доверенный цифровой сертификат от известного сертификационного центра “Comodo”.
Шаги будут следующими:

Недоверенные Сертификаты

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

Как работает замена сертификата TLS

THE END

Как обычно ждём вопросы и комментарии.

Заказ бесплатного ssl–сертификата


Откройте

бесплатного сертификата SSL. Заполните информацию о вас (данные должны быть реальными, это очень важно).

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

Введите код и нажмите «Continue»

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

После этого будет сгенерирован сертификат для доступа к сертифицирующему центру StartCom. Сохраните его в безопасном месте и установите в систему, выполнив по нему двойной клик мышью и нажав «Install».

Про сертификаты:  Как исправить: есть проблема с сертификатом безопасности этого сайта - Учебные пособия по Windows

Теперь у вас есть доступ к сертифицирующему центру. На следующем шаге введите имя домена, для которого хотите получить сертификат.

Для подтверждения домена необходимо создать на нем один из трех адресов:

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

или воспользоваться

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

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

Рекомендуется пропустить этот шаг и сгенерировать CSR на вашем облачном VPS. Так секретный ключ не окажется у StartCom.Для генерации CSR подключитесь к виртуальному серверу по SSH(подробнее в следующем разделе) и выполните команду:

openssl req -new -newkey rsa:4096 -nodes -keyout /etc/ssl/private.key -out /etc/ssl/domain.csr

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

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

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

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

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

openssl genrsa -out rootCA.key 2048

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

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

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

страну

,

город

,

компанию

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

rootCA.key

и

rootCA.pem

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

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

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

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

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

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

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

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

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

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

страна

,

город

,

компания

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

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

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

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

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

v3.ext

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

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

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

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

v3.ext

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

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

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

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

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

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

# remove temp file
rm -f device.crt;

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

./create_certificate_for_domain.sh mysite.localhost

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

mysite.localhost.crt

и

device.key

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

nginx ssl

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

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

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

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

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

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

Openssl, проверка SSL-сертификатов через терминал | Укрнеймс.БЛОГ

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

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

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

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

Настройка apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

root@shpc:/mnt# cd/etc/apache2/

Создаём каталог для хранения сертификатов:

root@shpc:/etc/apache2# mkdir ssl

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

a2enmod headers

Перезапускаем веб-сервер:

root@shpc:/etc/apache2# systemctl restart apache2

Аналогично нужно включить поддержку заголовков: 

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

root@shpc:/mnt# cd /etc/apache2/conf-available
root@shpc:/etc/apache2/conf-available# nano ssl-params.conf

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

root@shpc:/etc/apache2/conf-available# a2enconf ssl-params

Теперь переходим в каталог /etc/apache2/sites-available:

root@shpc:/etc/apache2/conf-available# cd/etc/apache2/sites-available

И делаем на всякий случай резервные копии всех хранящихся там файлов:

root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak
root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/
root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt
root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/ca.cer

Теперь перезагружаем веб-сервер:

root@shpc:/etc/apache2# a2ensite default-ssl
root@shpc:/etc/apache2/sites-available# service apache2 restart

Проверяем доступность сайта:

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl-certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der

У полученного файла не забываем сменить атрибуты на 555:

root@shpc:/opt/simple_CA# chmod555 serve-and-ca-chain.p7c 

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

Про сертификаты:  Как получить и поставить электронную подпись — Редакция от 01.06.2021 — Контур.Норматив

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

Сейчас время настроить аутентификацию для клиентов. 

Разновидности ssl-сертификатов

SSL-сертификаты в основном делятся по двум категориям:

  1. Центры сертификации, которые их производят.
  2. Типы самих продуктов.

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

CSR (Certificate Signing Request) — заявка на установку сертификата.

Разбирая первую категорию хочется отметить, что существует около 10 известных центров сертификации, занимающихся разработкой данного продукта. Давайте заострим внимание на двух самых популярных среди них — Sectigo и Let’s Encrypt.

Let’s Encrypt известен тем, что у них есть возможность бесплатной установки сертификатов на 3 месяца. Однако, в отличие от многих других центров сертификации, они не несут материальной ответственности за взлом зашифрованной транзакции и потери переводимых денег.

Sectigo производит несколько типов платных SSL. Давайте разберем какие типы сертификатов бывает на примере тех, которые выпускает Sectigo:

  • SectigoPositiveSSL — базовый и дешевый тип сертификата. Именно поэтому он один из самых востребованных среди остальных. К тому же его не трудно зарегистрировать в плане документации — вам необходимо только подтвердить то, что вы являетесь владельцем вашего доменного имени. Процедура оформления длится не долго (от одного часа до четырех).
  • SectigoPostitiveWildcardSSL — отличительная черта данного сертификата в том, что помимо домена он распространяется на все поддомены указанного адреса (в случае необходимости). Это намного экономнее в случае, если у вас несколько поддоменов и вы собираетесь устанавливать персональный SSL на каждый из них.
  • Sectigo EV SSL — сертификат с повышенным уровнем безопасности, поскольку у него происходит более усиленная проверка. Его характерная особенность заключается в том, что во время обмена информацией, и предоставления зашифрованного ключа, помимо самой проверки требуется личное подтверждение от владельца сайта или организации. Как правило на его выпуск уходит несколько дней. Именно такой тип SSL находится на ресурсах, где указанно наименование организации перед адресом сайта.

Создание сертификатов с помощью программы openssl

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

# mkdir /root/ca

# cd /root/ca

# mkdir certs crl newcerts private

# chmod 700 private

# touch index.txt

2. Сгенерируем приватный ключ.

# openssl genrsa -out /root/ca/private/ca_key.pem 2048

3. Создадим сертификат CA для этого приватного ключа

# openssl req -new -x509 -days 3650 -key /root/ca/private/ca_key.pem -out /root/ca/certs/ca.crt

Выводкоманды

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]:NSO

Locality Name (eg, city) []:Novosibirsk

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kraftec

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:www.kraftec.net

Email Address []:dit@kraftec.net

Для создания сертификата SSL для Captive портала и Веб-консоли необходимо создать файл конфигурации

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

# touch /root/ca/openssl.cnf

Добавим в данный файл следующие блоки

##########################################################################

[ ca ]

default_ca = CA_default

[ CA_default ]

dir = /root/ca

certs = $dir/certs

crl_dir = $dir/crl

database = $dir/index.txt

new_certs_dir = $dir/newcerts

certificate = $certs/ca.crt

private_key = $dir/private/ca_key.pem

serial = $dir/serial

crlnumber = $dir/crlnumber

crl = $dir/crl/crl.pem

RANDFILE = $dir/private/.rand

x509_extensions = usr_cert

name_opt = ca_default

cert_opt = ca_default

crl_extensions = crl_ext

default_days = 365

default_crl_days= 30

default_md = sha256

preserve = no

policy = policy_match

[ policy_match ]

countryName = match

stateOrProvinceName = match

organizationName = match

organizationalUnitName = optional

commonName = supplied

emailAddress = optional

[ req ]

default_bits = 2048

distinguished_name = req_distinguished_name

x509_extensions = v3_ca

string_mask = utf8only

[ req_distinguished_name ]

countryName = Country Name (2 letter code)

countryName_default = RU

countryName_min = 2

countryName_max = 2

stateOrProvinceName = State or Province Name (full name)

stateOrProvinceName_default = NSO

localityName = Locality Name (eg, city)

localityName_default = Novosibirsk

0.organizationName = Organization Name (eg, company)

0.organizationName_default = Kraftec

organizationalUnitName = Organizational Unit Name (eg, section)

#organizationalUnitName_default =

commonName = Common Name (e.g. server FQDN or YOUR name)

commonName_max = 64

emailAddress = Email Address

emailAddress_max = 64

[ usr_cert ]

basicConstraints=CA:FALSE

nsCertType = server

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer

subjectAltName=DNS:auth.kraftec.net, DNS:logout.kraftec.net, DNS:block.kraftec.net, DNS:ftpclient.kraftec.net, DNS:sslvpn.kraftec.net

[ v3_ca ]

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

basicConstraints = critical,CA:true

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ crl_ext ]

authorityKeyIdentifier=keyid:always

##########################################################################

Сгенерируем ключ для SSL сертификата Captive портала

# openssl genrsa -out /root/ca/private/Captiv_key.pem 2048

Сгенерируем ключ для SSL сертификата Веб-консоли

# openssl genrsa -out /root/ca/private/Web_key.pem 2048

Сгенерируем запрос на SSL сертификат Captive портала

# openssl req -new -key /root/ca/private/Captiv_key.pem -config /root/ca/openssl.cnf -out /root/ca/Captive.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) [NSO]:

Locality Name (eg, city) [Novosibirsk]:

Organization Name (eg, company) [Kraftec]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:auth.kraftec.net

Email Address []:dit@kraftec.net

Подпишем полученный запрос с помощью сертификата УЦ.

# openssl x509 -req -days 365 -CA /root/ca/certs/ca.crt -CAkey /root/ca/private/ca_key.pem -extfile /root/ca/openssl.cnf -extensions usr_cert -in Captive.csr -out Captive.crt

Вывод команды

Signature ok

subject=/C=RU/ST=NSO/L=Novosibirsk/O=Kraftec/CN=auth.kraftec.net/emailAddress=dit@kraftec.net

Getting CA Private Key

Сгенерируем запрос на SSL сертификат Веб-консоли

Предварительно исправим конфигурационный файл в расширении usr_cert изменим параметр на subjectAltName=DNS:utm.kraftec.net

# openssl req -new -key /root/ca/private/Web_key.pem -config /root/ca/openssl.cnf -out /root/ca/Web.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) [NSO]:

Locality Name (eg, city) [Novosibirsk]:

Organization Name (eg, company) [Kraftec]:

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:utm.kraftec.net

Email Address []:dit@kraftec.net

Подпишем полученные запросы с помощью сертификата УЦ.

# openssl x509 -req -days 365 -CA /root/ca/certs/ca.crt -CAkey /root/ca/private/ca_key.pem -extfile /root/ca/openssl.cnf -extensions usr_cert -in Web.csr -out Web.crt

Вывод команды

Signature ok

subject=/C=RU/ST=NSO/L=Novosibirsk/O=Kraftec/CN=utm.kraftec.net/emailAddress=dit@kraftec.net

Getting CA Private Key

Импортируем данные сертификаты и приватные ключи в UserGate в раздел сертификаты.

Сертификату ca.crt назначим роль SSL дешифрование

Сертификату Captive.crt назначим роль SSL captive-портала

Сертификату Web.crt назначим роль SSL веб-консоли

На компьютеры пользователей установим сертификат ca.crt в хранилище Доверенные корневые центры сертификации.

Оцените статью
Мой сертификат
Добавить комментарий