Комментарии 60
А затем идём на www.ssllabs.com/ и проверяем что же нам скажет сей сервис. Overall Rating — C.
Меняем протоколы на:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
А ssl_ciphers выбираем отсюда: wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
Меняем протоколы на:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
А ssl_ciphers выбираем отсюда: wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
Тут много что неправильно. Вот наилучшая возможная конфигурация nginx с объяснениями на GitHub Gist, а вот результат теста таких настроек — оценка A+.
А вот статья и видео с YAC 2014 от Эльдара Заитова, он простыми словами и безумно интересно рассказывает, что же происходит на уровне пониже, когда вы заходите на сайт с использованием HTTPS.
А вот статья и видео с YAC 2014 от Эльдара Заитова, он простыми словами и безумно интересно рассказывает, что же происходит на уровне пониже, когда вы заходите на сайт с использованием HTTPS.
SSLv3 то зачем? Уязвимость POODLE же.
а еще хорошо
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
а еще хорошо
ssl_prefer_server_ciphers on;
Вот пример моего конфига с которым ssllabs.com дает A+
listen 443 ssl spdy;
ssl on;
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_ciphers 'EECDH+ECDSA+AESGCM:AES128+EECDH:AES128+EDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!ADH';
ssl_prefer_server_ciphers on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 10s;
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=31536000";
add_header Public-Key-Pins 'pin-sha256="[SOME_BASE64]"; max-age=5184000;'; #[SOME_BASE64] надо выставлять свое, гуглить как считать Public-Key-Pins
ssl_stapling on;
ssl_trusted_certificate /etc/nginx/ssl/[SITE]/trustchain.pem;
ssl_certificate /etc/nginx/ssl/[SITE]/server.crt;
ssl_certificate_key /etc/nginx/ssl/[SITE]/server.key;
ssl_dhparam /etc/nginx/ssl/[SITE]/dh.pem; #openssl dhparam 2048 -out dh.pem
Очередная статья, где комментарии полезней самой статьи…
Так и правильно же, на то оно и сообщество, коллеги — подняли тему и делимся опытом.
Вот только эти комментаторы не удосужились написать СВОЮ статью… ;)
А зачем? Почти все указанное мной описано в этой статье, нафига плодить? А вот текущую дополнить можно, раз уж она есть.
Строка в конфиге:
вызовет ошибку ERR_BLOCKED_BY_CLIENT для сайтов, которые используют загрузку контента в фреймы. У меня была проблема с WYSIWYG-редактором tinyMCE — открывались пустые окна.
Чтобы разрешить загрузку в фреймах, я поменял «DENY» на «SAMEORIGIN».
add_header X-Frame-Options "DENY";
вызовет ошибку ERR_BLOCKED_BY_CLIENT для сайтов, которые используют загрузку контента в фреймы. У меня была проблема с WYSIWYG-редактором tinyMCE — открывались пустые окна.
Чтобы разрешить загрузку в фреймах, я поменял «DENY» на «SAMEORIGIN».
Маленькая ремарка: для А+ все сертификаты должны быть подписаны SHA-2 (SHA-256)
Настройки как у вас, алгоритм SHA384withRSA, но А+ не получаю, только А.
Подскажите, у вас в trustchain.pem корневой+промежуточные или же только промежуточные?
Корневой тоже должен быть, в этом как раз суть trusted ;).
Hint: всю цепочку сертификатов можно получить этим скриптом.
dumpchain www.example.com > trustchain.pem
Добавлю, что если веб-сервис предназначен для внутренних нужд компании, то можно использовать самоподписанный сертификат.
Час))) это с пятью перекурами?
> Мы говорим ему, чтобы он залез по SSH на сервер и командой
> cat csr.csr
> скопировал код и вставил его куда нужно.
Отличный у вас босс :)
— Дай мне CSR
— Сам зайди на сервер и возьми
> cat csr.csr
> скопировал код и вставил его куда нужно.
Отличный у вас босс :)
— Дай мне CSR
— Сам зайди на сервер и возьми
Неплохо было бы написать, что важен порядок подключения сертификатов (сначала основной, затем промежуточный)
По этому поводу сходу две ссылки:
habrahabr.ru/post/195808/
habrahabr.ru/company/yandex/blog/249771/
Зачем нужно еще одно хауту — неясно.
habrahabr.ru/post/195808/
habrahabr.ru/company/yandex/blog/249771/
Зачем нужно еще одно хауту — неясно.
Создаем bundled PEM-сертификат. Босс должен будет переслать письмо от thawte, в котором в PEM-формате будет лежать наш сертификат. Мы должны открыть sublime text и вставить туда этот сертификат, а также скачать промежуточный сертификат с сайта thawte, вставить его в тот же файл и сохранить в /etc/nginx/certificate_bundled.crt.
А не проще что-то вроде?
$ cat our.crt thawte.crt > /etc/nginx/certificate_bundled.crt
Копируем приватный ключ туда же командой
mv private.key /etc/nginx/private.key
Все таки не копируете, а перемещаете, может так случиться, что кто-то долго будет искать оригинал, когда сотрет перемещенный.
openssl rsa -in /etc/nginx/private.key -out /etc/nginx/private.key
Тоже сомнительно перетирать оригинал, лучше сделать просто новый файл без пароля:
openssl rsa -in /etc/nginx/private.key -out /etc/nginx/private_nopass.key
8.8.8.8 давно уже не торт. Все чаще бывают перебои и не раз замечен в «забывании» доменов. Сегодня резолвит домен, завтра — нет. Для тестовой настройки, чтобы адрес сразу из головы — можно. Для продакшн — не подходит.
А в ситуации
Добавлю, что если веб-сервис предназначен для внутренних нужд компании, то можно использовать самоподписанный сертификат.может сильно помешать.
Есть ли рекомендации, что использовать вместо него? А то недавно перешел на яндексовский днс, когда гугловский лежал.
Пока не было проблем, но мало ли…
Пока не было проблем, но мало ли…
Если свой поднимать нет желания — можно попробовать resolv.conf в таком порядке:
208.67.222.222
208.67.220.220
4.2.2.2
4.2.2.1
первые два — сервера OpenDNS, два последних — DNS, которые обслуживаются Level 3 из меркантильных соображений (при ошибке резолвинга они подставляют адрес searchguide.level3.com).
208.67.222.222
208.67.220.220
4.2.2.2
4.2.2.1
первые два — сервера OpenDNS, два последних — DNS, которые обслуживаются Level 3 из меркантильных соображений (при ошибке резолвинга они подставляют адрес searchguide.level3.com).
без доменного имени https поставить нельзяА просветите по п. 0 — разве это так? На ip разве нельзя получить сертификат? Понятно, что боссу нужно domain.com, но все же.
И еще, не нужно ли послать босса купить и выделенный ip заодно?
А просветите по п. 0 — разве это так? На ip разве нельзя получить сертификат? Понятно, что боссу нужно domain.com, но все же.Можно: www.gogetssl.com/comodo-ssl-certificates/comodo-instantssl-premium/
Current SSL may secure IP address
И еще, не нужно ли послать босса купить и выделенный ip заодно?Только если требуется совместимость с Internet Explorer на Windows XP. Без выделенного IP придётся каждый раз игнорировать предупреждение безопасности.
Эм, т.е. уже можно привязать SSL не к ip, а к доменному имени?
И повесить на один ip несколько SSL доменов?
И все (кроме IE на XP) поддерживают и не ругаются?
Вот до чего техника дошла.
И повесить на один ip несколько SSL доменов?
И все (кроме IE на XP) поддерживают и не ругаются?
Вот до чего техника дошла.
Можно: www.gogetssl.com/comodo-ssl-certificates/comodo-instantssl-premium/
Current SSL may secure IP address
Выдать сертификат для IP или же для .local можно, но до 31октября 2015 года, это последний день, с 1-го ноября поддержки SSL для IP или .local уже не будет, ни у одного провайдера…
У меня были проблемы с
ssl_stapling on;
когда было более одного хоста на одном сервере, использующих SSL.
ssl_stapling on;
когда было более одного хоста на одном сервере, использующих SSL.
Поднять SSL на сервере и перейти на https — не одно и тоже. Переход на https подразумевает, что вы как минимум перелопатите все содержимое и скрипты сервера, чтобы избежать mixed content, разберетесь с куками, чтобы они стали secure и настроите HSTS для поддоменов. Без этого практического толку от поднятия ssl ноль. Вы как были уязвимы к MitM так и остались.
С самого начала надо подключать ресурсы не указывая протокол явным образом.
Раз такая жара, то подскажите пожалуйста сервис. На нем вбиваешь домен, он сканирует его и находит объекты, которые подключены не по https протоколу.
2. Заходим по SSH на сервер и далее пишем:Бред какой-то. Зачем сначала создавать ключ с параметром des3, а потом отключать пароль, если можно сразу создать ключ с параметром nodes?
openssl genrsa -des3 -out private.key 2048
9. Отключаем пароль для приватного ключа командой:
openssl rsa -in /etc/nginx/private.key -out /etc/nginx/private.key
2. Заходим по SSH на сервер и далее пишем:Почему создание ключа и CSR разбивается на две команды? Вот так слабо?
3. Создаем CSR-запрос вот этой строкой:
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out csr.csr
Потому что так написано в одном частокопируемом мануале, и люди плохо понимающие что происходит просто его копируют.
Интересно, зачем вообще понадобилось в мануале des3, если это и так параметр по умолчанию? Вспомнилось.
В команде к openssl надо еще
-sha256 указать, SHA-1 очень-очень скоро будет неактуален.
-
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переходим на HTTPS на Nginx: шпаргалка