Различия

Показаны различия между двумя версиями страницы.

@@ Строка 1: / Строка 1: @@
+====== SSL сертификат ======
+~~Title: Что такое SSL сертификат для сайта, почты ~~
+{{htmlmetatags>
+metatag-description=(Что такое SSL-сертификат. Бесплатный SSL сертификат.  Кому нужен SSL-сертификат.)
+}}
+{{ ::http-https-01.png?nolink |}}
+  * Тестирование вашего сертификата [[https://www.ssllabs.com/ssltest/analyze.html|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).
+===== Кому и зачем нужен SSL-сертификат =====
+{{::ssl-01.png?nolink|}}
+Начиная с 2018 года SSL сертификат должен быть установлен на каждом сайте. Если вы запускаете новый сайт, даже это если это просто информационный сайт или блог, на нем должен быть установлен SSL сертификат. В Google наличие или отсутствие SSL сертификата (протокола HTTPS) является одним из факторов ранжирования вашего сайта.
+SSL-сертификат нужен для того, чтобы мошенники не могли перехватить личные данные, которые пользователи вводят у вас на сайте. Личные данные — это логины и пароли от аккаунтов, номера банковских карт, адреса электронной почты и т.д. Это значит, что SSL-сертификат пригодится на сайтах банков, платёжных систем, корпораций, интернет-магазинов, социальных сетей, государственных предприятий, онлайн-форумов и др.
+SSL-сертификат выгоден для владельца сайта: так вы подтвердите, что на сайте безопасно вводить личные данные и проявите заботу о клиентах. Если человек переживает, что конфиденциальная информация попадёт не в те руки, он получит дополнительные гарантии. Меньше риска для пользователей, выше репутация компании.
+===== SSL-сертификат, центр сертификации. =====
+Для работы SSL требуется, чтобы на сервере имелся **SSL-сертификат**. Технология шифрования не зависит от сертификатов, но они необходимы для того, чтобы гарантировать, что общаться друг с другом будут только те хосты, которые действительно намеревались это сделать. Если каждый из хостов может проверить сертификат другого, то они договариваются о шифровании сеанса. В противном случае они полностью отказываются от шифрования и формируют предупреждение, т.к. отсутствует [[аутентичность]].
+**Центр сертификации** или Удостоверяющий центр (англ. Certification authority, CA) — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится центрами сертификации в виде цифровых сертификатов, имеющих следующую структуру:
+    * Серийный номер сертификата;
+    * Объектный идентификатор алгоритма электронной подписи;
+    * Имя удостоверяющего центра;
+    * Срок годности;
+    * Имя владельца сертификата (имя пользователя, которому принадлежит сертификат);
+    * Открытые ключи владельца сертификата (ключей может быть несколько);
+    * Сертификат также содержит полностью определенное имя домена (FQDN [[RFC]] 821) в строке Common Name. Одна из возможных атак - подмена DNS - будет обнаружена до отправки данных.
+==== Виды SSL- сертификатов ====
+**Выделяют различные виды SSL- сертификатов в зависимости от типа проверки:**
+  * Сертификаты с проверкой домена – подтверждают подлинность доменного имени. Не содержат информации о компании.
+  * Сертификаты с проверкой компании – содержат информацию не только о домене, но и о компании, которой выдан сертификат. Пользуются большим доверием у пользователей.
+  * Сертификаты на домен и поддомены (**Wildcard** SSL) – обеспечивают защиту неограниченного количества субдоменов одним сертификатом. Сертификат выдается на определенное доменное имя и при этом защищает все поддомены. Данные сертификаты могут быть как с проверкой домена, так и с проверкой организации.
+  * Сертификаты с расширенной проверкой организации (Extended Validation SSL (EV SSL)) – обеспечивают наивысшее доверие клиентов. Когда пользователь находится на сайте с EV SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.
+<note>Wildcard SSL - сертификаты - это сертификаты, защищающие не только основной домен(ваш_домен.ру), но и поддомены(www.ваш_домен.ру, ssl.ваш_домен.ру, secure.ваш_домен.ру и т.д.). Может использоваться на веб-сервере и почтовом сервере. При генерации запроса на Wildcard сертификат в качестве Common Name (CN) используйте "*.domain.com", где domain.com — это ваше доменное имя.</note>
+===== Бесплатные Центры сертификации =====
+  * **Какой центр сертификации вам нужен?** Все зависит от варианта использования сертификата.
+      * **Частное использование.** Если вы планируете использовать сертификат только для личных целей, когда он нужен только вам или ограниченному числу пользователей (например, сотрудникам вашей компании), то вы можете сами стать для себя центром сертификации.
+      * **Официальное использование.** Если вам надо поддерживать официальные контакты с внешними пользователями и почтовыми серверами, вам придется прибегнуть к услугам официального центра сертификации.
+**Бесплатный сертификат** (центр выдачи сертификатов) должен поддерживаться браузером, иначе проще генерировать самому. Главное сертификат правильно создать. При правильном создании самоподписанного сертификата будет выводится только ошибка он невозможности проверить сертификат, например [[Thunderbird]]: "Верификация сертификата не возможна - выдавшая сертификат сторона ненадежна".
+От сертификата есть польза только если он выдан доверенным центром сертификации(которые встроены в windows) и если он обеспечен обязательствами (обычно от 10.000 у.е.).
+Все остальные сертификаты ничем не отличаются от самоподписанного, который можно сгенерировать самому на любой срок.
+**Бесплатные центры сертификации SSL:**
+    * [[https://dieg.info/review/obzor-regery/|Сервис Regery]] позволяет [[https://to.dieg.info/regerysslru|БЕСПЛАТНО получить]] SSL-сертификаты Regery Free SSL и Sectigo со сроком действия 90 дней. Сертификат предназначен для тестирования технической инфраструктуры до покупки коммерческого SSL-сертификата. Выпуск производится в течение НЕСКОЛЬКИХ МИНУТ.
+    * [[Let’s Encrypt|Let’s Encrypt]] - бесплатный центр сертификации SSL
+    * SSL Welcome to CAcert.org - аналогично предыдущему. Дают сертификаты на год, но браузеры ничего не знают об этом поставщике и ругаются так же как и на самоподписанные сертификаты.
+    * Thawte (основанный, Марком Шаттлвортом и проданный затем компании VeriSign). Предоставляет бесплатные сертификаты для удостоверения электронной почты (но не для SSL). Этот УЦ позаботился о том, чтобы его сертификаты можно было установить в любой системе, кроме того, КС от Thawte предустановлены практически во всех программах, которые работают с цифровыми сертификатами. Если сертификат нужен вам для подписи и шифрования частной почты, бесплатные сертификаты Thawte – лучший выбор. Недостатком Thawte можно назвать то, что при выдаче бесплатных сертификатов не поддерживаются самостоятельно сгенерированные запросы на получение сертификатов, вдобавок Thawte не поддерживает установку сертификатов в Konqueror. Это означает, что для установки бесплатных сертификатов Thawte нужно использовать Firefox или Opera.
+===== Файлы сертификатов X.509 =====
+Получение, выдача, передача и резервное копирование сертификатов и секретных ключей сопровождаются сохранением их данных в специальных файлах. Чаще всего для этого используются файлы со следующими расширениями:
+    * *.cer – сертификат, сохраненный в стандарте CER. Может включать сертификат, секретный ключ, путь сертификации.
+    * *.der – сертификат, сохраненный в стандарте DER. Может включать сертификат, секретный ключ, путь сертификации. Формат который понимает Windows.
+    * *.crt – файл сертификата в формате CER, DER или Netscape.
+    * *.pem – сертификат в кодировке Base64. Может также включать полный путь удостоверения сертификата и секретный ключ.
+    * *.p8 – файл, содержащий секретный ключ, защищенный по стандарту PKCS#8.
+    * *.p12 (в Windows используется расширение *.pfx) – файл сертификата, защищенный по стандарту PKCS#12. Может включать сертификат, секретный ключ, путь сертификации.
+====== Создание и использование самоподписанного (self-signed) SSL сертификата ======
+===== Создание CA -сертификата =====
+<note important>Способ распространения CA -сертификата зависит главным образом от того, в каких приложениях он будет использоваться и каким будет их окружение. GUI - приложения обычно обращаются к корневому хранилищу сертификатов, предоставляемому операционной системой, которая обеспечивает централизованное управление всеми сертификатами. На использующих [[OpenSSL]] серверах, не имеющих другого пользовательского интерфейса, кроме командной строки, **нет единого** централизованного корневого хранилища. Приложения командной строки (например, демон smtpd) могут использовать собственные хранилища, расположение которых должно быть указано в их индивидуальных настройках. </note>
+Если вы решили самостоятельно выпускать сертификаты, то первым делом вам нужно создать сертификат вашего собственного центра сертификации. Для этого используем программу CA.pl входящую в поставку [[OpenSSL]], предварительно отредактируем конфигурационный файл openssl.cnf.
+<code>
+# 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
+.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
+</code>
+===== Postfix SMTP SSL/TSL сертификат =====
+По умолчанию [[SMTP]]-сеанс клиента с сервером не шифруется. Клиент просто устанавливает [[TCP]] - соединение и начинает передачу данных. Если содержимое не было зашифровано другими средствами, оно передается открытым текстом и может быть прочитано (изменено) каждым, кто сможет перехватить поток данных.
+  * **Как работает [[TLS]] на примере SMTP?**
+  * Создадим SSL - сертификат сервера [[Postfix]]. Создаем заявку на сертификат (в последующем заявку нужно подписать в нашем центре сертификации).<code>
+# cd /etc/ssl/
+# openssl req -new -nodes -keyout postfix_private_key.pem -out postfix_private_key.pem -days 3650</code>, где -days: время жизни сертификата;
+  * Последний этап создания серверного сертификата заключается в подписании его центром сертификации. Если вы пользуетесь услугами официального центра, следуйте его инструкциям. В противном случае запустите [[openssl]], чтобы создать файл postfix_public_cert.pem на основе postfix_private_key.pem:<code>
+# openssl ca -policy policy_anything -out postfix_public_cert.pem -infiles postfix_private_key.pem</code>
+<note>Файл postfix_public_cert.pem - это сертификат, который будет выслаться клиентам на начальной стадии установления [[TLS]]-соединения. Вместе с этим сертификатом Postfix будет также высылать подпись из файла postfix_private_key.pem. Хост-получатель при проверке сертификата postfix_public_cert.pem выполнит определенные вычисления на основании подписи, сформированной Postfix с использованием секретного ключа, и подписи в CA-сертификате. Результат должен соответствовать подписи в postfix_public_cert.pem. В случае несовпадения открытый ключ будет признан фальшивым и соединение немедленно завершится.</note>
+  * Подготовим ключи для использования в Posrfix. Скопируем 3 файла в отдельную директорию и установим права.<code>
+# mkdir /etc/ssl/allsslkey
+# chmod 600 postfix_private_key.pem
+</code>
+  * Настройка main.cf в Postfix.<code>
+# 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
+</code>
+  * **Проверка**: имитация TLS-сеанса "почтовый клиент -сервер"<code>
+# openssl s_client -starttls smtp -CApath /etc/ssl/allsslkey/ -connect localhost:25</code>
+====== Quick Postfix SMTP SSL/TSL сертификат ======
+TLS- шифрование трафика предназначено для обеспечения защиты трафика при взаимодействии клиентов, находящихся за пределами доверенных сетей, с нашим сервером, а также при взаимодействии нашего сервера c другими почтовыми серверами. Для TLS-шифрования трафика мы будем использовать функции OpenSSL и самоподписной доверенный сертификат X.509. Для создания самоподписного доверенного сертификата необходимо выполнить команду:
+<code>
+# 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
+</code>
+  * Команда 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:
+<code>
+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
+</code>
+Указанные параметры имеют следующие значения:
+  * 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-команды, если необходима защищенная сессия между клиентом и сервером.
+<note tip>**Отличия портов 25, 465, 587.** По 465 порту соединение сразу должно открываться по TLS/SSL. С 587 работают как с 25: соединение в открытом виде, а для включения шифрования подаётся команда STARTTLS, если сервер заявил о такой возможности в ответ на EHLO от клиента. smtps (465 порт) фича более старая, starttls - более новая и, понятно, более гибкая.</note>
+Для того, чтобы Postfix принимал TLS- соединения на специальный порт (465/SMTPS, а не 25/SMTP), в файле /usr/local/etc/postfix/master.cf необходимо раскомментировать строки:
+<code>
+smtps inet n - n - - smtpd
+  -o smtpd_tls_wrappermode=yes
+  -o smtpd_sasl_auth_enable=yes
+</code>
+Не забудьте, что Ваш брандмауэр должен разрешать прохождение TCP-трафика на адреса нужных интерфейсов сервера порт 465, поэтому добавьте соответствующие правила, если они отсутствуют. На этом добавление поддержки TLS-шифрования трафика к Postfix заканчивается. Остается перезапустить Postfix и начать пользоваться аутентификацией SMTP и TLS-шифрованием трафика.
+====== Quick Dovecot SSL сертификат ======
+<code>
+# 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
+</code>
+Правим конфигурационный файл [[Dovecot]].
+<code>
+# 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
+...
+</code>
+Вывести все доступные сертификаты
+<file>
+openssl s_client -connect 10.26.95.225:443 -showcerts
+</file>
+====== Quick Apache2 самоподписанный SSL сертификат ======
+[[mod_gnutls]]: Позволяет на разные виртуальные домены устанавливать разные SSL сертификаты.
+  * Включаем модуль ssl и файл с настройками HTTPS по умолчанию<file bash>
+a2enmod ssl
+a2ensite default-ssl
+</file>
+  * Создадим самоподписанные SSL сертификаты (можно оставить по умолчанию сгенерированные системой: ssl-cert-snakeoil.pem)<code bash>
+mkdir /etc/apache2/certs
+cd /etc/apache2/certs/
+openssl req -new -nodes -x509 -out httpsd.pem -keyout httpsd.pem -days 9999
+</code>
+  * Теперь необходимо отредактировать файл с настройками HTTPS сайта по умолчанию: /etc/apache2/sites-enabled/default-ssl.conf<code bash>
+<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>
+</code>
+====== Создание самоподписанного SSl сертификата для Nginx ======
+Создадим и подключим самоподписанный SSL сертификат в [[Nginx|Nginx]].
+Создадим папку где будем хранить сертификаты:
+<file bash>
+mkdir /etc/nginx/ssl
+chown root:root /etc/nginx/ssl
+chmod 700 /etc/nginx/ssl
+</file>
+Перейдем в эту папку и сгенерируем сертификат:
+<file bash>
+cd /etc/nginx/ssl
+openssl req -new -x509 -days 9999 -nodes -newkey rsa:2048 -out nginx.pem -keyout nginx.key
+</file>
+При генерации вас попросят указать некоторые данные, так как мы создаем сертификат для себя то заполнять их не обязательно. Настроим использование одного самоподписанного сертификата для нескольких сайтов.
+ Теперь для конфигурации хоста с поддержкой шифрования будем использовать следующий шаблон:
+<file bash>
+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;
+    ...
+}
+</file>
+ таким образом можно работать как по HTTP так и HTTPS
+Пример с принудительным использованием HTTPS:
+<file bash>
+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;
+    ...
+}
+</file>

📌 Удобный подбор VPS по параметрам доступен на DIEGfinder.com - официальном инструменте проекта DIEG. Это часть единой экосистемы, созданной для того, чтобы помочь быстро найти подходящий VPS/VDS сервер для любых задач хостинга.

📌 Для тестирования скриптов, установщиков VPN и Python-ботов рекомендуем использовать надежные VPS на короткий срок. Подробнее о быстрой аренде VPS для экспериментов - читайте здесь.

💥 Подпишись в Телеграм 💥 и задай вопрос по сайтам и хостингам бесплатно!

Различия

7 Самых Популярных Статей

7 Самых Популярных Обзоров