Введение во взаимную аутентификацию сервисов на java c tls/ssl / хабр

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это ):

cert.pem — это сертификат SSL/TLS;
key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям . И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

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

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify и -Verify . Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

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

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

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

Обновление сертификатов почтового сервера

В Centos 8 certbot почему-то не добавил себя в планировщики. Ни в cron, ни в systemd timers. Но нам мало обновить сертификаты, нужно еще перезапустить службы, которые его используют. Для этого идем в конфиг letsencrypt для каждого домена и добавляем в самый конец параметр.

post_hook = systemctl reload postfix dovecot httpd

Сделать это нужно в конфигурационных файлах в директории /etc/letsencrypt/renewal/. Там для каждого домена будет свой конфиг. После этого можете прогнать тест обновления, чтобы убедиться в том, что ошибок нет.

# certbot renew --dry-run

Все в порядке. Можно добавлять задание в /etc/crontab, или в любой другой конфиг, как вы обычно делаете. Я больше люблю все задачи держать в одном системном конфиге crontab.

1 1 * * * root /usr/bin/certbot renew

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

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

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

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

С помощью оснастки MMC найдите сертификат X.509, который используется для проверки подлинности клиента. Дополнительные сведения см. в разделе Практическое руководство. Просмотр сертификатов с помощью оснастки MMC.
Получите доступ к отпечатку сертификата. Дополнительные сведения см. в статье Практическое руководство. Извлечение отпечатка сертификата.
Скопируйте отпечаток сертификата в текстовый редактор, например «Блокнот».
Удалите все пробелы между шестнадцатеричными символами. Эту задачу можно выполнить, в том числе, с помощью функции поиска и замены текстового редактора, заменив каждый пробел символом null.

Установить Certbot

В этом руководстве предполагается, что вы работаете на компьютере, на котором Certbot установлены. Certbot — это бесплатный инструмент с открытым исходным кодом, разработанный Electronic Frontier Foundation (EFF), который вы можете использовать для запроса или отзыва SSL /TLS сертификаты от SSL.com по протоколу ACME. Certbot можно запустить на различных платформах, включая Linux, macOS и Windows.

Если у вас есть Snapd установлен, вы можете использовать эту команду для установки:
```
sudo snap install --classic certbot
```
If не в твоем , вам также потребуется добавить его или выполнить такую команду:
```
sudo ln -s / оснастка / bin / certbot / usr / bin / certbot
```

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

Повысьте безопасность своего сайта с помощью SSL / TLS сертификата

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

Использование сертификата HTTPS также позволяет улучшить ранжирование сайта в поисковых системах.

Ниже приведен список сертификационных центров (поставщиков SSL), которые помогут вам обзавестись сертификатом совершенно бесплатно.

Расшифровка используемых аббревиатур.

SSL — Защищенный сокет;
TLS — Безопасность транспортного уровня;
CDN — Сеть доставки контента;
DV — Проверенный домен;
ACME — Автоматизированная среда управления сертификатами.

Let’s Encrypt

Это совместный с Linux Foundation проект, который спонсируется Mozilla, Akamai, SiteGround, Cisco, и т. д. Он предоставляет бесплатный HTTPS сертификат.

Сервис является автоматизированным. Это означает, что вам не нужно тратить время на создание CSR, чтобы заверить сертификат. Все это происходит на серверах в автоматическом режиме:

Comodo

Comodo предлагает бесплатный SSL-сертификат на 90 дней. Это подходит для тех случаев, когда вы хотите проверить, какова будет разница при использовании сертификата и без него. Или для какого-то краткосрочного проекта.

Вы можете за считанные минуты получите бесплатный SSL-сертификат, защищенный надежным алгоритмом шифрования. Все основные браузеры распознают сертификаты Comodo:

Cloud Flare

Компания, специализирующаяся на кибербезопасности и технологиях CDN. Они помогают сделать ваш сайт более быстрым и безопасным. Услугами Cloud Flare пользуются многие популярные сайты, включая Reddit, yelp, Mozilla, StackOverflow и т. д.:

Недавно Cloud Flare анонсировала универсальный сертификат для сайтов HTTPS для всех пользователей. Если вы используете Cloud Flare и еще не активировали SSL, это можно сделать быстро:

Войдите в аккаунт Cloud Flare;
Выберите сайт, на котором вы хотите включить SSL;
Нажмите иконку Crypto;
Убедитесь, что у вас задан параметр “Flexible”, а статус отображается как “ACTIVE CERTIFICATE”:

Внесение всех изменений займет несколько секунд.

StartCom

StartCom предоставляет бесплатный SSL-сертификат для личного использования. Чтобы получить его, необходимо подтвердить право собственности на домен:

Таким образом, можно бесплатно получить DV-сертификат класса 1! Он отлично подойдет для личного сайта / блога.

WoSign

WoSign является еще одним сервисом, предоставляющим сертификат безопасности HTTPS сроком на 2 года без какой-либо оплаты. Он поддерживает алгоритм SHA2. «WoSign CA Free SSL Certificate G2» является эмитентом сертификатов:

SSL For Free

ACME SSL For Free и Let’s Encrypt предоставляют услуги валидации домена для выдачи SSL-сертификата. Это полностью бесплатно, и SSL-сертификаты выдаются в течение нескольких минут:

Настройка Apache на использование клиентских сертификатов

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

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

Примеры работы с XCA

Создание ключа SSH

1. Для начала перейдите на вкладку «Закрытые ключи».
2. Нажмите на кнопку «Новый ключ».
3. В поле «Тип ключа» выберите RSA. В поле «Длина ключа» выберите 2048 bit. Имя ключу дайте на свое усмотрение.

Экспорт ключей

Для экспорта открытого ключа необходимо выполнить следующие действия:

1. Перейти на вкладку «Закрытые ключи»;
2. Выбрать нужный «Сертификат клиента»;
3. Нажать кнопку «Экспорт»;
4. В появившемся окне в поле «Формат сертификата» нужно выбрать Открытый ключ SSH2 (*.pub) и указать путь к файлу, затем нажать «ОК».

Для экспорта закрытого ключа необходимо выполнить следующие действия:

1. Перейти на вкладку «Закрытые ключи»;
2. Выбрать нужный закрытый ключ сервера;
3. Нажать кнопку «Экспорт»;
4. В появившемся окне в поле «Формат для экспорта» нужно выбрать Закрытый ключ PEM (*.pem), указать путь к файлу, затем нажать «ОК».

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

1. Перейти на вкладку «Закрытые ключи»;
2. Выбрать нужный закрытый ключ сервера;
3. Нажать кнопку «Экспорт»;
4. В появившемся окне в поле «Формат для экспорта» нужно выбрать Зашифрованный ключ PEM (*.pem), указать путь к файлу, затем нажать «ОК»;
5. В появившемся окне Certificate and Key management нужно ввести пароль, который будет требоваться для доступа к этому ключу.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@mycompany.com

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

        SSLEngine on

        SSLCertificateFile    /etc/ssl/certs/server.pem
        SSLCertificateKeyFile /etc/ssl/private/server.key

        # Эта директива добавляет файл, содержащий список
        # всех сертификатов, которыми подписан сертификат сервера
        #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch "MSIE " \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE " ssl-unclean-shutdown

</VirtualHost>
</IfModule>

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Привязка SSL-сертификата к номеру порта

в Windows Server 2003 или Windows XP используйте средство HttpCfg.exe в режиме «задать» в хранилище SSL (SSL), чтобы привязать сертификат к номеру порта. Это средство использует отпечаток для идентификации сертификата, как показано в следующем примере.
- Параметр -i имеет следующий синтаксис : и указывает средству установить сертификат на порт 8012 компьютера. Дополнительно, четыре нуля, предшествующие номеру, можно заменить на фактический IP-адрес компьютера.
- Параметр -h указывает отпечаток сертификата.
в Windows Vista используйте средство Netsh.exe, как показано в следующем примере.
- Параметр certhash указывает отпечаток сертификата.
- Параметр иппорт указывает IP-адрес и порт, а также функции, аналогичные параметру -i в описании средства Httpcfg.exe.
- Параметр AppID — это идентификатор GUID, который можно использовать для поиска приложения-владельца.

Обновление сертификата

Если планируется использовать сертификат SSL от Let’S Encrypt более 90 дней, его придется систематически обновлять. И делать это рекомендуется заранее, минимум за 30 дней до истечения срока действия. Иначе возникают риски временной неработоспособности протокола SSL, когда сайт перестает открываться по прежним ссылкам (браузеры предупреждают об ошибке).

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

$ certbot renew

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

$crontab -e

30 2 * * 1 /usr/bin/certbot renew >> /var/log/renew-ssl.log

В таком виде она каждый понедельник в 2:30 будет выполнять проверку актуальности всех SSL и записывать результат в файл с указанным названием.

Настройка SSL, TLS в NGINX

Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:

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

установить число рабочих процессов равным числу процессоров,
разрешить keep-alive соединения,
включить разделяемый кэш сессий,
выключить встроенный кэш сессий
и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Изменения я буду комментировать

# Создаём отдельный server для перенаправления с http на https
server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

# А это основной сервер с https
server {
  server_name example.com www.example.com;  # Копируем из верхнего сервера
  listen 1.2.3.4:443 ssl http2; #вместо 1.2.3.4 вставляете IP своего сервера. http2 включчает поддержку протокола http/2

  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # Сертификат
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # Ключ

  # Рекомендации по кешированию запросов
  keepalive_timeout   70; # 70 секунд держим соединение открытым
  keepalive_requests 150; # 150 запросов максимум на 1 соединение, после закрываем
  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  # А строки ниже - для усиления безопасности соединения
  ssl_prefer_server_ciphers on; # Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; # Типы шифров
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Разрешённые типы протоколов

... # Тут остальные правила NGINX

Сохранили, проверили, перезагрузили

nginx -t && service nginx reload

Продление сертификата (вручную)

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

sudo certbot Renew --force-Renewal Сохранение журнала отладки в /var/log/ssl-com/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Обработка /etc/ssl-com/renewal/DOMAIN.NAME - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Не удалось выбрать подходящий плагин: ручной плагин не работает; могут быть проблемы с вашей существующей конфигурацией. Ошибка была: PluginError ('Сценарий аутентификации должен быть предоставлен с --manual-auth-hook при неинтерактивном использовании подключаемого модуля вручную.',) Попытка обновить сертификат (DOMAIN.NAME) из / etc / ssl-com / обновление / DOMAIN.NAME.conf вызвало непредвиденную ошибку: ручной плагин не работает; могут быть проблемы с вашей существующей конфигурацией. Ошибка была: PluginError ('Сценарий аутентификации должен быть предоставлен с --manual-auth-hook при неинтерактивном использовании подключаемого модуля вручную.',). Пропуская. Все попытки продления не удались. Следующие сертификаты не могут быть обновлены: /etc/ssl-com/live/DOMAIN.NAME/fullchain.pem (сбой) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Все попытки обновления не удались. Следующие сертификаты не могут быть обновлены: /etc/ssl-com/live/DOMAIN.NAME/fullchain.pem (сбой) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 сбой при обновлении, 0 сбоев при синтаксическом анализе

Приватный ключ

Приватный ключ является самым важным элементом при выпуске сертификата.

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

Если приватный ключ потерян или повреждён, то работа web-сервера будет не возможна, т.к. не получится зашифровать / расшифровать передаваемый трафик. Так же при утере или повреждении приватного ключа мы не сможем сменить или перевыпустить сертификат, т.к. на основе приватного ключа генерируется CSR-запрос в центр сертификации.

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

openssl genrsa -out private.key 2048

Получаем сертификат от Let’s Encrypt

Итак, я считаю, что вы настроили почтовый сервер по предложенной выше ссылке. Значит, у вас установлен веб сервер Apache, а так же все в порядке с dns записями. Сертификатов мы получим сразу два. Для доменных имен:

mail.site.ru — имя почтового сервера, этот сертификат будут использовать postfix и apache
webmail.site.ru — домен для web интерфейса почты, будет использовать веб сервер

Для настройки получения сертификатов let’s encrypt и настройки apache, нам нужно будет установить несколько пакетов. Напоминаю, что речь идет про Centos 8. В других системах настройка будет аналогичной, только имена пакетов могут отличаться.

# dnf install certbot python3-certbot-apache mod_ssl

Пакеты эти живут в репозитории epel, так что если он еще не подключен, подключите.

# dnf install epel-release

Дальше нам нужно добавить 2 виртуальных домена в настройки apache. Для этого создаем 2 конфига в директории /etc/httpd/conf.d/.

1. mail.site.ru.conf

<VirtualHost *:443>
 ServerName mail.site.ru
 DocumentRoot /var/www/mail.site.ru/
 <Directory /var/www/mail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/mail.site.ru-error.log
 CustomLog /var/log/httpd/mail.site.ru-access.log combined
</VirtualHost>

<VirtualHost *:80>
 ServerName mail.site.ru
 DocumentRoot /var/www/mail.site.ru/
 <Directory /var/www/mail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/mail.site.ru-error.log
 CustomLog /var/log/httpd/mail.site.ru-access.log combined
</VirtualHost>

2. webmail.site.ru.conf

<VirtualHost *:443>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
</VirtualHost>

<VirtualHost *:80>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
</VirtualHost>

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

# apachectl -t
# apachectl reload

Если увидите ошибку:

AH00526: Syntax error on line 85 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty

Просто удалите конфиг /etc/httpd/conf.d/ssl.conf. Он нам не нужен.

Если нет ошибок, то можно запускать certbot и получать сертификаты. Делается это очень просто.

# certbot --apache

Если все прошло без ошибок, то вы увидите в директории /etc/letsencrypt/live две папки с сертификатами для каждого из доменов.

Так же certbot автоматически добавит в конфигурации виртуальных хостов apache несколько дополнительных параметров.

<VirtualHost *:443>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
 SSLCertificateFile /etc/letsencrypt/live/mail.site.ru/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/mail.site.ru/privkey.pem
 Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

<VirtualHost *:80>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
 RewriteEngine on
 RewriteCond %{SERVER_NAME} =mail.site.ru
 RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} 
</VirtualHost>

В этот виртуальный хост установите веб почту, если вам она нужна.

Как проверить сертификаты SSL/TLS

Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.

SeoLik

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

Проверяем наличие HTTPS соединения:

Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ».
В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков.

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

SSL Shopper

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

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

Wormly Web Server Tester

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

Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires».

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

Immuni Web

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

При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report».

SSL Checker

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

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

Спасибо за внимание!

Про установку SSL-сертификатов вы можете почитать тут и тут.

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

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

1. Создайте файл расширения x509 v3:

cat > v3.ext <<-EOFauthorityKeyIdentifier=keyid,issuerbasicConstraints=CA:FALSEkeyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEnciphermentsubjectAltName = @alt_names # Локальные хостингиDNS.1 = localhostDNS.2 = 127.0.0.1DNS.3 = ::1 # Перечислите доменные именаDNS.4 = local.devDNS.5 = my-app.devDNS.6 = local.some-app.devEOF

Следуя этому шаблону, можно добавить сколько угодно доменных имен.

Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.

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

openssl req -new -nodes -newkey rsa:4096 \  -keyout localhost.key -out localhost.csr \  -subj "/C=US/ST=State/L=City/O=Some-Organization-Name/CN=localhost"

Опционально: страну, штат, город и организацию можно изменять.

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

openssl x509 -req -sha512 -days 365 \-extfile v3.ext \-CA ca.crt -CAkey ca.key -CAcreateserial \-in localhost.csr \-out localhost.crt

Использование сертификата

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

Вот несколько примеров:

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

Откройте браузер и введите команду chrome://flags/#enable-quic;
В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Цифровые сертификаты[править]

Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.

Способы получения SSL-сертификата:

Использовать самоподписанный сертификат
Использовать «пустой» сертификат

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

Файлы сертификатов X.509

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

*.cer – сертификат, сохраненный в стандарте CER. Может включать сертификат, секретный ключ, путь сертификации.
*.der – сертификат, сохраненный в стандарте DER. Может включать сертификат, секретный ключ, путь сертификации. Формат который понимает Windows.
*.crt – файл сертификата в формате CER, DER или Netscape.
*.pem – сертификат в кодировке Base64. Может также включать полный путь удостоверения сертификата и секретный ключ.
*.p8 – файл, содержащий секретный ключ, защищенный по стандарту PKCS#8.
*.p12 (в Windows используется расширение *.pfx) – файл сертификата, защищенный по стандарту PKCS#12. Может включать сертификат, секретный ключ, путь сертификации.