Как создать самозаверяющий сертификат для доменного имени для разработки?

Бесплатные сертификаты

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

Самоподписанный (самоизданный, самозаверенный, self-signed) сертификат — тот, который вы сами создали для своего домена или IP-адреса. Многим владельцам сайтов может показаться, что это идеальный вариант:

• Бесплатно.
• Доступно. Такой SSL-сертификат может создать любой владелец домена.
• Без обращения к поставщикам услуг. Не нужно ждать ответа от центра сертификации.
• Быстро. Но только если вы знаете, что делать и как пользоваться специальными программами или библиотеками. Например, для Windows можно воспользоваться криптографическим хранилищем OpenSSL или консолью PowerShell. 
• Можно создать сколько угодно сертификатов.

Вам уже кажется, что выбор сделан и читать дальше нет смысла? Всё не совсем так.

Минусы

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

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

Бесплатные доверенные сертификаты

Такие SSL-сертификаты можно оформить довольно быстро. Часто ими пользуются стартапы, чтобы понять, что вообще такое SSL и как это работает. Бывают только одного вида — DV SSL (Domain Validation). Это сертификаты, удостоверяющие доменное имя. 

Плюсы

• Быстро. Такой сертификат могут выдать вам уже через несколько минут. Всё потому, что тип такого сертификата — DV (Domain Validation) SSL и для его оформления нужно только подтверждение владения доменом, как и у платных DV.
• Просто получать и устанавливать.
• Отлично подойдёт для теста с возможностью сэкономить в первые несколько месяцев.
• Известные компании-поставщики. Те же Let’s Encrypt на рынке с 2012 года и поддерживаются Google, Facebook и другими крупными корпорациями.

Минусы

• Небольшой срок действия. Например, сертификаты Let`s Encrypt необходимо перевыпускать каждые 3 месяца.
• Сложности с продлением. Хостеры автоматически продлевают некоторые бесплатные сертификаты. Но здесь бывают проблемы. Перед выпуском сертификационный центр обращается к сайту за специальным файлом. Иногда он в системе не обнаруживается: не было места на диске и файл не записался, во время проверки почему-то закрылся доступ к сайту и пр. Итог один — сертификат не обновляется, а вы даже не узнаете об этом, если не решите вдруг проверить срок действия вручную.
• Отсутствие поддержки. Для корректной работы SSL-сертификата важна грамотная полноценная поддержка (по телефону, по email, в чатах). Она недоступна для бесплатных SSL. На официальных сайтах удостоверяющих центров, как правило, размещены ответы на часто задаваемые вопросы, которые в основном описывают общие случаи и могут быть бесполезны для решения конкретной проблемы. Также есть неофициальная информация на тематических форумах, но среди неё ещё надо найти нужную.
• Есть вероятность не заметить, что сертификат не работает. Как мы писали выше, посмотреть сроки действия сертификата можно вручную. Есть и другой способ: проверять даты с помощью специального скрипта, который не так просто создать. Поддержки нет. Если не проверять сроки, можно пропустить время продления, и сертификаты будут аннулированы. В безопасности сайта появятся дыры, посетители, увидев уведомление о ненадёжности сайта, станут покидать сайт и трафик снизится.

В 2017 году кредитное бюро Equifax сообщило о масштабном взломе: хакеры украли данные 143 млн человек — почти половины населения США. Это произошло отчасти из-за истечения срока действия сертификата, который был неактивным в течение 19 месяцев.

Получаем сертификат от 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>

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

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

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

можно выполнить следующую Windows PowerShell команду: (или ). Кроме того, можно проверить текущие сертификаты в консоли MMC: Service- > Certificates.

Сертификат, для которого установлено значение «The- PRIMARY », равно true , — это сертификат, который AD FS в настоящее время используется.

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

Чтобы обеспечить непрерывность обслуживания, все партнеры Федерации (представленные в ферме AD FS с помощью отношений доверия проверяющей стороны или поставщика утверждений) должны использовать новые сертификаты подписи маркера и расшифровки маркеров до истечения этого срока действия. Рекомендуем начать планирование для этого процесса не менее 60 дней заранее.

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

Обе приведенные выше команды создают сертификат для доменов и . Версия Win10 дополнительно имеет срок службы 15 лет и читаемое отображаемое имя «Dev Cert * .dev.local, dev.local, localhost».

Обновление: если вы укажете несколько записей имени хоста в параметре (как показано выше), первая из этих записей станет темой домена (AKA Common Name). Полный список всех записей имен хостов будет храниться в поле Subject Alternative Name (SAN) сертификата. (Спасибо @BenSewards за указание на это.)

После создания сертификат будет немедленно доступен в любых HTTPS-привязках IIS (инструкции ниже).

Доверяйте сертификату

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

Откройте mmc.exe, Файл → Добавить / удалить оснастку → выберите «Сертификаты» в левом столбце → Добавить → выберите «Учетная запись компьютера» → Далее → «Локальный компьютер …» → Готово → ОК

В левом столбце выберите «Сертификаты (локальный компьютер) / Личный / Сертификаты». Найдите только что созданный сертификат (в Win 10 может помочь столбец «Понятное имя»). Выберите этот сертификат и нажмите Ctrl-C, чтобы скопировать его в буфер обмена.

В левом столбце выберите «Сертификаты (локальный компьютер) / Надежные корневые центры сертификации / Сертификаты». Нажмите Ctrl-V, чтобы вставить сертификат в это хранилище. Сертификат должен появиться в списке доверенных корневых центров и теперь считается заслуживающим доверия.

Протестируйте сертификат

Для проверки ваших сертификатов Firefox – ваш лучший выбор. (Поверьте, я сам фанат Chrome, но в этом случае FF лучше.)

Вот причины:

• Firefox использует свой собственный кеш SSL, который очищается при повторной загрузке. Поэтому любые изменения в сертификатах ваших локальных веб-сайтов будут немедленно отражены в предупреждениях FF, в то время как другим браузерам может потребоваться перезапуск или ручная очистка кэша SSL Windows.
• Также FF дает вам несколько полезных советов для проверки действительности вашего сертификата: Нажмите “Дополнительно”, когда FF покажет предупреждение о сертификате. FF покажет вам короткий текстовый блок с одним или несколькими возможными предупреждениями в центральных строках текстового блока:

Это предупреждение верно! Как отмечалось выше, Firefox не использует хранилище сертификатов Windows и будет доверять этому сертификату, только если вы добавите для него исключение. Кнопка для этого находится прямо под предупреждением.

Это предупреждение показывает, что вы сделали что-то не так. Домен (подстановочный знак) вашего сертификата не соответствует домену вашего сайта. Проблема должна быть решена либо путем изменения домена вашего сайта (sub-), либо путем выдачи нового сертификата, который соответствует. Фактически, вы можете добавить исключение в FF, даже если сертификат не совпадает, но вы никогда не получите зеленый символ замка в Chrome с такой комбинацией.

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

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

По умолчанию срок действия самоподписанного сертификата Zimbra составляет 5 лет. Это значительно больше срока поддержки LTS-версий Zimbra OSE и, скорее всего, у администратора сервера не возникнет потребности в том, чтобы его обновлять.  Однако все же возникают ситуации, при которых у администратора возникает необходимость обновить самоподписанный сертификат. Сделать это также можно двумя способами: через консоль администратора, с помощью мастера установки сертификата, а также в командной строке.

В первом случае вам потребуется открыть Мастер установки сертификата и выбрать в нем раздел «Установить самозаверяющий сертификат». При нажатии кнопки далее откроется анкета для создания CSR. После ее заполнения вам будет предложено настроить срок действия сертификата. В отличие от выпускаемого при установке сертификата, срок действия этого по умолчанию составляет всего 1 год. После того как укажете желаемый срок действия сертификата, нажмите на кнопку «Установить», чтобы сертификат установился. 

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

• /opt/zimbra/bin/zmcertmgr createcrt -new -days 365 (365 — количество дней, которые будет действовать новый сертификат)

• /opt/zimbra/bin/zmcertmgr deploycrt self

• /opt/zimbra/bin/zmcertmgr viewdeployedcrt

• su — zimbra -c zmcontrol restart

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

sudo sucd /opt/zimbra/ssl/zimbra/caopenssl x509 -in ca.pem -outform DER -out ~/zimbra.cer

После этого скопируйте полученный сертификат на целевые машины и дважды кликните по нему мышкой. В открывшемся окне нужно выбрать «Установить сертификат» и импортировать его в Мастере импорта сертификатов. Единственный нюанс при его установке, что при выборе хранилища для сертификата необходимо поместить его в хранилище «Доверенные корневые центры сертификации». Кроме того, можно установить данный сертификат через групповые политики. После того, как данный сертификат будет указан в качестве доверенного, браузер и другие приложения не будут сообщать об ошибках при подключении к серверу.

По всем вопросам, связанными c Zextras Suite и Team Pro вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте [email protected].

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

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

Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):

openssl genpkey -algorithm RSA -out rootCA.key

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

Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу «hello» (-pass pass:hello):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello

Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.

Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):

man enc

Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096

Создание CA -сертификата

Способ распространения CA -сертификата зависит главным образом от того, в каких приложениях он будет использоваться и каким будет их окружение. GUI — приложения обычно обращаются к корневому хранилищу сертификатов, предоставляемому операционной системой, которая обеспечивает централизованное управление всеми сертификатами. На использующих Как пользоваться OpenSSL серверах, не имеющих другого пользовательского интерфейса, кроме командной строки, нет единого централизованного корневого хранилища. Приложения командной строки (например, демон smtpd) могут использовать собственные хранилища, расположение которых должно быть указано в их индивидуальных настройках.

Если вы решили самостоятельно выпускать сертификаты, то первым делом вам нужно создать сертификат вашего собственного центра сертификации. Для этого используем программу CA.pl входящую в поставку Как пользоваться OpenSSL, предварительно отредактируем конфигурационный файл openssl.cnf.

# cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.orig
# nano openssl.cnf
...


dir             = ./demoCA
# cacert.pem- Это открытый ключ центра сертификации. Он должен находиться в корневых хранилищах ваших хостов,
# чтобы они могли проверить родпись в открытом сертификате (например, Postfix).
certificate     = $dir/cacert.pem
# cakey.pem - это секретный ключ центра сертификации. Он должен быть хорошо защищен,
# доступ к нему на чтение и запись должен иметь только администратор центра сертификации.
private_key     = $dir/private/cakey.pem
# Время жизни сертификата (по умолчанию 1 год)
default_days    = 1095

# длина RSA ключа (по умолчанию 1024 bit). Длину ключа можете настроить по своему усмотрению.
default_bits            = 1024

countryName_default             = UA
0.organizationName_default      = Example INC
stateOrProvinceName_default     = Example
organizationalUnitName_default  = Example

# В подавляющем большинстве случае должно соответствовать полному доменному имени хоста.
# Common Name (eg, your name or your server's hostname) []:OpenVPN-CA

commonName                      = Common Name (eg, YOUR name)
commonName_default              = mail.example.com
...
# /usr/lib/ssl/misc/CA.pl -newca

SSL-сертификат, центр сертификации.

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

Центр сертификации или Удостоверяющий центр (англ. Certification authority, CA) — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится центрами сертификации в виде цифровых сертификатов, имеющих следующую структуру:

• Серийный номер сертификата;
• Объектный идентификатор алгоритма электронной подписи;
• Имя удостоверяющего центра;
• Срок годности;
• Имя владельца сертификата (имя пользователя, которому принадлежит сертификат);
• Открытые ключи владельца сертификата (ключей может быть несколько);

Сертификат также содержит полностью определенное имя домена (FQDN RFC 821) в строке Common Name. Одна из возможных атак — подмена DNS — будет обнаружена до отправки данных.

Виды SSL- сертификатов

Выделяют различные виды SSL- сертификатов в зависимости от типа проверки:

• Сертификаты с проверкой домена – подтверждают подлинность доменного имени. Не содержат информации о компании.
• Сертификаты с проверкой компании – содержат информацию не только о домене, но и о компании, которой выдан сертификат. Пользуются большим доверием у пользователей.
• Сертификаты на домен и поддомены (Wildcard SSL) – обеспечивают защиту неограниченного количества субдоменов одним сертификатом. Сертификат выдается на определенное доменное имя и при этом защищает все поддомены. Данные сертификаты могут быть как с проверкой домена, так и с проверкой организации.
• Сертификаты с расширенной проверкой организации (Extended Validation SSL (EV SSL)) – обеспечивают наивысшее доверие клиентов. Когда пользователь находится на сайте с EV SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.

Wildcard SSL — сертификаты — это сертификаты, защищающие не только основной домен(ваш_домен.ру), но и поддомены(www.ваш_домен.ру, ssl.ваш_домен.ру, secure.ваш_домен.ру и т.д.). Может использоваться на веб-сервере и почтовом сервере. При генерации запроса на Wildcard сертификат в качестве Common Name (CN) используйте «*.domain.com», где domain.com — это ваше доменное имя.

Разворачиваем собственный ЦС

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.

Допустим, нам надо настроить веб-сервер так, чтобы соединение к нему шло по протоколу HTTPS и сервер заодно проверял клиента по сертификату. Пользователь у нас один, веб-сервер на Apache 2. Схема нашего центра сертификации будет такой:

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом: 

Далее создадим сертификат для CA:

root@shpc:/opt/simple_CA# openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

На выходе получим два файла: ключ и сертификат. 

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

root@shpc:/opt/simple_CA# openssl x509 -text -noout -in ca.cer

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

root@shpc:/opt/simple_CA# openssl genrsa -out server.key 4096

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

root@shpc:/opt/simple_CA# openssl req -new -key server.key -out server.req -sha256

Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

root@shpc:/opt/simple_CA# openssl x509 -req -in server.req -CA ca.cer -CAkey ca.key -set_serial 100 -extensions server -days 1460 -outform PEM -out server.cer -sha256 

Должно получиться 5 файлов.

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Шаг 5 — Тестирование шифрования

Теперь мы готовы протестировать наш сервер SSL.

Откройте браузер и введите и доменное имя или IP-адрес вашего сервера в адресную панель:

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

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

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

Если вы настроили Apache для перенаправления HTTP на HTTPS, вы можете проверить правильность перенаправления функций:

Если при этом появляется такой же значок, перенаправление работает правильно.