Включение ssl apache. Установка mod_ssl в apache
Чтобы настроить SSL сертификат, один из наших клиентов, Алексей, следовал пошаговому руководству, и, казалось, все прошло хорошо. Но позже начали появляться негативные последствия, например, длительное время загрузки, частичная недоступность веб-сайта. Все это очень расстроило Алексея, так как от установки SSL сертификата он ожидал только улучшение работы своего веб-проекта. Наша поддержка решила разобраться с ошибками конфигурации и помочь Алексею на самом деле защитить данные посетителей его сайта.
Если настроить SSL неверно, пользы не будет даже от наилучшего сертификата
Следуя политике безопасности информации, Алексей решил защитить свой веб-проект, в т.ч. зашифровать передаваемые данные с помощью SSL сертификата. И хотя это не интернет-магазин и не финансовое учреждение, все же на сайте имеется область регистрации и авторизации в личный кабинет, где обрабатываются заказы. Так как пользователи здесь оставляют свои контактные данные, шифрование давало Алексею не только конкурентное преимущество, но и действительно было необходимо для защиты информации пользователей.
Алексей выбрал SSL сертификат от поставщика, обещавшего самый высокий уровень защиты за несколько кликов. Изучив информацию, Алексей понял, что простого сертификата с проверкой только домена будет недостаточно. Он выбрал решение среднего класса и заказал SSL сертификат с проверкой компании. Ранее мы уже рассматривали разные уровни валидации .
Пройдя проверку и получив файлы сертификата, Алексей взялся за его установку. Он шаг за шагом следовал руководству по установке. Но что-то пошло не так… Страница начала загружаться медленней, временами была недоступной, и, как выяснилось в тесте от Qualys SSL Labs, не была действительно защищенной. Что же произошло?
Ошибки конфигурации из-за устаревшего руководства
Алексей связался с нами и прислал результаты теста SSL-сервера, так как ему они были не совсем понятны. Мы также попросили Алексея прислать нам руководство, по которому он устанавливал SSL сертификат. При этом оказалось, что в инструкции не учитывалось актуальное положение в дел в области безопасности, в связи с чем многие пользователи оставались в опасности, даже с установленным сертификатом.
Например, в инструкции отсутствовало указание, что нужно отключить SSL 3-й версии. Уже давно известно о небезопасности протоколов шифрования SSLv3 и RC4, и существует достаточно альтернатив для них. В октябре 2015 года поисковый гигант Google решил попрощаться с этими небезопасными стандартами. Поэтому мы посоветовали Алексею отключить эти SSL-протоколы и использовать TLS в версиях 1.0, 1.1 и 1.2.
Конфигурация SSL при обмене ключами
Далее мы объяснили Алексею, что срок действия сертификата, доверенность центра сертификации, а также используемые алгоритмы хэширования также влияют на оценку. Алексей выбрал очень хороший SSL сертификат, поэтому к достижению хорошей оценки оставалось всего несколько шагов. На самом деле, сертификаты EV с расширенной проверкой оцениваются выше, это Алексей знал и ранее, но позволил себе сэкономить. Тем не менее, он проследил, чтобы при выпуске сертификата использовался длинный приватный ключ, который он сам хранит на защищенном компьютере. Алексей защитил сертификатом имена пользователей и пароли, как он и планировал. Но ошибки в настройке SSL могут сделать даже наилучший сертификат бесполезным.
Cookies также следует защищать
Алексей решил использовать файлы Cookies. Он добавил соответствующее предупреждение для посетителей сайта и указал на использование этого технологии в Политике конфиденциальности.
Тем не менее, он не заметил одну деталь: файлы cookies также необходимо защищать, в противном случае возрастает возможность проведения MITM-атаки. С помощью специальных флагов можно установить, будут ли cookies передаваться по защищенному HTTPS-соединению или по незащищенному HTTP-соединению.
Если не установить флаги безопасности, происходит следующее: пользователь обращается к вашему сайту по HTTPS и cookie начинает свою работу, т.е. отслеживает действия этого пользователя. Позже, посетитель возвращается, но на этот раз он обращается к сайту по HTTP. Cookie по-прежнему отправляется к веб-приложению. В такой ситуации злоумышленник может отследить cookie, выдать себя за пользователя, и свободно действовать от его имени.
Использование HSTS для устранения ошибок
Как мы видим, возможность управлять зашифрованными сайтами через HTTP, то есть по незащищенному каналу, открывает большую дыру в безопасности. Эту проблему можно решить с помощью механизма HSTS. HSTS (сокращенно от «HTTP Strict Transport Security») – это технология, которая принудительно активирует защищенное HTTPS-соединение. Все современные браузеры используют HSTS как стандарт. Активированный HSTS устанавливает, что (HTTP-)сервера должны использовать защищенное соединение. Также HSTS-стандарт обязывает прикладные программы взаимодействовать с сайтом только по зашифрованному каналу. В двух словах: HSTS предотвращает использование HTTP и активирует HTTPS-соединение.
OCSP для увеличения секретности
SSL сертификат Алексея содержит URL-адрес ответчика OCSP , которым управляет центр сертификации, выдавший SSL сертификат. Этот URL-адрес проверяется браузерами при установлении соединения с сайтом по протоколу HTTPS, чтобы определить, не отозван ли сертификат. Таким образом, можно исключить его неправомерное использование. После того, как соединение с веб-сайтом установлено, отправляется следующий запрос на OCSP-ответчик. Даже это краткое описание процесса показывает, что дополнительное соединение с ответчиком обеспечивает более высокий уровень секретности.
С помощью метода «OCSP-Степлинг» можно решить проблемы, вызванные OCSP. Через определенные промежутки времени, например, каждый час, веб-сервер получает OCSP-ответ о состоянии собственного сертификата. Этот ответ отправляется непосредственно браузеру пользователя при первичном рукопожатии. Соединение между браузером пользователя и OCSP-ответчиком с этой целью не требуется. Безопасность процесса обеспечивается тем, что ответ OCSP–ответ всегда подписан OCSP-ответчиком центра сертификации, и эту подпись проверяет браузер.
HPKP — пиннинг открытого ключа
Можно ли доверять сертификату из цепочки корневого и промежуточных сертификатов? Чтобы получить ответ на этот вопрос, используется процедура, называемая HPKP, сокращенно от HTTP Public Key Pinning. Пиннинг открытого ключа позволяет определить, когда открытый ключ сертификата был изменен для определенного хоста. Это может произойти со скомпрометированными сертификатами. Таким образом, HPKP становится механизмом, который проверяет подлинность сертификатов SSL/TLS.
Правильная настройка SSL сертификата: инструкции, которым можно доверять
Конечно же, инструкциям по установке доверять можно и нужно, но они должны быть актуальными. Следующие рекомендации из надежных источников помогут вам избежать ошибок:
- используйте безопасное HTTPS-соединение для всех веб-сервисов;
- автоматическое перенаправление: чтобы избежать незашифрованных обращений к серверу, настройте автоматическое перенаправление на HTTPS-версию;
- библиотеки TLS: полагайтесь только на последние версии. При использовании TLS вы никого не исключаете, но если вы применяете незащищенный SSL, вы также включаете и потенциальных хакеров;
- настройте HSTS, чтобы гарантированно исключить незашифрованные соединения. Это можно сделать двумя способами: во-первых, вы можете дополнить заголовок HSTS так, чтобы браузер обращался только к HTTPS-версии сайта. Во-вторых, вы можете поместить свой сайт в список предварительной загрузки HSTS. Он оповещает современные браузеры, что HTTP-обращения необходимо автоматически перенаправлять на HTTPS;
- заказывайте SSL/TLS сертификаты только на доверенных сайтах;
- лучше всего заказывайте SSL сертификаты с расширенной проверкой (
Недавно я уже рассказывал о том как для подтверждения доменного имени. Мы его использовали для организации ssl/tls соединений в почтовом сервере. Теперь его же мы будем использовать для того, чтобы перевести наш сайт на работу по ssl протоколу.
Установка mod_ssl в apache
В качестве сервера у нас выступает , хотя это не принципиально, настройка на других linux дистрибутивах будет идентичной. Рабочим web сервером является apache . Использовать ssl протокол в apache мы будем с помощью мода mod_ssl . Первым делом проверим, установлен ли он:
# rpm -qa | grep mod_ssl
Если нет, то устанавливаем:
# yum -y install mod_ssl
После установки мода, идем в директорию /etc/httpd/conf.d и правим там файл настроек ssl.conf. Прописываем пути к сертификатами в директивах SSLCertificateFile и SSLCertificateKeyFile .
Создание виртуального хоста с поддержкой ssl
После сохранения проверяем конфигурацию apache:
# httpd -t
Если появляется предупреждение:
Default_ VirtualHost overlap on port 443, the first has precedence
То ищем в /etc/httpd/conf/httpd.conf строчку NameVirtualHost *:80 и добавляем после нее NameVirtualHost *:443
Снова проверяем. Если ошибок нет, перезапускаем апач и заходим на сайт, прописав в адресной строке https, вместо http. Теперь ваш сайт доступен по протоколу https. Но пользователи сайта могут об этом не знать. Было бы разумным сделать переадресацию с открытого протокола на защищенный. Сделаем это.
Переадресация с http на https
Для того, чтобы сделать автоматическую переадресацию с http на https, необходимо в описании виртуального хоста в httpd.conf добавить порт 80 вместе с 443:
И в корне сайта с помощью.htaccess и mod_rewrite делаем перенаправление всех запросов с http на https:
# cat .htaccess RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
Теперь даже если просто набрать адрес сайта с http откроется его защищенная версия https. Не забудьте проверить, включен ли у вас модуль mod_rewrite в настройках apache. И проверьте фаервол. Для корректной работы сайта по протоколу https необходимо открыть 443 порт на веб сервере.
TLS или безопасность транспортного уровня - предшественник SSL, отвечает за безопасность на уровне сокетов, по сути это защищённый протокол созданный для того, чтобы обеспечить безопасную передачу обычного сетевого трафика.
За счет этих протоколов информация может быть безопасно передана между двумя узлами не будучи при этом перехваченной и прочтённой третьими лицами. Также они отвечают за проверку подлинности домена и сервера, проверяя достоверность сертификата.
В этой статье я расскажу как создать самостоятельно подписанный сертификат SSL для Apache на базе Ubuntu 14.04, что позволит вам шифровать поступающий трафик. Хотя такой способ не обеспечивает проверки подлинности сервера, он позволяет пересылать информацию в защищенном режиме.
Требования
Прежде чем начать, требуется выполнить некоторые настройки. Пользователь, под которым мы будем работать должен иметь sudo привелегии. Также нам понадобится установленный Apache. Если вы его ещё не установили, то можете сделать это выполнив следующие команды:
Sudo apt-get update sudo apt-get install apache2
Шаг 1 - Активация модуля SSL
Пакет Apache для Ubuntu 14.04 по-умолчанию поддерживает SSL . Его достаточно просто активировать. Команда для активации модуля:
Sudo a2enmod ssl
После активации SSL следует перезапустить сервер для вступления в силу новых настроек:
Теперь наш веб сервер поддерживает SSL, осталось выполнить некоторые настройки.
Шаг 2 - создание подписанного сертификата SSL
Для начала создадим поддиректорию в каталоге настройки Apache, где будем хранить сертификат.
Sudo mkdir /etc/apache2/ssl
Теперь создадим здесь ключ и сертификат одной командой:
Sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Давайте подробно разберёмся в параметрах команды:
- openssl - основной инструмент для создания и управления сертификатами, ключами, запросами на подпись и т.д. для OpenSSL
- req - этот параметр задаёт запрос на подпись сертификата X.509. X.509 - стандартная структура открытого ключа, которой придерживается SSL для управления ключами и сертификатами. Нам необходим этот параметр так как мы хотим создать новый сертификат.
- -x509 - этот параметр указывает на то, что мы хотим создать самостоятельно подписанный сертификат.
- -nodes - указывает на то, что мы не хотим создавать кодовую фразу. При создании кодовой фразы у вас могут возникнуть проблемы при автоматическом запуске Apache, так как каждый раз придется её вводить.
- -days 365 - срок действия сертификата - один год.
- -newkey rsa:2048 - этот параметр указывает на одновременное создание приватный ключа и запроса на сертификат. Это необходимо, так как мы не создали приватный ключ заранее. rsa:2048 - создает RSA ключ длиной 2048 бит.
- -keyout - имя файла создаваемого приватного ключа.
- -out - имя файла создаваемого сертификата.
После запуска этой команды вам предстоит ответить на несколько вопросов. Наиболее важный из которых - Common Name (e.g. server FQDN or YOUR name)". Здесь следует ввести доменное имя ассоциируемое с сертификатом, или открытый IP адрес при отсутствии доменного имени.
Вопросы выглядят примерно следующим образом:
Country Name (2 letter code) :RU State or Province Name (full name) :Moscow Locality Name (eg, city) :Moscow Organization Name (eg, company) :Your Company Organizational Unit Name (eg, section) :Department of Kittens Common Name (e.g. server FQDN or YOUR name) :your_domain.com Email Address :[email protected]
Ключ и сертификат будут созданы в каталоге /etc/apache2/ssl .
Шаг 3 - Настройка Apache для использования SSL
Теперь у нас есть сертификат и ключ и мы можем настроить Apache для использования этих файлов в файле виртуальных хостов. Вместо использования шаблона 000-default.conf мы воспользуемся шаблоном default-ssl.conf , который уже включает в себя некоторые необходимые настройки.
Откройте этот файл с правами root:
Sudo nano /etc/apache2/sites-available/default-ssl.conf
После удаления комментариев файл выглядит следующим образом:
Выглядит довольно сложно, но нам и не надо глубоко вникать в структуру этого файла. Для начала укажем обычные параметры, которые мы задаем при создании виртуального хоста (ServerAdmin, ServerName, ServerAlias, DocumentRoot и т.д.) и укажем место хранения SSL сертификатов. В итоге файл настройки должен выглядеть примерно следующим образом:
Сохраните и закройте файл после исправления.
Шаг 4 - активация виртуального хоста с SSL
Теперь настало время включить наш виртуальный хост. Выполняем команду:
Sudo a2ensite default-ssl.conf
Перезапускаем Apache:
Sudo service apache2 restart
Теперь виртуальный хост, который будет служить для безопасной передачи данных, должен запуститься.
Шаг 5 - проверка
Итак, мы выполнили предварительную настройку, настало время проверить её. Заходим на наш сервер через протокол https://
Https://you_domain.com
Вы должны увидеть предупреждение о том, что невозможно проверить ваш сертификат, так как он не был подписан одной из известных удостоверяющих организаций. Этого следовало ожидать, так как мы самостоятельно подписывали свой сертификат. Хотя наш сертификат и не проходит проверку, так как он не был подписан удостовереяющей организацией, трафик все равно будет шифроваться.
Итак, нажимаем “Proceed anyway” (продолжить). Вы будете перенаправлены в корневой каталог вашего домена. Теперь ваш трафик зашифрован. Вы можете убедиться в этом увидев значок замка на панели меню.
Заключение
Ваш сайт теперь поддерживает SSL. Таким образом вы защищаете соединение между пользователями и вашим сайтом, но каждый раз пользователи будут видеть предупреждение о том, что сертификат невозможно проверить.
Если вы собираетесь запускать проект с использованием SSL, следует задуматься над приобретением SSL сертификата от удостоверяющего центра.
Перед установкой SSL-сертификата перейдите к и убедитесь, что услуга SSL-сертификата активна:
Установка SSL-сертификата через форму на сайте
После отправки заявки:
- на виртуальный хостинг сертификат будет установлен автоматически;
- на VPS и выделенный сервер установка будет произведена в ручном режиме нашими системными администраторами.
По окончании установки сертификата вы получите сообщение на контактный e-mail.
Сертификат не работает с www
Как правило, это означает что у вас заказан не Wildcard сертификат , т.е. действие сертификата распространяется только на тот домен, для которого он был заказан, например, на mysite.ru . На поддомены, в том числе и на www.mysite.ru , такие сертификаты не распространяются.
В качестве решения вы можете настроить переадресацию с http://www.mysite.ru/ на https://mysite.ru/ , для этого воспользуйтесь .
Самостоятельная установка
При необходимости вы можете самостоятельно установить SSL-сертификат на хостинг и на VPS при помощи следующих инструкций:
Как установить SSL-сертификат на сторонний хостинг
Для установки SSL-сертификата на сторонний хостинг вы можете воспользоваться инструкциями по самостоятельной установке через панель управления (см. инструкцию выше) или обратиться в техническую поддержку вашего хостинг-провайдера. Специалисты сайт не оказывают консультаций по вопросам установки сертификатов на сторонний хостинг.
Итак, вы приобрели SSL-сертификат для вашего домена. В процессе заказа вы должны были выбрать авторизационный email, расположенный на вашем домене: admin, administrator, hostmaster, postmaster, webmaster. На выбранный вами авторизационный email придет письмо содержащее ссылку, пройдя по которой, вы подтвердите ваши административные права домена. После этого на ваш контактный электронный почтовый ящик аккаунта поступит несколько писем.
Имеются следующие файлы:
Приватный ключ (для удобства сохраните его в виде простого текстового файла с именем ваш_домен.key)
Файл сертификата для вашего домена, ваш_домен.crt
Два файла цепочки сертификатов PositiveSSLCA2.crt и AddTrustExternalCARoot.crt
В этом руководстве пошагово описаны способы привязки SSL-сертификата к сайту для организации безопасного шифрованного соединения между веб-сервером и браузером клиента.
Обратите внимание, если письмо, содержащее приватный ключ, к вам не поступило, то в первую очередь проверьте, пожалуйста, каталог "Спам" в вашем почтовом ящике. В том случае, если в указанном каталоге письмо не обнаружено, напишите, пожалуйста, письмо с контактного электронного почтового ящика аккаунта на
Установка сертификата средствами ISPmanager
1. Войдите в ISPmanager под учетной записью "root". (Если вы заказали VPS сервер на тарифе с администрированием нашими специалистами, то данный шаг необходимо пропустить)
Войдите в меню "Учетные записи" → "Пользователи", выберите пользователя-владельца сайта, к которому требуется привязать SSL-сертификат, и нажмите кнопку "Изменить".
В появившемся установите галочку "Может использовать SSL", если она еще не установлена.
Сохраните изменения кнопкой "Ok".
Дальнейшие действия мы будем выполнять от имени созданного пользователя-владельца сайтов. Снова выберите вашего пользователя-владельца сайта и нажмите кнопку "Войти" в правом верхнем углу, ISPmanager автоматически понизит ваши привилегии до его уровня.
2. Перейдите в раздел "WWW" → "WWW-домены". В списке отображаются все добавленные в конфигурационные файлы веб-сервера домены, в колонке "Параметры" иконками отображается наличие или отсутствие тех или иных модулей веб-сервера, которые участвуют в обработке запросов к сайту. Необходимо подключить модуль для работы с SSL для сайта, для этого выберите домен и нажмите кнопку "Изменить" сверху.
Откроется новая вкладка, в которой нужно установить галочку "Защищённое соединение (SSL)" и "Перенаправлять HTTP-запросы в HTTPS" и сохранить изменения кнопкой "Ok". Обратите внимание, желательно чтобы этот домен был единственным доменом с SSL на этом IP-адресе.
3. Теперь перейдем в раздел "WWW" → "SSL сертификаты", здесь показаны все имеющиеся на сервере сертификаты безопасности, отсюда мы добавим наш. Обратите внимание на наличие самоподписанного сертификата для вашего домена - он был сгенерирован ISPmanager-ом автоматически на предыдущем шаге, в момент когда вы установили галочку "SSL" в настройках WWW-домена. Этот сертификат использоваться не будет, мы добавим наш, сделать это можно кнопкой "Создать" сверху.
На первом шаге выберете тип сертификата "существующий".
На втором шаге вам необходимо будет ввести имя сертификата, сам сертификат, приватный ключ сертификата и подтверждающую цепочку. Откройте в "Блокноте" все имеющиеся у вас файлы: приватный ключ, который мы сохранили в файл ваш_домен.key, файл сертификата ваш_домен.crt и другие два. В форму ввода "SSL-сертификат" скопируйте содержимое файла ваш_домен.crt; в форму "Ключ SSL-сертификата" скопируйте текст из файла ваш_домен.key. В форму "Цепочка SSL-сертификатов" последовательно скопируйте содержимое файлов PositiveSSLCA2.crt и AddTrustExternalCARoot.crt, именно в этом порядке. Нажмите кнопку "Завершить" для сохранения введенных данных.
В открывшемся окне в поле "SSL-сертификат" выберете добавленный вами в предыдущем шаге сертификат и подтвердите изменения кнопкой "Ok".
5. Перейдите на ваш сайт, для работы по шифрованному соединению в адресной строке браузера впишите адрес наподобие "https://ваш_домен.ru/". Аббревиатура "https" означает работу по шифрованному протоколу HTTP, что нам и требуется. Если все сделано правильно, браузер не будет выдавать никаких предупреждений или сообщений о потенциальных угрозах, а сразу отобразит сайт. В адресной строке при этом тем или иным способом будет обозначен факт того, что передаваемые данные шифруются и сертификат подтвержден.
Настройка закончена. Следует, однако, иметь в виду, что при каких-либо изменениях в ПО веб-сервера (его переконфигурирование, смена IP-адреса домена, установка nginx перед Apache например) эта схема работы может нарушиться. В этом случае возможно придется внести соответствующие коррективы в конфигурационные файлы веб-сервера вручную.
Если у вас возникнут какие-либо вопросы при добавлении сертификата к вашему сайту - техническая поддержка всегда будет рада помочь вам, напишите пожалуйста письмо на адрес support@сайт с контактного e-mail вашего сервера.
Установка сертификата утилитами из консоли: CentOS, Apache 2
Если на вашем сервере установлен и используется проксирующий веб-сервер nginx, вам следует организовать работу с сертификатами с его помощью. Инструкция по настройке nginx ниже, отдельным пунктом.
1. Поместите все 4 файла (приватный ключ, сохраненный в файле ваш_домен.key , и файлы сертификатов ваш_домен.crt , PositiveSSLCA2.crt и AddTrustExternalCARoot.crt
# cat /var/www/httpd-cert/PositiveSSLCA2.crt /var/www/httpd-cert/AddTrustExternalCARoot.crt > -bundle
# openssl verify /var/www/httpd-cert/ваш_домен.crt-bundle
5. В конфигурационном файле Apache 2 (наиболее вероятно - /etc/httpd/conf/httpd.conf) создайте новый VirtualHost на 443м порту. Ниже приведены только директивы, отвечающие за работу с сертификатом, остальные можно скопировать по аналогии из имеющегося для 80-го порта:
SSLEngine on
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
SSLCertificateFile /var/www/httpd-cert/ваш_домен.crt
SSLCertificateKeyFile /var/www/httpd-cert/ваш_домен.key
SSLCACertificateFile /var/www/httpd-cert/ваш_домен.crt-bundle
ServerName ваш_домен
...
6. Проверьте корректность синтаксиса конфигурационного файла:
# /etc/init.d/httpd configtest
Syntax OK
Перезапустите Apache и проверьте работу сайта с https://, если все сделано правильно - в адресной строке при этом тем или иным способом будет обозначен факт того, что передаваемые данные шифруются и сертификат подтвержден.
Установка сертификата утилитами из консоли: CentOS, nginx
1. Поместите все 4 файла (приватный ключ, сохраненный в файле ваш_домен.key, и файлы сертификатов ваш_домен.crt , PositiveSSLCA2.crt и AddTrustExternalCARoot.crt ) в директорию /var/www/httpd-cert/.
2. Установите владельца и группу всех файлов в root:
# chown root:root /var/www/httpd-cert/ваш_домен.key /var/www/httpd-cert/ваш_домен.crt /var/www/httpd-cert/PositiveSSLCA2.crt /var/www/httpd-cert/AddTrustExternalCARoot.crt
3. Установите права на файл ключа "только для владельца, только для чтения":
# chmod 400 /var/www/httpd-cert/ваш_домен.key
4. Создайте файл цепочки сертификатов:
# cat /var/www/httpd-cert/AddTrustExternalCARoot.crt >> /var/www/httpd-cert/ваш_домен.crt
# cat /var/www/httpd-cert/PositiveSSLCA2.crt >> /var/www/httpd-cert/ваш_домен.crt
Проверить подлинность цепочки сертификата можно так:
# openssl verify /var/www/httpd-cert/ваш_домен.crt
/var/www/httpd-cert/ваш_домен.bundle: OK
Посмотреть информацию об сертификате - например так:
# openssl x509 -text -in ваш_домен.crt
5. Внесите в конфигурационный файл nginx, в модуль server, следующие директивы:
server {
Ssl on;
ssl_certificate /var/www/httpd-cert/ваш_домен.crt;
ssl_certificate_key /var/www/httpd-cert/ваш_домен.key;
Server_name your.domain.com;
...
}
Обратите внимание, что это должен быть первый, и желательно единственный VirtualHost на этом IP-адресе на 443 порту.
6. Перезапустите nginx командой
# /etc/init.d/nginx restart
и проверьте работу сайта с https://, если все сделано правильно - в адресной строке при этом тем или иным способом будет обозначен факт того, что передаваемые данные шифруются и сертификат подтвержден.
