Все оказалось куда проще, создаем в рабочей диретокрии софта php /etc или /usr/local/etc/ файл php-cli.ini и php cli из консоли автоматом подтянут этот конфиг.
После увидите инструкцию для днс txt запись.
И после acme.sh -d dom.ru -d '*.dom.ru' --renew --yes-I-know-dns-manual-mode-enough-go-ahead-please
Что на шел в интернете, сам не генерил еще викард от letsencrypt
А что мешает подключиться по ssh и закрыть доступ к порту через iptables?
Или отредактировать конфиг вэб сервера?
Для сведения, нашел интересный материал от мазиллы.
Где есть рекомендуемые параметры для протоколов tls.
Мазила рекомендует параметры чипсетов такие.
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
И автоматический генератор кода вэб сервера от мазиллы, это если кто не хочет разбираться в параметрах.
https://ssl-config.mozilla.org/
Все в порядке, после заполнения кэша у кэщирующего днс, отдача ssl_stapling прошла верна OCSP stapling Yes.
Nginx поддерживает stapling только в качестве кэша, поэтому если в данный момент у него нет действительного ocsp для запроса, он отвечает браузеру без stapling и исправляет сервер ocsp, чтобы сохранить его для дальнейшего использования, как то так.
И из консоле компа тоже стала выводится информация.
openssl s_client -connect site.net:443 -status 2>&1 | grep "OCSP" OCSP response: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response
Заметил что на бесплатном сертификате Let’s Encrypt не работает OCSP stapling = Yes.
Получаю OCSP response: no response sent и проверки сертификата OCSP stapling = No.
В конфиге виртуал хоста указываю.
ssl_stapling on; ssl_stapling_verify on; resolver 127.0.1.1; resolver_timeout 5s;
ssl_certificate /usr/local/etc/letsencrypt/live/site.ru/fullchain.pem; ssl_certificate_key /usr/local/etc/letsencrypt/live/site.ru/privkey.pem; ssl_trusted_certificate /usr/local/etc/letsencrypt/live/site.ru/chain.pem;
А вот что насчет тикетов?
ssl_session_ticket_key current.key; ssl_session_ticket_key prev.key; ssl_session_ticket_key prevprev.key;
Как то мутно описано, толи это нужно для когда используется при балансировке трафика, толи я не понял.
это тоже включено у меня:
ssl_stapling on;ssl_stapling_verify on;но! не так давно из-за этого возникала одна проблема, которую не так просто было обнаружить.
суть вроде в том была, что при этом еще происходит обращение к dns серверам (из /etc/resolv.conf или там же в nginx конфиге resolver и resolver_timeout)
так вот однажды заметил что https сайты как-то тормознуто отвечают. начал ковырять, при перезагрузке nginx вообще страшно медленно это делал.
оказалось что по какой-то причине временно была плохая связь с гугловскими днс (8.8.8.8) или они сами по себе подтормаживали.
и при перезапуске nginx с парой сотен доменов с сертификатами и ssl_stapling'ом, происходило множество обращений к dns и отсюда тормоза.
в итоге решил дополнительной установкой локального кэширующего dnsmasq и указанием его как единственного в системе.
после чего nginx стал перегружаться моментом и все тормоза пропали.
вот такая история, о которой надо помнить, используя ssl_stapling
Хмм, а чем поможет dnsmasq если он просто перенаправляет запросы на указанный днс.
Если указать днс гугла или cloudflare, или провайдеровский днс в конфиге dnsmasq , то они также если упадут, запросу долго ждать ответа придется, или я ошибаюсь?
