Instalacja certyfikatu TLS/SSL na Apache i Nginx

Nazwa SSL nadal jest powszechna w wyszukiwaniach, ale współczesna konfiguracja korzysta z TLS. Dla większości publicznych stron wystarczy automatycznie odnawiany certyfikat ACME, na przykład Let’s Encrypt. Certyfikat komercyjny ma sens tylko wtedy, gdy wynika to z wymagań organizacji, klienta lub konkretnej usługi.

Co trzeba przygotować przed instalacją

Certyfikat musi odpowiadać rzeczywistym nazwom obsługiwanym przez serwer, na przykład example.com i www.example.com. Potrzebujesz kontroli nad DNS lub ruchem HTTP dla walidacji domeny, dostępu do właściwego serwera albo panelu hostingowego oraz informacji, który vhost obsługuje daną aplikację.

• sprawdź, które warianty domeny mają działać po HTTPS,
• ustal, czy certyfikat jest obsługiwany przez klienta ACME, panel czy dostawcę hostingu,
• nie zapisuj prywatnego klucza w katalogu publicznym ani w repozytorium,
• przed przeładowaniem usługi przygotuj test konfiguracji i plan powrotu.

Przykład dla Apache

Poniższy fragment pokazuje vhost z plikami wygenerowanymi przez klienta ACME. Ścieżki i nazwa usługi mogą być inne na Twoim serwerze.

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Użycie fullchain.pem jest ważne: przeglądarka powinna otrzymać pełny łańcuch certyfikatów, a nie tylko certyfikat serwera.

Przykład dla Nginx

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Dyrektywy HTTP/2 zależą od wersji Nginx, dlatego nie należy kopiować ich z przypadkowej starej konfiguracji. Certyfikat i prywatny klucz muszą być dostępne dla procesu serwera, przy zachowaniu ograniczonych uprawnień do klucza.

Test, przeładowanie i kontrola z zewnątrz

Po zmianie najpierw testuje się konfigurację. Dopiero poprawny wynik jest podstawą do przeładowania właściwej usługi. Przykładowe polecenia uruchamiaj wyłącznie na serwerze, którego konfigurację właśnie sprawdzasz.

apachectl -t && systemctl reload apache2
nginx -t && systemctl reload nginx
openssl s_client -connect example.com:443 -servername example.com </dev/null

Po stronie użytkownika sprawdź stronę w przeglądarce, przekierowanie HTTP do HTTPS oraz nazwy domen na certyfikacie. Zewnętrzny monitoring powinien kontrolować dostępność HTTPS, poprawność hostname i termin wygaśnięcia.

Odnowienie jest częścią wdrożenia

Nie wystarczy jednorazowo wystawić certyfikat. Trzeba wiedzieć, jaki klient lub panel go odnawia, czy zadanie odnowienia działa oraz kto dostanie alert przed wygaśnięciem. Test odnowienia wykonuje się narzędziem użytym na danym hoście, a nie uniwersalnym poleceniem skopiowanym z innego systemu.

Jeśli zmiana certyfikatu jest elementem większej aktualizacji systemu lub migracji aplikacji, zaplanuj ją razem z testami i kopią bezpieczeństwa. Zobacz także hardening serwera, monitoring oraz bezpieczną migrację.