Установка и настройка mod_ssl в Apache на CentOS 5,6, получение SSL сертификата.

ssl-128-bit-encryption Если мы хотим чтобы наш сайт на Apache в CentOS 5,6 не похакали сниферофилы и прочие мазакакеры, то нам просто необходимо поприкрывать все, так сказать, слабые места, а также поставить и настроить mod_ssl, получить SSL сертификат для веб сервера.

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

СБУ хочет, чтобы провайдеры хранили данные о пользователях 90 дней

Украинский закон «О телекоммуникациях» не позволяет бороться с киберпреступностью в полной мере. Такое мнение на съезде Интернет ассоциации Украины высказал руководитель подразделения СБУ Валентин Петров.

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

Как обычно под предлогом борьбы с преступностью, борьба реально будет вестись с бизнесом и политически неугодными индивидами путём перехвата и дальнейшего анализа их Интернет трафика (корпоративной почты, посещённых сайтов и пр.). Как там у В. Леонтьева: "Каждый хочет иметь и невесту и друга..."

Или к примеру просто админ сети будет местами шутить, так например вычленит из трафика данные административного акаунта от посещаемого тобой сайта, удалит весь контент с сайта, а вместо него напишет АДМИН ЛОХ!:) или что-то в таком духе. В некоторых вопросах АДМИН конечно ЛОХ но, не до такой же степени, чтобы упустить возможность организации безопасного HTTPS (SSL) соединения с веб сервером Apache для администрирования веб ресурса!:)

Установка mod_ssl и openssl

Для организации безопасного HTTPS (SSL) соединения с веб сервером Apache нам потребуется Apache модуль mod_ssl и собственно сам openssl для создания корневого сертификата и сертификата сервера. Проверим наличие в системе mod_ssl и openssl:

yum list installed | grep mod_ssl
yum list installed | grep openssl

Если mod_ssl и openssl не установлен, то устанавливаем:

yum install mod_ssl
yum install openssl

Самоподписной SSL сертификат сервера Apache

mod_ssl подключается и настраивается через конфигурационный файл /etc/httpd/conf.d/ssl.conf. По умолчанию SSLCertificateFile /etc/pki/tls/certs/localhost.crt и SSLCertificateKeyFile /etc/pki/tls/private/localhost.key уже присутствуют в системе, но желательно бы сгенерировать свой собственный:

openssl genrsa -out ca.key 1024
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 99999 -in ca.csr -signkey ca.key -out ca.crt
mv ca.crt /etc/pki/tls/certs
mv ca.key /etc/pki/tls/private/ca.key
mv ca.csr /etc/pki/tls/private/ca.csr

На первом шаге мы создали RSA-ключ нашего сервера, которым на следующем шаге будет подписан так званый CSR (сertificate signing request - запрос на получение сертификата) файл. .csr файл будет в себе содержать информацию о владельце сертификата, которую openssl попросит указать задавая вопросы:

sh-4.1# openssl req -new -key ca.key -out ca.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:UA
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:Kiev
Organization Name (eg, company) [Default Company Ltd]:Windows Remote Shaman
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server hostname) []:remoteshaman.com
Email Address []:support@remoteshaman.com
Please enter the following extra attributes
to be sent with your certificate request
A challenge password []:???
string is too long, it needs to be less than 20 bytes long
A challenge password []:???
An optional company name []:WRS

На третьем этапе мы создаём и подписываем себе свой SSL сертификат. Нужно учесть, что созданный ранее RSA-ключ, которым был подписан CSR запрос, является уникальным. Потеряв RSA-ключ, мы сможем сгенерировать новый, но с новым ключом наш сертификат уже будет недействителен. Сохраните RSA-ключ в надежном месте (создайте его резервную копию).

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

Сам RSA-ключ является обычным текстовым файлом и содержит в себе примерно такие строки:

-----BEGIN RSA PRIVATE KEY-----
MIICXgIKJ0de98yf98ytguQwYbq1Yf177CBSPVSyl+oMPvc7QKzimldewAosMkcR
BQo/02IbIrZsHw2YHL5+EuxZr0RsdgrewhgrWKa3FWQh00XBDEQCGKQSVAqFyi2J
Bb47nJ5nGfWfetRf33hYlRqN2CluH7uU02qV0fbgd4yjtre4e3Ddp7FblQIDAQAB
R1a/fwOWIhkKGoLAlKPxhgd457659igjgl8o4C+V2Nv/LNDW8nk6qF1/fZ9JLdld
m7vBJRoosa44yfjyu7ik67jng7JjjuqX3ae+Bg4/DFzJh/qyLBwwMHrlnicLxXUL
3w8f+a4t/R4vmh5Pqlep5IorWWfwhNIO2MODfzcN8XeApA==
-----END RSA PRIVATE KEY-----

Важную роль в этом файле играют первая и последняя строки "-----BEGIN RSA PRIVATE KEY-----" и "-----END RSA PRIVATE KEY-----", где должно быть строго по пять тире. Никогда НЕ исправляйте этот файл в текстовом редакторе вручную.

Теперь обновите конфигурационный файл Apache SSL: vi +/SSLCertificateFile /etc/httpd/conf.d/ssl.conf

Измените полный путь, где хранится новый сертификат: SSLCertificateFile /etc/pki/tls/certs/ca.crt

Установите верный путь к файлу ключа сертификата: SSLCertificateKeyFile /etc/pki/tls/private/ca.key

Для добавления безопасной HTTPS (SSL) версии сайта для виртуального хоста Apache, нужно в его конфиг файле, например vi /etc/httpd/conf.v/wrs.conf, подправить секцию <VirtualHost *:81>...</VirtualHost>, и модифицировать её до такого состояния:

<VirtualHost *:81 *:443>
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/ca.crt
    SSLCertificateKeyFile /etc/pki/tls/private/ca.key
    ....
</VirtualHost>

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

sh-4.1# httpd -t
[Sat Nov 03 08:01:34 2012] [warn] _default_ VirtualHost overlap on port 443, the
first has precedence
Syntax OK
sh-4.1# vi /etc/httpd/conf/httpd.conf
NameVirtualHost *:443
sh-4.1# httpd -t
Syntax OK
service httpd restart

Запуск Apache без ввода пароля для SSL ключа .key

Если вы создавали приватный SSL ключ с его шифрованием openssl genrsa -des3 -out ca.key 2048 и задавали парольную фразу (от 4 до 8191 символов), то при каждом старте/перезапуске веб-сервера будет запрашиваться пароль для приватного SSL ключа .key

Для того чтобы указать веб-серверу путь к файлу пароля от SSL ключа .key делаем:

mkdir /usr/local/etc/rc.d/
cd /usr/local/etc/rc.d/
vi startssl.pl
#!/usr/bin/perl
print "<пароль для SSL ключа .key сертификата сервера >\n";
chmod 550 startssl.pl

Потом в httpd.conf или в ssl.conf пишем: SSLPassPhraseDialog exec:/usr/local/etc/rc.d/startssl.pl

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

openssl rsa -in ca.key -out ca.pem
rm -f ca.key
mv ca.pem ca.key

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

Бесплатный самоподписной SSL сертификат созданный нами ранее подойдёт для нашего персонального сайта, при этом пытаясь посетить сайт на котором организовано безопасное HTTPS (SSL) соединение с самоподписным SSL сертификатом для сервера Apache, пользователь получит в браузер предупреждение о том, что сертификат не является действительным и безопасное HTTPS (SSL) соединение может быть не установлено.

В таких случаях обычно нужно или внести сертификат в исключения браузера, или установить SSL сертификат вручную, для чего обычно достаточно ввести в адресную строку браузера путь к сертификату и открыть его в браузере. Но в браузере Опера 11.64 даже после установки SSL сертификата, при попытке посетить сайт через https://, в данных о странице будет указанно "Незащищённое соединение", "Серверу не удалось принять меры безопасности." и не ясно, толи соединение вовсе незащищённое, толи соединение защищено частично? Такое загадочное поведение Опера 11.64 характерно для веб-страниц в которые включены сторонние элементы, такие как счётчики, рисунки, скрипты и пр., а если на странице нет сторонних элементов, то слева в адресной строке красуется значок замка с надписью "Безопасный" - конечно если SSL сертификат установлен. Примерно так же ведёт себя и Internet Explorer 8.

В опере можно попробовать снять галку с "opera:config -> Security Prefs -> OCSP Validate Certificates". У браузеров "Chrome" и "FireFox" поведение иное и если на странице присутствуют иные сторонние элементы, которые загружаются со сторонних незащищённых серверов, то в "Chrome" и "FireFox" указывается, что используется частично безопасное HTTPS (SSL) соединение.

Для избавления от всех этих манипуляций в Сети Интернет можно попытаться раздобыть бесплатный доверенный SSL сертификат для веб сервера. Обычно такие раздачи бесплатных доверенных SSL сертификатов имеют кратковременный характер (выдаются на 30-365 дней) и придуманы для привлечения клиентов. После истечении срока действия SSL сертификата от авторитетного/доверенного поставщика, он ничем не отличается от самоподписанного.

Список доверенных поставщиков бесплатных SSL сертификатов, у которых можно получить бесплатный доверенный SSL сертификат для веб сервера сроком на 30-365 дней:

  • freessl.su - срок от 30 до 90 дней, поставщик COMODO;
  • instantssl.com - Срок 90 дней, поставщик COMODO;
  • ipsca.com - срок 90 дней, поставщик IpsCA;
  • trustico.eu - срок 30 дней, поставщик GeoTrust;
  • rapidssl.com - срок 30 дней, поставщик - они же - RapidSSL;
  • verisign.com - cрок 14 дней, сертификаты не авторизованные (не стоило бы и упоминать);
  • globalsign.com - срок 30 и 45 дней, поставщики - они же - GlobalSign Inc;
  • ssl.com - срок 30 дней, поставщик COMODO;
  • startssl.com - выдает сертификаты на 1 год от StartCom, на сайте поставщика отмечено что, "Many software vendors like Mozilla (Firefox) and Apple (Safari) provide built-in support of the StartCom Certification Authority";
  • cacert.org - как и предыдущий, даёт сертификат сроком на один год, но веб-браузеры ничего не знают о нём (InclusionStatus - CAcert Wiki) и так же ругаются как и на самоподписанные сертификаты.

Купить SSL сертификат будет стоить где-то минимум 60-80 у.е. в год но, вполне можно обойтись самоподписанным сертификатом и дать пользователям своего сайта соответствующие пояснения и детальную инструкцию по его установке.

Настройка брандмауэра iptables

Последнее, что осталось сделать - это открыть доступ к 443-му порту в брандмауэре. Просмотрите список правил iptables -L -v, и если в цепочке Chain INPUT ... последним стоит всё запрещающее правило, то его нужно удалить перед добавлением разрешающего. Для удаления последнего правила iptables используйте iptables -D INPUT ?, где знак вопроса "?" это номер последнего правила iptables - отсчёт сверху в низ начиная с 1.

Добавим в брандмауэре iptables разрешающее правило для 443-го порта и сохраним изменения:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
service iptables save
service iptables restart
iptables -L -v

SSL (HTTPS) на нескольких виртуальных хостах

mod_ssl не даёт возможности реализовать несколько name based SSL виртуальных хостов на одном IP адресе, точнее, несколько виртуальных SSL хостов на одном IP можно реализовать, но SSL сертификат на все виртуальные хосты будет один, что не есть гуд. При попытке использовать несколько виртуальных SSL хостов на одном IP в /var/log/httpd/error_log всегда будем получать предупреждения:

[Mon Nov 05 08:01:02 2012] [warn] Init: SSL server IP/port conflict: 
localhost:4
43 (/etc/httpd/conf.v/default.conf:3) vs. myhost.name:443 (/etc/httpd/conf.v/
myhost.conf:2)
[Mon Nov 05 08:01:02 2012] [warn] Init: You should not use name-based virtual ho
sts in conjunction with SSL!!

Эти предупреждения не есть критично, но как упоминалось ранее SSL сертификат на все виртуальные хосты будет один. "Гениальные" предположения типа дополнительно использовать NameVirtualHost myhost.name:443, указывать имя виртуального хоста в секции <VirtualHost myhost.name:443>...</VirtualHost> приводят к полному беспределу и ошибкам типа:

Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Hint: https://remoteshaman.com/
------------------
Starting httpd: [Tue Nov 06 07:51:34 2012] [error] VirtualHost myhost.name:81
-- mixing * ports and non-* ports with a NameVirtualHost address is not support
ed, proceeding with undefined results
[Tue Nov 06 07:51:34 2012] [error] VirtualHost myhost.name:443 -- mixing * po
rts and non-* ports with a NameVirtualHost address is not supported, proceeding
with undefined results
[Tue Nov 06 07:51:34 2012] [error] VirtualHost 94.249.240.244:81 -- mixing * por
ts and non-* ports with a NameVirtualHost address is not supported, proceeding w
ith undefined results
------------------
Starting httpd: [Tue Nov 06 07:55:44 2012] [warn] NameVirtualHost myhost.name
:81 has no VirtualHosts
[Tue Nov 06 07:55:44 2012] [warn] NameVirtualHost myhost.name:443 has no Virt
ualHosts

На странице фака SSL/TLS Strong Encryption: FAQ - Apache HTTP Server, кроме использования разных IP, предлагается использовать разные порты, но это тоже не есть оптимальный выход - для каждого хоста писать Listen 444, Listen 445 и т.д., добавлять правило в iptables для порта или диапазона портов, а пользователю ручками вбивать в браузер номер порта или делать для него редирект.

Для реализации SSL (HTTPS) на одном IP и для нескольких виртуальных хостов одновременно с разными SSL сертификатами нужно использовать такой чудо-модуль как mod_gnutls на библиотеке GnuTLS, который можно применить только для апачей выше версии 2.0.42.

Для компиляции mod_gnutls в системе должны быть установлены пакеты httpd-devel и gnutls-devel, подробную инструкцию по компиляции и установке mod_gnutls можно найти здесь >>>

Заключение

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

Как видим В. Леонтьев был прав: "Каждый хочет иметь и невесту и друга...", а чтобы нас не поимели в сети Интернет мы должны всегда использовать только безопасные HTTPS (SSL) независимо от типа соединения (HTTP, POP, SMTP и т.д.), если есть такая возможность

Ссылки по теме:

Олег Головский


Комментарии   

Арсений Яковлевич
0 #2 Арсений Яковлевич 14.03.2013 16:29
Цитирую murz:
статья хорошая, но не могли бы добавить пункт, настройки доступа по клиентским сертификатам, с настройкой httpd.

Ну, так не особо хитрое дело! Всего несколько строк сменить и делов то: "Авторизация с помощью клиентских SSL сертификатов. (ssl crypt mod_ssl apache)" - http://www.opennet.ru/base/sec/ssl_cert.txt.html
Цитировать
murz
0 #1 murz 14.03.2013 12:01
статья хорошая, но не могли бы добавить пункт, настройки доступа по клиентским сертификатам, с настройкой httpd.
Цитировать

Добавить комментарий


Защитный код
Обновить

2 megabytes