Настройка Apache + SSL для работы сайта по HTTPS

Инструкция написана для операционных систем на базе UNIX.

Шаг 1. Создание сертификата

Для боевого сервера, сертификат должен быть получен от доверенного центра сертификации — либо локального для компании, либо коммерческого. Или получен бесплатно от Let’s Ecnrypt.

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

а) на Red Hat / CentOS:

б) на Debian / Ubuntu:

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

mkdir ssl ; cd ssl

И генерируем сертификат:

openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test»

* в данном примере созданы открытый и закрытый ключи на 4 года (1461 день); значения параметра subj могут быть любыми в рамках тестирования.

Шаг 2. Установка модуля SSL для Apache

Прежде, чем устанавливать модуль, выполняем команду:

apachectl -M | grep ssl

Если видим строчку, на подобие:

Спускаемся к шагу 3 данной инструкции.

Иначе, устанавливаем httpd ssl_module.

yum install mod_ssl

б) Для Ubuntu/Debian:

Открываем файл конфигурации apache:

* подразумевается, что используется apache 2.4.

Находим и снимаем комментарии со следующих строчек:

.
LoadModule ssl_module libexec/apache24/mod_ssl.so
.
Include etc/apache24/extra/httpd-ssl.conf
.

И ставим комментарии в следующих строках:

#
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#

Чтобы настройки применились, необходимо перезапустить веб-сервер одной из команд:

systemctl restart httpd

systemctl restart apache2

service apache2 restart

* первая, как правило, используется в системах на базе RPM, вторая — DEB, третья — BSD.

Шаг 3. Настройка Apache

Выходим из папки ssl:

Открываем файл с настройкой виртуальный доменов.

* где site.conf — конфигурационный файл для конкретного сайта

В открытый файл добавляем следующее:

ServerName site.ru
DocumentRoot /var/www/apache/data
SSLEngine on
SSLCertificateFile ssl/cert.pem
SSLCertificateKeyFile ssl/cert.key

* где ServerName — домен сайта; DocumentRoot — расположение файлов сайта в системе; SSLCertificateFile и SSLCertificateKeyFile — пути до файлов ключей, которые были сгенерированы на шаге 1.

Проверяем корректность настроек в Apache:

Перечитываем конфигурацию apache:

Шаг 4. Проверка работоспособности

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

Если сайт не заработал, пробуем найти причину по log-файлу. Как правило, он находится в каталоге /var/log/apache или /var/log/httpd.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

ServerName site.ru
RewriteEngine On
RewriteCond % off
RewriteRule (.*) https://%% [R=301,L]

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать.

В файле .htaccess

Установка модуля rewrite

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

LoadModule rewrite_module modules/mod_rewrite.so

* если ее нет, добавляем; если она закомментирована, снимаем комментарий.

systemctl restart httpd

systemctl restart apache2

Apache + NGINX

При использовании веб-сервера на базе и Apache и NGINX, как правило, наружу смотрит последний. В таком случае, именно он будет отвечать на http-запросы, и в таком случае нужно настраивать SSL на NGINX.

Как настроить Apache для работы по HTTPS (SSL)

Apache SSL: переход Apache на HTTPS

Нужен ли HTTPS?

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

Веб-сервер Apache поддерживает работу HTTPS. Для настройки HTTPS на Apache нужен SSL сертификат. Точнее говоря, «SSL сертификат» включает в себя приватный ключ и публичный ключ (сертификат). Также вместе с SSL ключами дополнительно могут присылаться сертификаты центра сертификации, корневой сертификат.

Сертификаты SSL

SSL сертификаты можно разделить на два вида: валидные и самоподписанные.

Сертификат SSL можно сгенерировать у себя на компьютере. Причём можно сгенерировать для любого доменного имени. Но к таким сертификатам у веб-браузеров нет доверия. Поэтому если открыть сайт, защищённый таким сертификатом, то веб-браузер напишет ошибку, что сертификат получен из ненадёжного источника и либо запретит открывать этот сайт, либо предложит перейти на сайт на ваш страх и риск. Это так называемые «самоподписанные сертификаты». Чтобы браузер не выдавал ошибку о ненадёжного сертификате, его нужно добавить в список доверенных. Такие сертификаты подойдут для тестирования веб-сервера и обучению настройки веб-сервера для работы с SSL и HTTPS. Ещё такой сертификат можно использовать на сайте, к которому имеет доступ ограниченный круг лиц (несколько человек) — например, для сайтов в локальной сети. В этом случае они все могут добавить сертификат в доверенные.

Для реального сайта такой сертификат не подойдёт.

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

1) получить тестовый сертификат на 3 месяца (затем его можно продлить)

2) купить сертификат — в этом случае он действует от года и более

Валидный сертификат отличается от самоподписанного тем, что сторонний сервис удостоверяет подлинность этого сертификата. Собственно, оплачивается именно эта услуга удостоверения, а не выдача сертификата.

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

Как сгенерировать SSL сертификат в Windows

У меня веб-сервер установлен в папку C:\Server\bin\Apache24, поэтому если у вас он в другой директории, то подправьте команды под свои условия.

Откройте командную строку Windows (Win+x, далее выберите «Windows PowerShell (администратор)»). В командной строке введите команды:

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

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

Двухбуквенное имя страны (двухбуквенный код)

Название штата или провинции/области (полное имя)

Название населённого пункта (например, города)

Подразделение организации (т.е. отдел)

Общее имя (например, FQDN сервера или ВАШЕ имя). Это самая важная часть — здесь нужно ввести доменное имя. Можете ввести localhost.

Теперь выполните команду:

В результате в каталоге C:\Server\bin\Apache24\bin\ должны появиться три новых файла:

Из них нам понадобятся только два:

Как в Windows для Apache подключить SSL сертификаты

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

Для настройки использования SSL на локальном веб-сервере Apache в Windows следуйте инструкции ниже (в моём случае веб-сервер установлен по этой инструкции, если у вас не так, то отредактируйте пути до файлов).

В каталоге C:\Server\ создайте новую папку certs и переместите туда файлы localhost.key и localhost.crt.

В директории C:\Server\bin\Apache24\conf\ откройте текстовым редактором файл httpd.conf. В самый низ добавьте туда строки:

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

• DocumentRoot — укажите путь до сайтов на сервере
• ServerName — укажите имя вашего хоста, если это не локалхост

Обратите внимание, что мы не просто поместили эти строки в конфигурационный файл, а заключили их в контейнер VirtualHost. Дело в том, что если этого не сделать, то директива SSLEngine on включит SSL для всего веб-сервера, и даже при попытке открыть сайты на 80 порту, эти подключения будут обрабатываться как HTTPS, что вызовет ошибку «Bad Request. Your browser sent a request that this server could not understand». По этой причине эти настройки помещены в контейнер виртуального хоста. Обратите внимание, что используется ключевое слово _default_ — то есть сюда будут собираться все запросы на 443 порт если они не предназначены для другого хоста, который также настроен. То есть при желании вы можете создать больше виртуальных хостов для работы с HTTPS, при этом вместо _default_ указывайте IP хоста или символ * (звёздочка).

После этого сохраните изменения, закройте файл и перезапустите веб-сервер.

Для проверки сделанных изменений, перейдите по адресу https://localhost/ (протокол HTTPS). Поскольку сертификат является самоподписанным, то появится такое сообщение:

К самоподписанным сертификатам нет доверия и эту ошибку нельзя убрать без добавления таких сертификатов в доверенные. Для перехода нажмите «Всё равно продолжить».

Как уже было сказано, валидные сертификаты нужно покупать, либо использовать тестовые. В чём подвох использования тестовых сертификатов? Формально, в какой-то момент их могут перестать выдавать, но, на самом деле, уже сейчас многие сайты годами живут с такими тестовыми сертификатами. На современных хостингах настроено автоматическое подключение и продление таких сертификатов — это просто супер удобно. Обычно на хостингах предусмотрено некоторое количество абсолютно бесплатных SSL сертификатов с автоматическим продлением, но за небольшую плату (10 рублей в месяц), можно подключить тестовые сертификаты для любого количества сайтов. Пример такого хостинга здесь.

Решение проблем

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

Главная подсказка в первой строке: Can’t open C:\Program Files\Common Files\SSL/openssl.cnf for reading, No such file or directory — она означает, что возникла ошибка чтения файла C:\Program Files\Common Files\SSL/openssl.cnf из-за того, что он отсутствует.

Файл openssl.cnf поставляется с самим веб-сервером Apache и находится в папке conf. Поэтому есть несколько вариантов, как исправить эту ошибку. Например, можно создать нужные папки и скопировать туда этот файл. Но можно пойти более простым путём — на время создания сертификатов установить переменную окружения OPENSSL_CONF указав в ней правильный путь до файла.

Также нужно переключиться из PowerShell в обычную командную строку Windows, поскольку иначе переменная окружения почему-то не устанавливается. Допустим, сервер размещён в папке C:\Server\bin\Apache24\bin\, тогда файл openssl.cnf расположен по пути C:\Server\bin\Apache24\conf\openssl.cnf, в этом случае, чтобы исправить ошибку Can’t open C:\Program Files\Common Files\SSL/openssl.cnf for reading, No such file or directory нужно выполнить:

Отредактируйте пути в этих командах в соответствии с вашей структурой папок.

Связанные статьи:

• Ошибка «You’re speaking plain HTTP to an SSL-enabled server port» (РЕШЕНО) (100%)
• Apache для Windows (51.3%)
• Как запустить Apache на Windows (51.3%)
• Документация по Apache на русском языке (51.3%)
• Как подключить PHP к Apache на Windows (51.3%)
• Как ограничить пропускную способность Apache на Windows для IP и отдельных файлов (RANDOM — 51.3%)

Comments

Статья не помогла. Очень важно приложить к статье openssl.cnf, который по факту должен быть прописан в переменной окружеия OPENSSL_CONF. Толку от такого сертификата нет, т.к приходится добавлять исключение и это ещё в самых лояльных браузерах. Такой сертификат не подписан к домену, что делает его бессмысленным.

Очень важно приложить к статье openssl.cnf,

Этот файл поставляется с веб-сервером. Зачем его здесь прикладывать?

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

Смотрите внимательнее команды — файл добавляется в переменную окружения. На один раз. Используется тоже один раз.

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

Тут половина статьи о валидных и самоподписанных сертификатах. Только вы не понимаете сути. Сертификат не «не подписан к домену». Домен в сертификате указан. Сертификат не подписан сервисом, который уполномочен проверять валидность сертификатов — нет смысла переписывать это из статьи, всё есть.

Чем не помогла? Тем, что браузеры не принимают самоподписанные сертификаты? В этом статья виновата?

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

Эта статья для тех, кто хочет потренироваться, проверить, как настраивать SSL сертификаты в веб-сервере Apache под Windows. Или для тех, кто уже купил себе валидный сертификат.

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

Спасибо за подробную статью!!

Если у кого-то с apache не запускается — закомментируйте строку «Listen 443» — у меня по умолчанию апач ее слушает.
Также я закомментировал строку «LoadModule ssl_module modules/mod_ssl.so» т.к. выше в конфиге она уже была по умолчанию.

Приветствую! Всё верно сказано — видимо, изменения связаны с обновлением сервера. Обновлю статью, чтобы не было проблем у других пользователей.

Громадное спасибо! Такая подробная, но без воды статья! Все сработало! Установил Apache, PHP, Mysql(по этой статье

), SSL (по текущей статье), все связано, все работает. Просто с недавних пор перестали удовлетворять разные сборки web серверов для разработчиков(старые версии продуктов в них зачастую, а при обновлении какого-то компонента перестает работать вся связка в целом). Теперь поставил все с новыми, актальными версиями, сэконоил благодаря вашему труду столько времени, спасибо еще раз!

Статья помогла, правда рулить стало только после установки OPENSSL_CONF.
Валидный сертификат для localhost-а я сгенерил mkcert-ом под windows.
Всё работает, но всё же было бы круто заставить апач генерить SSL-валидность, но как ?

Ещё было бы здорово обращаться к одному и тому же порту и через http и через https..

Ещё было бы здорово обращаться к одному и тому же порту и через http и через https..

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

Ну то есть на самом деле возможно )) Но тогда нужно делать два хоста и каждый из них будет иметь своё имя и, соответственно, свои настройки. В качестве хостов можно выбрать любые имена, например, site1.loc, site2.loc, site.home и вообще что угодно. Один из этих хостов на 80-м порту будет работать по протоколу HTTP, а другой хост будет настроен на 80-м порту обслуживать протокол HTTPS. Если вы действительно собираетесь этим заморачиваться, я дам вам ссылки.

Всё работает, но всё же было бы круто заставить апач генерить SSL-валидность, но как ?

Добавьте сгенерированный сертификат в доверенные и будет зелёный замочек — но только на том компьютере, где добавили. Ну или сгенерируйте сертификат сервера с помощью корневого сертификата, который был добавлен в доверенные (первый способ проще). Если вы действительно будете этим заморачиваться, я дам вам ссылки.

Других способов получить валидный SSLдля localhost нет. Нужно понимать, что в этом и есть суть, что кто попало не может сгенерировать сертификаты для чего попало. Можно получить (причём даже бесплатно) сертификат для публичного адреса (домена) который принадлежит вам. И подлинность этого сертификата будет удостоверять третья сторона.

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

1. я отправляю запрос на генерацию сертификат для своего домена, в запросе содержится адрес домена
2. третья сторона присылает мне строку, которую я должен разместить на своём домене, я размещаю её
3. после этого третья сторона заходит на мой домен (сайт), считывает строку, проверяет, что она верная. Это означает, что данный домен действительно принадлежит тому, кто делает запрос на выдачу сертификата
4. третья сторона выдаёт мне сертификат
5. я добавляю сертификат в настройки сервера
6. веб-браузер посетителей «смотрит», кем выдан сертификат и делает запрос к третьей стороне, «действительно ли был выдан такой сертификат для этого домена?»
7. третья сторона отвечает «да, всё норм»
8. веб-браузер пользователя начинает считать этот сертификат доверенным

Допустим, я хочу сертификат для домена localhost.

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

А если бы третья сторона давала сертификаты «на веру» без проверки, или если бы на своём компьютере можно было генерировать валидные сертификаты для любого имени, то это как выпускать замки, которые можно открыть любым ключом или вообще без ключа — не было бы никакого смысла городить этот огород, тогда уж проще вообще без сертификатов, поскольку никакого толка в них бы не было.