Содержание

SSL сертификат

SSL (Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причем для шифрования используется асимметричный алгоритм с открытым ключом. При шифровании с открытым ключом используется два ключа, причем любой из них может использоваться для шифрования сообщения. Тем самым, если мы используем один ключ для шифрования, то соответственно для расшифровки нужно использовать другой ключ. В такой ситуации мы можем получать защищенные сообщения, публикуя открытый ключ, и храня в тайне секретный ключ.

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

SSL поддерживает три типа аутентификации: Аутентификация обеих сторон (клиент — сервер), аутентификация сервера с неаутентифицированным клиентом и полная анонимность. Всякий раз, когда сервер аутентифицируется, канал безопасен против атаки человек посредине, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». При посылке верного сообщения «finished», тем самым стороны докажут что они знают верный секрет (pre_master_secret).

Кому и зачем нужен SSL-сертификат

Начиная с 2018 года SSL сертификат должен быть установлен на каждом сайте. Если вы запускаете новый сайт, даже это если это просто информационный сайт или блог, на нем должен быть установлен SSL сертификат. В Google наличие или отсутствие SSL сертификата (протокола HTTPS) является одним из факторов ранжирования вашего сайта.

SSL-сертификат нужен для того, чтобы мошенники не могли перехватить личные данные, которые пользователи вводят у вас на сайте. Личные данные — это логины и пароли от аккаунтов, номера банковских карт, адреса электронной почты и т.д. Это значит, что SSL-сертификат пригодится на сайтах банков, платёжных систем, корпораций, интернет-магазинов, социальных сетей, государственных предприятий, онлайн-форумов и др.

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

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

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

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

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

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

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

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

Бесплатный сертификат (центр выдачи сертификатов) должен поддерживаться браузером, иначе проще генерировать самому. Главное сертификат правильно создать. При правильном создании самоподписанного сертификата будет выводится только ошибка он невозможности проверить сертификат, например Mozilla Thunderbird почта: "Верификация сертификата не возможна - выдавшая сертификат сторона ненадежна".

От сертификата есть польза только если он выдан доверенным центром сертификации(которые встроены в windows) и если он обеспечен обязательствами (обычно от 10.000 у.е.). Все остальные сертификаты ничем не отличаются от самоподписанного, который можно сгенерировать самому на любой срок.

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

Файлы сертификатов X.509

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

Создание и использование самоподписанного (self-signed) SSL сертификата

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

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

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

# cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.orig
# nano openssl.cnf
...
[ CA_default ]

dir             = ./demoCA
# cacert.pem- Это открытый ключ центра сертификации. Он должен находиться в корневых хранилищах ваших хостов,
# чтобы они могли проверить родпись в открытом сертификате (например, Postfix).
certificate     = $dir/cacert.pem
# cakey.pem - это секретный ключ центра сертификации. Он должен быть хорошо защищен,
# доступ к нему на чтение и запись должен иметь только администратор центра сертификации.
private_key     = $dir/private/cakey.pem
# Время жизни сертификата (по умолчанию 1 год)
default_days    = 1095
[ req ]
# длина RSA ключа (по умолчанию 1024 bit). Длину ключа можете настроить по своему усмотрению.
default_bits            = 1024
[ req_distinguished_name ]
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

Postfix SMTP SSL/TSL сертификат

По умолчанию SMTP — простой протокол передачи почты-сеанс клиента с сервером не шифруется. Клиент просто устанавливает Порты TCP. Что такое TCP / IP порт - соединение и начинает передачу данных. Если содержимое не было зашифровано другими средствами, оно передается открытым текстом и может быть прочитано (изменено) каждым, кто сможет перехватить поток данных.

Файл postfix_public_cert.pem - это сертификат, который будет выслаться клиентам на начальной стадии установления TLS-соединения. Вместе с этим сертификатом Postfix будет также высылать подпись из файла postfix_private_key.pem. Хост-получатель при проверке сертификата postfix_public_cert.pem выполнит определенные вычисления на основании подписи, сформированной Postfix с использованием секретного ключа, и подписи в CA-сертификате. Результат должен соответствовать подписи в postfix_public_cert.pem. В случае несовпадения открытый ключ будет признан фальшивым и соединение немедленно завершится.

Quick Postfix SMTP SSL/TSL сертификат

TLS- шифрование трафика предназначено для обеспечения защиты трафика при взаимодействии клиентов, находящихся за пределами доверенных сетей, с нашим сервером, а также при взаимодействии нашего сервера c другими почтовыми серверами. Для TLS-шифрования трафика мы будем использовать функции OpenSSL и самоподписной доверенный сертификат X.509. Для создания самоподписного доверенного сертификата необходимо выполнить команду: 

# mkdir /etc/postfix/certs
# cd /etc/postfix/certs
# openssl req -new -nodes -x509 -out smtpd.pem -keyout smtpd.pem -days 3650
# chmod 644 smtpd.pem

В процессе выполнения команды на экран будут выданы запросы о вводе таких параметров как: Country Name, State or Province Name; Locality Name; Organization Name; Organizational Unit Name; Common Name; Email Address. Самым важным параметром является значение Common Name. В нашем случае оно должно совпадать с FQDN сервера, по которому клиенты будут обращаться к нему для отправки почты. Чтобы не вводить эти данные вручную каждый раз при создании сертификата можно отредактировать файл /etc/ssl/openssl.cnf.

После генерации сертификата необходимо включить поддержку TLS в файле main.cf: 

smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_auth_only = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_cert_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_CAfile = /etc/postfix/certs/smtpd.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Указанные параметры имеют следующие значения:

Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты - 25 или 587. Спецификации и многие сервера поддерживают и тот, и другой порты. Хотя некоторые сервера поддерживают порт 465 для безопасного SMTP, но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищенная сессия между клиентом и сервером.

Отличия портов 25, 465, 587. По 465 порту соединение сразу должно открываться по TLS/SSL. С 587 работают как с 25: соединение в открытом виде, а для включения шифрования подаётся команда STARTTLS, если сервер заявил о такой возможности в ответ на EHLO от клиента. smtps (465 порт) фича более старая, starttls - более новая и, понятно, более гибкая.

Для того, чтобы Postfix принимал TLS- соединения на специальный порт (465/SMTPS, а не 25/SMTP), в файле /usr/local/etc/postfix/master.cf необходимо раскомментировать строки: 

smtps inet n - n - - smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

Не забудьте, что Ваш брандмауэр должен разрешать прохождение TCP-трафика на адреса нужных интерфейсов сервера порт 465, поэтому добавьте соответствующие правила, если они отсутствуют. На этом добавление поддержки TLS-шифрования трафика к Postfix заканчивается. Остается перезапустить Postfix и начать пользоваться аутентификацией SMTP и TLS-шифрованием трафика.

Quick Dovecot SSL сертификат

# mkdir /etc/dovecot/certs
# cd /etc/dovecot/certs
# openssl req -new -nodes -x509 -out imapd.pem -keyout imapd.pem -days 3650
# chmod 644 imapd.pem

Правим конфигурационный файл Настройка сервера Dovecot и Postfix. 

# nano /etc/dovecot/dovecot.conf
...
## SSL settings
ssl_cert_file = /etc/dovecot/certs/imapd.pem
ssl_key_file = /etc/dovecot/certs/imapd.pem
ssl_ca_file = /etc/dovecot/certs/imapd.pem
...

Вывести все доступные сертификаты 

openssl s_client -connect 10.26.95.225:443 -showcerts

Quick Apache2 самоподписанный SSL сертификат

Apache mod_gnutls: Позволяет на разные виртуальные домены устанавливать разные SSL сертификаты.

Создание самоподписанного SSl сертификата для Nginx

Создадим и подключим самоподписанный SSL сертификат в Nginx.

Создадим папку где будем хранить сертификаты: 

mkdir /etc/nginx/ssl
chown root:root /etc/nginx/ssl
chmod 700 /etc/nginx/ssl

Перейдем в эту папку и сгенерируем сертификат: 

cd /etc/nginx/ssl
openssl req -new -x509 -days 9999 -nodes -newkey rsa:2048 -out nginx.pem -keyout nginx.key

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

server {
    listen          *:80;
    listen          *:443 ssl;
    server_name     my.site.com;
 
#    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2; # SSLv3 исключить CVE-2014-3566
    ssl_certificate	/etc/nginx/ssl/nginx.pem;
    ssl_certificate_key	/etc/nginx/ssl/nginx.key;
 
    ...
}

таким образом можно работать как по HTTP так и HTTPS

Пример с принудительным использованием HTTPS: 

server {
    listen          *:80;
    server_name     my.site.com;    
    rewrite ^ https://$host$request_uri? permanent;
}
 
server {
    listen          *:443 ssl;
    server_name     my.site.com;
 
    ssl			on;
#    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2; # SSLv3 исключить CVE-2014-3566
    ssl_certificate	/etc/nginx/ssl/nginx.pem;
    ssl_certificate_key	/etc/nginx/ssl/nginx.key;
 
    ...
}