Kto pamięta bezpieczny zestaw ssl_cipher niech pierwszy rzuci kamieniem. Ja nie.
https://ssl-config.mozilla.org/
Proste i skuteczne narzędzie, w którym wybieramy serwer, wersję jego i OpenSSL, poziom paranoi… kopiuj-wklej i do boju. Gotowe. 🙂
Kto pamięta bezpieczny zestaw ssl_cipher niech pierwszy rzuci kamieniem. Ja nie.
https://ssl-config.mozilla.org/
Proste i skuteczne narzędzie, w którym wybieramy serwer, wersję jego i OpenSSL, poziom paranoi… kopiuj-wklej i do boju. Gotowe. 🙂
Skończył mi się certyfikat SSL dla tego bloga. StartSSL podpadł wszystkim dookoła, trzeba było zrobić z tym porządek.
Z pomocą przyszła inicjatywa Let’s Encrypt, Electronic Frontier Foundation i rewelacyjny skrypt certbot 🙂
Co zrobiłem, żeby mieć nowy certyfikat:
# cd /opt
# mkdir certbot
# chmod 700 certbot
# cd certbot/
# wget https://dl.eff.org/certbot-auto
# chmod 700 certbot-auto
# ./certbot-auto --nginx
Certbot wyświetlił mi wszystkie skonfigurowane na nginxie domeny i poprosił o wybranie tej odpowiedniej.
Podałem maila, zgodziłem się na otrzymanie wiadomości w momencie gdy certyfikat się będzie miał ku końcowi.
Certbot poprawił config dla podanej domeny, wygenerował podpisany przez Let’s Encrypt certyfikat, zrobił reload nginxa.
Koniec.
Wow?!
PS
Certbot dostępny jest też w repozytorium EPEL ale jest tam starsza wersja, która jeszcze nie kuma nginxa. Za to dla fanów Apache – polecam 🙂
PS2
Pisałem już, że certbot i generowane przez Let’s Encrypt certyfikaty są darmowe?
PS3
Co do jakości samego certyfikatu:
https://www.ssllabs.com/ssltest/analyze.html?d=marcin.szydelscy.pl
W mojej konfiguracji używam JIRA za proxy postawionym na nginxie. Po upgrade do wersji 7.3 (a co za tym idzie też podniesieniu wersji tomcata do wersji 8.5) JIRA przestała działać z ustawionym parametrem connectora:
proxyName="jira.example.com" proxyPort="443" scheme="https" secure="true"
Jak to zwykle bywa okazało się, że to known issue 😉 Jak to jeszcze częściej bywa known issue nie wprost odwołuje się do tego co miałem w konfigu, ale workaround zadziałał.
Rozwiązanie problemu to zmiana parametru protocol na:
protocol="org.apache.coyote.http11.Http11NioProtocol"
Przejrzałem sobie logi z nginxa i zastanowiły mnie poniższe wpisy pojawiające się przy wszystkich moich domenach z ssl.
invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in
Rozwiązanie oczywiście banalne, wszystkie linie:
listen twojeip:443 ssl spdy;
zmieniamy na:
listen twojeip:443 ssl http2;
Google udostępnia całkiem sympatyczne narzędzie do analizowania jakości strony – PageSpeed. Ciągle dostawałem tam informację, że moje serwery nie kompresują zawartości. Kombinowałem i kombinowałem…
Okazało się, że w 'gzip_types’ brakowało typu 'application/javascript’. W dokumentacji nginx’a tego nie ma…
Cały wpis odpowiadający za włączenie kompresji w nginx’ie:
gzip on; gzip_comp_level 2; gzip_http_version 1.0; gzip_proxied any; gzip_min_length 1100; gzip_buffers 16 8k; gzip_types text/plain text/html text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript; gzip_disable "MSIE [1-6].(?!.*SV1)"; gzip_vary on;