• Тестирование вашего сертификата SSL Server Test

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).

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

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

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

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

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

• Серийный номер сертификата;
• Объектный идентификатор алгоритма электронной подписи;
• Имя удостоверяющего центра;
• Срок годности;
• Имя владельца сертификата (имя пользователя, которому принадлежит сертификат);
• Открытые ключи владельца сертификата (ключей может быть несколько);

• Сертификат также содержит полностью определенное имя домена (FQDN RFC 821) в строке Common Name. Одна из возможных атак - подмена DNS - будет обнаружена до отправки данных.

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

• Сертификаты с проверкой домена – подтверждают подлинность доменного имени. Не содержат информации о компании.
• Сертификаты с проверкой компании – содержат информацию не только о домене, но и о компании, которой выдан сертификат. Пользуются большим доверием у пользователей.
• Сертификаты на домен и поддомены (Wildcard SSL) – обеспечивают защиту неограниченного количества субдоменов одним сертификатом. Сертификат выдается на определенное доменное имя и при этом защищает все поддомены. Данные сертификаты могут быть как с проверкой домена, так и с проверкой организации.
• Сертификаты с расширенной проверкой организации (Extended Validation SSL (EV SSL)) – обеспечивают наивысшее доверие клиентов. Когда пользователь находится на сайте с EV SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.

• Какой центр сертификации вам нужен? Все зависит от варианта использования сертификата.
  • Частное использование. Если вы планируете использовать сертификат только для личных целей, когда он нужен только вам или ограниченному числу пользователей (например, сотрудникам вашей компании), то вы можете сами стать для себя центром сертификации.
  • Официальное использование. Если вам надо поддерживать официальные контакты с внешними пользователями и почтовыми серверами, вам придется прибегнуть к услугам официального центра сертификации.

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

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

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

• Сервис Regery позволяет БЕСПЛАТНО получить SSL-сертификаты Regery Free SSL и Sectigo со сроком действия 90 дней. Сертификат предназначен для тестирования технической инфраструктуры до покупки коммерческого SSL-сертификата. Выпуск производится в течение НЕСКОЛЬКИХ МИНУТ.
• Let’s Encrypt - бесплатный центр сертификации SSL
• SSL Welcome to CAcert.org - аналогично предыдущему. Дают сертификаты на год, но браузеры ничего не знают об этом поставщике и ругаются так же как и на самоподписанные сертификаты.
• Thawte (основанный, Марком Шаттлвортом и проданный затем компании VeriSign). Предоставляет бесплатные сертификаты для удостоверения электронной почты (но не для SSL). Этот УЦ позаботился о том, чтобы его сертификаты можно было установить в любой системе, кроме того, КС от Thawte предустановлены практически во всех программах, которые работают с цифровыми сертификатами. Если сертификат нужен вам для подписи и шифрования частной почты, бесплатные сертификаты Thawte – лучший выбор. Недостатком Thawte можно назвать то, что при выдаче бесплатных сертификатов не поддерживаются самостоятельно сгенерированные запросы на получение сертификатов, вдобавок Thawte не поддерживает установку сертификатов в Konqueror. Это означает, что для установки бесплатных сертификатов Thawte нужно использовать Firefox или Opera.

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

• *.cer – сертификат, сохраненный в стандарте CER. Может включать сертификат, секретный ключ, путь сертификации.
• *.der – сертификат, сохраненный в стандарте DER. Может включать сертификат, секретный ключ, путь сертификации. Формат который понимает Windows.
• *.crt – файл сертификата в формате CER, DER или Netscape.
• *.pem – сертификат в кодировке Base64. Может также включать полный путь удостоверения сертификата и секретный ключ.
• *.p8 – файл, содержащий секретный ключ, защищенный по стандарту PKCS#8.
• *.p12 (в Windows используется расширение *.pfx) – файл сертификата, защищенный по стандарту PKCS#12. Может включать сертификат, секретный ключ, путь сертификации.

Если вы решили самостоятельно выпускать сертификаты, то первым делом вам нужно создать сертификат вашего собственного центра сертификации. Для этого используем программу 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

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

• Как работает TLS на примере SMTP?
• Создадим SSL - сертификат сервера Настройка почтового сервера Postfix. Создаем заявку на сертификат (в последующем заявку нужно подписать в нашем центре сертификации).

  # cd /etc/ssl/
  
  # openssl req -new -nodes -keyout postfix_private_key.pem -out postfix_private_key.pem -days 3650

  , где -days: время жизни сертификата;

• Последний этап создания серверного сертификата заключается в подписании его центром сертификации. Если вы пользуетесь услугами официального центра, следуйте его инструкциям. В противном случае запустите Как пользоваться OpenSSL, чтобы создать файл postfix_public_cert.pem на основе postfix_private_key.pem:

  # openssl ca -policy policy_anything -out postfix_public_cert.pem -infiles postfix_private_key.pem

• Подготовим ключи для использования в Posrfix. Скопируем 3 файла в отдельную директорию и установим права.

  # mkdir /etc/ssl/allsslkey
  # chmod 600 postfix_private_key.pem

• Настройка main.cf в Postfix.

  # nano /etc/postfix/main.cf
  ...
  # Включить TLS
  smtpd_use_tls=yes
  smtpd_tls_key_file = /etc/postfix/certs/postfix_private_key.pem
  smtpd_tls_cert_file = /etc/postfix/certs/postfix_public_cert.pem
  #путь к хранилищам сертификатов
  smtpd_tls_CApath = /etc/ssl/certs
  #loglevel to mail.log
  smtpd_tls_loglevel = 2
  #Добавляет информацию в заголовок Received каждого письма
  smtpd_tls_received_header = yes

• Проверка: имитация TLS-сеанса "почтовый клиент -сервер"

  # openssl s_client -starttls smtp -CApath /etc/ssl/allsslkey/ -connect localhost:25

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

• Команда req заставляет OpenSSL создать сертификат, ключи:
• -new - cоздать запрос на сертификат,
• -nodes - не шифровать закрытый ключ,
• -x509 (совместно с -new) - создать самоподписной сертификат,
• -keyout - задает местонахождение закрытого ключа,
• -out - задает местонахождение самоподписного сертификата,
• -days - задает время действия сертификата (365x10 дней, что приблизительно равно десяти годам).

В процессе выполнения команды на экран будут выданы запросы о вводе таких параметров как: 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

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

• smtp_use_tls - использовать TLS, если удаленный сервер сообщает о поддержке TLS,
• smtpd_use_tls - сообщать клиентам о поддержке TLS,
• smtpd_tls_auth_only - использовать аутентификацию SMTP только для TLS-соединений,
• smtp_tls_note_starttls_offer - фиксировать в логе имена серверов, выдающих сообщение STARTTLS, поддержка TLS для которых не включена,
• smtpd_tls_key_file - местонахождение закрытого ключа сервера,
• smtpd_tls_cert_file - местонахождение сертификата сервера,
• smtpd_tls_CAfile - местонахождение самоподписного доверенного сертификата,
• smtpd_tls_CApath - место нахождение всех корневых сертификатов, для проверки клиентов
• smtpd_tls_loglevel - детальность сообщений о TLS-активности, выводимых в лог,
• smtpd_tls_received_header - запрашивать заголовки сообщений с информацией о версии протокола и алгоритме шифрования,
• smtpd_tls_session_cache_timeout - время, в течение которого данные в кэше TLS-сессии считаются актуальными,
• tls_random_source - имя устройства-генератора псевдослучайных чисел (PRNG).
• smtpd_tls_ask_ccert - устраняет ошибку No client certificate requested

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

Для того, чтобы 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-шифрованием трафика.

# 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

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

• Включаем модуль ssl и файл с настройками HTTPS по умолчанию

  a2enmod ssl
  a2ensite default-ssl

• Создадим самоподписанные SSL сертификаты (можно оставить по умолчанию сгенерированные системой: ssl-cert-snakeoil.pem)

  mkdir /etc/apache2/certs
  cd /etc/apache2/certs/
  openssl req -new -nodes -x509 -out httpsd.pem -keyout httpsd.pem -days 9999

• Теперь необходимо отредактировать файл с настройками HTTPS сайта по умолчанию: /etc/apache2/sites-enabled/default-ssl.conf

  <VirtualHost *:443>
  ...
  ## SSL settings
   
          SSLEngine on
  # запретить использование устаревшего протокол SSLv2 и SSLv3
          SSLProtocol all -SSLv2 -SSLv3
  # или запретить можно запретить все и включить только требуемые
  #SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
   
          SSLCertificateFile /etc/apache2/certs/httpsd.pem          
          SSLCertificateKeyFile /etc/apache2/certs/httpsd.pem
  #                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
  #                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
   
  ...
  </VirtualHost>

Создадим и подключим самоподписанный 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;
 
    ...
}