Установка SSL на WordPress. Плюсы и минусы процесса.

Итак, постепенно мы пришли к тому, что требование к установке SSL сертификатов из разряда «желательно» перешло в разряд «нужно». В этом материале постараюсь объяснить суть задачи, конечные цели и смысл в реализации этого полезного процесса.

Что произошло?

Не так давно, платформа Google начала настойчиво требовать подключения SSL у всех коммерческих площадок, работающих с платёжными и персональными данными. Требования были довольно таки очевидны, поскольку уже не осталось человека, который бы не слышал про страшных сетевых мошенников, которые пользуясь массовым незнанием населения, яростно выкрадывают номера платёжных карт и всячески пытаются залезть в карман добросовестного потребителя. Казалось бы, SSL не решает проблему социального взлома, но на уровне перехвата данных, наличие стабильного шифрования превращает задачу похищения данных в невыполнимый и мучительный процесс. Стало быть, если у вас некоммерческая площадка, то и установка сертификатов вам ни к чему, но… Google ещё раз обрадовал владельцев сайтов, что теперь HTTPS (защищённый протокол HTTP) становится стандартом де-факто для всех «сайтостроителей».  Разумеется, если у вас на ресурсе пасётся 200 человек, то устраивать себе сложные выходные скорее всего не потребуется, но для серьёзной площадки наличие SSL является насущной необходимостью, которая эффективно защищает как ваших пользователей, так и вас, как потенциальную жертву различных видов взлома. Следует отметить, что SSL (Secure Sockets Layer) это устойчивое обозначение безопасного метода соединения, хотя на данный момент он признан невзломоустойчивым и существует общая рекомендация перехода на TLS (Transport Layer Security). Все современные центры сертификации обеспечивают работу по TLS, но аббревиатура SSL по-прежнему в ходу.

Где взять сертификаты?

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

Итак, самое интересное – где взять бесплатный SSL сертификат?

Наиболее известный зарубежный поставщик бесплатных SSL сертификатов — https://www.startssl.com/ . Start SSL позволяет бесплатно получить сертификат первого уровня сроком на один год. Минусы – довольно запутанная регистрация и невозможность перевыпуска сертификата при необходимости.

Более известный провайдер – Comodo ( http://comodo-ssl.com/ ) предоставляет бесплатную версию сертификата почти на три месяца (90 дней). Минус – потом будете платить. Хотя вроде бы они позволяют генерировать новый пакет каждые три месяца, но не проверял.

И всё. Правда. Остальные поставщики вообще не заслуживают внимания, либо работают по схеме схожей с Comodo.

Где взять платный сертификат?

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

https://www.globalsign.com/ru-ru/ — Global Sign ещё один крайне известный поставщик платных SSL сертификатов. Но и ценник там соответствующий, так что если хотите экономить, то выбор пока ещё есть.

https://www.geotrust.com – Geotrust. Очень дорого. Никакой гибкости в тарифных планах.

https://www.rapidssl.com/ — Rapid SSL – дороже, чем Comodo, но вполне доступен. Рекомендуется покупка сертификата на три года.

И, наконец, самые дорогие сертификаты поставляет компания Symantec — https://www.symantec.com/ru/ru/ssl-certificates/ (бывший VeriSign). Огромные гарантии, конские цены и всё как не любим. Рекомендуется для серьёзных людей, коим не жалко отваливать по 20 тысяч рублей в год.

Из Российских поставщиков наиболее известны упомянутые ранее: Reg.ru или Nic.ru (Ру-Центр), у них доступные цены, но, как вы понимаете, в связи с «законом Яровой» — это ещё и 100% гарантия взлома, если вами заинтересуются определённые персонажи.

Как получить и настроить сертификат?

Теперь начинается сложная часть материала, ибо он претендует на роль «How to do» инструкции для не совсем чайников. Это на самом деле нетривиальная задача и её решение требует уймы «побочных» знаний. Для примера, на диком сайта freelance.ru мне предлагали решение этой проблемы по цене от 5 до 20 тысяч рублей… И как всегда, это можно сделать самостоятельно.  Вопросы традиционно задаются в комментариях. Реализация процесса будет происходить на базе ОС Centos 6.5 с установленным Nginx. В качестве поставщика сертификата выбираем Comodo SSL, как наиболее дешёвого и простого.  Речь пойдёт про WordPress и в заключительном слове расскажу про Bitrix.

1. Часть первая. Подготовка сервера.

• Подключаемся к серверной консоли по протоколу SSH.
• Устанавливаем OpenSSL для генерация CSR запроса и ключевого SSL файла

yum install openssl

(скорее всего уже установлено, т.к. OpenSSL идёт в базовой поставке Centos)

• Смотрим, где мы находимся

ls

• Генерируем ключевые файлы

openssl req -new -newkey rsa:2048 -nodes -keyout my_new.key -out my_new.csr

Где my_new.*** — название файлов где будут сгенерированы ключи

Обратите внимание! Программа начнёт запрашивать у вас следующие данные:

Country Name – если речь идёт про Россию, то RU

State or Province Name – вводим то, что считаем нужным. Если Москва, то Moscow

Locality Name – город, если Москва, то Moscow

Organization Name – название организации, на базовом уровне SSL сертификации роли не играет. Вводите либо то, что есть, либо просто название сайта

Organizational Unit Name – подразделение компании

Common Name – полное имя домена (например, www.mysite.ru)

Email Address – адрес электронной почты на домене (admin@mysite.ru)

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

Файлы my_new.key my_new.csr созданы и готовы к дальнейшему использованию.

2. Часть вторая. Получение сертификата Comodo.

• Идём на сайт http://comodo-ssl.com/ssl/comodo-free-ssl-certificate-na-90-dney , нажимаем «Купить»

• Заполняем предложенные поля формы (рекомендую на латинице).

 

Нажимаем «Далее», открывается окно для вставки CSR кода.

• Возвращаемся в консоль сервера и вводим команду

vi my_new.csr

• Копируем содержимое файла в соответствующее поле.

 

Выбираем сервер для генерации ключей (любой) и нажимаем «Дальше».

• Теперь нас перебрасывает на английский сайт Comodo, где мы, ещё раз вставляем содержимое файла my_new.csr и ещё раз выбираем сервер для генерации.
  
  Обратите внимание, что бы галочка «Opt in» была убрана, иначе замучают спамом.

Нажимаем Next.

• На экране появляется этап валидации домена по электронной почте.

Создаём на своём почтовом хостинге аккаунт из предложенных системой (в случае примера «admin@», после чего нажимаем Continue и ждём письма с кодом подтверждения.

• На следующем этапе вы проверяете информацию и добавляете требуемые сведения. При чём заполнять нужно только те поля, которые выделены красным цветом (стрелками на скриншоте). На этом же этапе создаётся учётная запись Comodo.

Заполнили, нажимаем Next.

• Теперь убеждаемся, что мы заказали сертификат стоимостью 0.00 долларов, сроком на 90 дней. Соглашаемся с правилами и нажимаем Continue to payment information.

• Видим, что уже почти всё, осталось только ввести код подтверждения из почтового ящика для чего проверяем почту и ждём письма. Полученный код вставляем в поле отмеченное стрелкой.
  
  Нажимаем Next, затем Complete.

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

3. Часть третья. Установка сертификатов Comodo на Nginx.

Сразу отметим, что установка SSL под обычный Apache web server делается несколько проще. Однако пока Nginx всё ещё неплохо справляется со своими обязанностями прокси-сервера для динамического «фронтенда», посему работаем с ним. Возможно позднее, инструкция будет дополнена и в части конфигурации Apache.

Получив архив с файлами ключей его нужно разаархивировать на локальной машине и изучить содержимое.

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

AddTrustExternalCARoot.crt

COMODORSAAddTrustCA.crt

COMODORSADomainValidationSecureServerCA.crt

mysite_ru.crt

Далее существуют два способа интеграции ключей в Nginx, либо мы собираем все ключи в два файла командой:

cat mysite_ru.crt COMODORSADomainValidationSecureServerCA.crt  COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > ssl-keyz.crt

где ssl-keyz.crt файл со всеми ключами.

Либо второй способ – прописываем в конфигурационные файлы Nginx только корневой сертификат и ключ сгенерированный ранее (файл my_new.key ч.1 п.4 ).

Рекомендую первый способ, с получением ssl-keyz.crt и в качестве примера привожу только его. Все сертификаты рекомендую запрятать куда-то на сервере, это может быть произвольная папка в любом месте, но обычно используется что-то вроде /home/ssl/

Теперь идём в конфигурационные файлы Nginx (обычно это где-то тут — /etc/nginx/conf.d/)

vi /ect/nginx/имя-конфигурационного-файла.conf
пишем следующее:

server
{
 server_name mysite.ru www.mysite.ru #вписываем название домена
 listen *:443; #слушаем порт 443
 ssl on; #включаем поддержку SSL
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #задействуем протоколы SSL(TLS)
 ssl_certificate /home/ssl/ssl-keyz.crt; #указываем на сертификаты выданные Comodo
 ssl_certificate_key /home/ssl/my_new.key;#указываем главный ключ
}

Если нам нужна безусловная переадресация (редирект) на с http на https, то в конфигурацию добавляются следующие строки:

server
{
 listen *:80; #слушаем порт 80
 server_name mysite.ru  www.mysite.ru; #что переадресовываем
 return 301 https://$host/$1; #и отдаём 301 редирект с переадресацией на HTTPS
}

 

Затем открываем порт 443 на файрволе iptables.

iptables -I INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

Сохраняем настройки в конфигурационном файле iptables

iptables-save | sudo tee /etc/sysconfig/iptables

Перезапускаем файрвол

/etc/init.d/iptables restart

Перезапускаем сервер httpd

/etc/init.d/httpd restart

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

https://mysite.ru и смотрим, всё ли у нас получилось. Если всё идеально, что бывает не всегда, то в статусе соединения вы увидите зелёный замок.

Это означает, что соединение с сайтом произошло корректно и сертификат работает корректно.

Но скорее всего картинка будет такой.

И это неудивительно… поэтому начинается четвёртую часть, где мы покажем, как настраивать CMS WordPress для работы с SSL.

4. Часть четвёртая. Настройка SSL в WordPress.

Уровень «закипающий чайник».

Проблема в том, что вы всё это время использовали протокол http, который чисто механически оставил следы в коде CMS. Это не ваша вина (хотя нет, врём, абсолютные URL это всегда ваша вина). Но давайте пока попробуем базовыми методами устранить старые следы. Открываем «админку» WordPress и идём в «Настройки» — «Общие». Находим там поля «Адрес WordPress (URL)» и «Адрес сайта (URL)» и изменяем там http://mysite.ru на https://mysite.ru. Сохраняем настройки и проверяем результат.

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

Получилось? Если да – поздравляю, если замочек в статусе всё ещё перечёркнут, то начинаем процедуру глубокой настройки WP.

Уровень «мастер».

Придётся лезть в SQL запросы и если от этого становится страшно, до лучше дайте денег специалисту. Будет на кого поорать в случае чего.  При работе с базами данных ВСЕГДА делайте резервные копии!

Чаще всего кишки HTTP остаются в статьях и картинках и если у вас на сайте их много, то руками их не перебрать. Идём в SQL консоль (Phpmyadmin или из SSH консоли) и делаем вот такую команду к БД где установлен WordPress.

UPDATE wp_posts SET

post_content = REPLACE(post_content, 'http://mysite.ru/', 'https://mysite.ru/');

Где wp_post – таблица с вашими статьями и заметками

Помогло? Нет? Не беда, включаем безусловную поддержку SSL на уровне ядра WordPress, для чего скачиваем плагин WordPress HTTPS и в его настройках указываем следующее.

SSL Host – www.mysite.ru и Port 443

Дальше находим пункт Remove Unsecure Elements и активируем его. Важно! Это может привести сайт в неработоспособное состояние! Или отключить какие-то кривые плагины.

Проверяем! Опять не помогло? Тогда начинается самое сложное – отладка выводимой информации, для чего устанавливаем браузер Firefox для разработчиков.  https://www.mozilla.org/ru/firefox/developer/

Запускаем браузер, открываем сайт, кликаем правой кнопкой мыши и выбираем Inspect Element with Firebug, далее вкладка Console, там кликаем Secure. Смотрим, что конкретно происходит во время загрузки страницы и получаем более чем наглядную информацию об элементе, который вызывает ошибку SSL. По опыту можем отметить, что чаще всего проблема связана с разработчиками кривых плагинов для WordPress. Когда вы работаете с обычной, небезопасной версией, то этого никто не замечает. А SSL подобные «шалости» откровенно подчёркивает и заставляет усиленно заботиться о безопасности ресурса.

Дополнительная информация для несчастных пользователей CMS «Битрикс».

Мы вам безусловно сочувствуем. Нет ничего более сложного и корявого, чем этот монстр. Но во многом он неплох, особенно, если коробочная версия вас устраивает. На пути освоения этой мега-платформы вы будете всё время спотыкаться о сучки и коряги, прежде чем сайт заработает как надо. Суждено отдать уйму денег и потратить кучу времени, поэтому, когда в конечном итоге вы поймёте, что необходимо ставить SSL, то ошибочно посчитаете эту затею пустяковой… Не вдаваясь в лирику процесса привожу единственно работающий конфигурационный файл Nginx для Битрикс. Обращаю внимание, на сервере обязательно должен быть установлен php-fpm и корректно работать php5-fpm.sock. Данный конфигурационный файл адаптирован для работы с кривой настройкой сокета и решает большинство проблем возникающих в работе Битрикса через NGINX.

server {
        listen 443;
        ssi on;
        gzip on;
        gzip_comp_level 7;
   gzip_types                      application/x-javascript application/javascript text/css;

        server_name mysite.ru www.mysite.ru;
        charset off;
        index index.php;
        root $root_path;
        set $root_path /var/www/httpdocs;        
        access_log /home/httpd-logs/mysite.ru.access.log ;
        error_log /home/httpd-logs/mysite.ru.error.log notice;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        client_max_body_size 1024M;
        client_body_buffer_size 4M;


        if ($host = 'www.mysite.ru' ) {
              rewrite ^(.*)$ http://mysite.ru$1 permanent;
        }
        location / {
                try_files       $uri $uri/ @bitrix;
        }

        location ~* /upload/.*\.(php|php3|php4|php5|php6|phtml|pl|asp|aspx|cgi|dll|exe|shtm|shtml|fcg|fcgi|fpl|asmx|pht|py|psp|rb|var)$ {
                types {
 text/plain text/plain php php3 php4 php5 php6 phtml pl asp aspx cgi dll exe ico shtm shtml fcg fcgi fpl asmx pht py psp rb var;
                }
        }

        location ~ \.php$ {
                try_files       $uri @bitrix;
                fastcgi_pass    127.0.0.1:9000;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f wm@mysite.ru";
                include fastcgi_params;
        }
        location @bitrix {
                fastcgi_pass    127.0.0.1:9000;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php;
                fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f wm@mysite.ru";
        }
        location ~* /bitrix/admin.+\.php$ {
                try_files       $uri @bitrixadm;
                fastcgi_pass    127.0.0.1:9000;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f wm@mysite.ru";
                include fastcgi_params;
        }
        location @bitrixadm{
                fastcgi_pass    127.0.0.1:9000;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root/bitrix/admin/404.php;
                fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f wm@mysite.ru";
        }

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }
        
        
        location ~* /\.ht  { deny all; }

        location ~* /\.(svn|hg|git) { deny all; }
        
        location ~* ^/bitrix/(modules|local_cache|stack_cache|managed_cache|php_interface) {
          deny all;
        }

        location ~* ^/upload/1c_[^/]+/ { deny all; }
        location ~* /\.\./ { deny all; }
        location ~* ^/bitrix/html_pages/\.config\.php { deny all; }
        location ~* ^/bitrix/html_pages/\.enabled { deny all; }
        location ^~ /upload/support/not_image   { internal; }
        location ~* @.*\.html$ {
          internal;
          expires -1y;
          add_header X-Bitrix-Composite "Nginx (file)";
        }
        location ~* ^/bitrix/components/bitrix/player/mediaplayer/player$ {
          add_header Access-Control-Allow-Origin *;
        }
        location ~* ^/bitrix/cache/(css/.+\.css|js/.+\.js)$ {
          expires 30d;
          error_page 404 /404.html;
        }
        location ~* ^/bitrix/cache              { deny all; }
        location ^~ /upload/bx_cloud_upload/ {
 location ~ ^/upload/bx_cloud_upload/(http[s]?)\.([^/:]+)\.(s3|s3-us-west-1|s3-eu-west-1|s3-ap-southeast-1|s3-ap-northeast-1)\.amazonaws\.com/(.+)$ {
                internal;
                resolver 8.8.8.8;
                proxy_method GET;
                proxy_set_header    X-Real-IP               $remote_addr;
                proxy_set_header    X-Forwarded-For         $proxy_add_x_forwarded_for;
                proxy_set_header    X-Forwarded-Server      $host;
                #proxy_max_temp_file_size 0;
                proxy_pass $1://$2.$3.amazonaws.com/$4;
          }
          location ~* .*$       { deny all; }
        }
		location ~* ^/(upload|bitrix/images|bitrix/tmp) {
        expires 20d;
        }

        location  ~* \.(css|js|gif|png|jpg|jpeg|ico|ogg|ttf|woff|eot|otf)$ {
          error_page 404 /404.html;
          expires 20d;
        }

        location = /404.html {
                access_log off ;
        }
		ssl on;
		ssl_certificate путь к сертификатам;
		ssl_certificate_key путь к сертификатам;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
		ssl_ciphers ALL:!DH:!EXPORT:!RC4:+HIGH:+MEDIUM:!LOW:!aNULL:!eNULL;
}

Важные минусы!

После того, как вы окончательно переберётесь на SSL,необходимо проверить, что сайт корректно индексируется поисковыми системами, это будет заметно, если банально кликать на поисковые результаты выдачи. Если по клику на статью вас будет перекидывать на «главную», то поздравляю, Вам предстоит настраивать 301 редирект и совсем не факт, что всё получится. Есть люди, которые говорят, что истерика с SSL вызвана специально для подогрева рынка сертификатов, но по факту интеграции решения на ряд проектов были выявлены серьёзные уязвимости в ряде популярных плагинов WordPress, стало быть — не всё так плохо.

В качестве послесловия.

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