Próbuję skonfigurować protokół SSL na moim serwerze Apache2, ale wygląda na to, że w ogóle nie działa.

Wykonałem samouczek, aby utworzyć pliki certyfikatów przy pomocy openssl i odpowiednio skonfigurowałem /etc/apache2/sites-available/default-ssl.conf.

Za każdym razem, gdy próbuję otworzyć witrynę za pomocą https, moja przeglądarka odmawia połączenia z powodu problemów z bezpieczeństwem. Mówi, że nie skonfigurowałem poprawnie mojej witryny.

W moim /var/log/apache2/error.logdostaję ostrzeżenia, które mówią, że mój certyfikat serwera nie zawiera identyfikatora, który odpowiada nazwie serwera.

[Mon Apr 10 11:03:24.041813 2017] [mpm_prefork:notice] [pid 1222] AH00169: caught SIGTERM, shutting down
[Mon Apr 10 11:03:30.566578 2017] [ssl:warn] [pid 661] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.579088 2017] [ssl:warn] [pid 1194] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.592958 2017] [mpm_prefork:notice] [pid 1194] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2k configured -- resuming normal operations
[Mon Apr 10 11:03:31.593136 2017] [core:notice] [pid 1194] AH00094: Command line: '/usr/sbin/apache2'

Czy masz jakieś pomysły, jak to rozwiązać? Dzięki w odniesieniu!

Okej, zauważyłem, że ten post jest ostatnio dość często oglądany i wydaje się, że wiele osób boryka się z tym samym problemem, co ja. Jeśli tak, to może ci to pomóc.

Wykonałem prosty krok po kroku, aby utworzyć certyfikat SSL dla mojego serwera. Podobnie jak w przypadku wielu samouczków, wynikiem tego samouczka był samopodpisany certyfikat przy użyciu OpenSSL. Tak, z podpisem własnym , że był problem. Przeglądarka nie mogła zaufać serwerowi z powodu jego certyfikatu, który jest podpisany przez siebie. Cóż, ja też nie zrobiłbym ...

Certyfikat musi być podpisany przez zewnętrzny, wiarygodny urząd certyfikacji (CA). Natknąłem się więc na Let's Encrypt który wykonuje całą pracę za Ciebie, a nawet jest łatwiejszy do skonfigurowania, a najlepsze jest to: jest całkowicie darmowy.

Instalacja

1) Usuń stare pliki certyfikatów ssl, które utworzyłeś za pomocą OpenSSL

2) Otwórz backports, aby uzyskać klienta Certbot na Debianie. Powinieneś wiedzieć, że otworzy to dziurę dla niedokończonego oprogramowania! Instaluj tylko pakiety, gdy wiesz, co robisz.

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

3) Zaktualizuj system Linux

sudo apt-get update

4) Zainstaluj certbota

sudo apt-get install python-certbot-apache -t jessie-backports

5) Skonfiguruj apache ServerName i ServerAlias

sudo nano /etc/apache2/sites-available/000-default.conf

6) Edytuj plik konfiguracyjny Apache

<VirtualHost *:80>
    . . .
    ServerName example.com
    ServerAlias www.example.com
    . . .
</VirtualHost>

7) Sprawdź poprawność składni

sudo apache2ctl configtest

8) Jeśli plik konfiguracyjny wygląda dobrze, zrestartuj serwer Apache

sudo systemctl restart apache2

9) Ustaw certyfikat za pomocą certbota i postępuj zgodnie z instrukcjami wyświetlanymi na ekranie.

sudo certbot --apache

Odnowienie

Wszystkie certyfikaty Let's Encrypt są ważne przez 3 miesiące. Aby odnowić, możesz uruchomić ręcznie

sudo certbot renew

Lub zautomatyzuj tę usługę jako zadanie CRON

sudo crontab -e

i wprowadź następujący wiersz, aby wywołać odnowienie w każdy poniedziałek o 2:30.

. . .
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

Bardziej szczegółowy samouczek można znaleźć tutaj: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8

Jeśli nie widzisz żadnych innych błędów SSL i jeśli próbowałeś ustawić „Debugowanie LogLevel” w pliku httpd.conf, ten komunikat o błędzie może również sugerować, że w pliku httpd.conf brakuje „Listen 443”.

To nie są błędy - to ostrzeżenia. Całkiem możliwe jest uruchomienie mod_ssl z certyfikatem, który nie pasuje do zdefiniowanych nazw serwerów, o ile zdefiniowano domyślnego hosta ssl, a nazwa pospolita na certyfikacie odpowiada nazwie hosta używanej przez klientów do łączenia się.

To ostatnie wydaje się nieprawdziwe w twoim przypadku. Jak mówi Jacob, musisz określić poprawną nazwę hosta jako nazwę pospolitą (lub alias) podczas tworzenia CSR .

Aby zobaczyć, jakie nazwy są obecnie na certyfikacie:

openssl s_client -showcerts -connect ${HOSTNAME}:443

Jeśli na komputerze jest zainstalowanych wiele certyfikatów i są one obsługiwane pod tym samym adresem IP, wówczas:

openssl s_client -showcerts -connect ${HOSTIP}:443 -servername ${HOSTNAME}

(gdzie wartości $ {...} są symbolami zastępczymi, należy je zastąpić odpowiednimi wartościami).

Natknąłem się na ten problem niedawno, gdy wygasł mój samopodpisany certyfikat. Poszukałem google i właśnie skopiowałem polecenie utworzenia nowego certyfikatu z jednej strony internetowej.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/apache2/ssl/apache.crt

W moim pliku konfiguracyjnym Apache: /etc/apache2/sites-available/default-ssl.conf. Plik certyfikatu i plik klucza odnoszą się do następującej nazwy pliku.

    SSLCertificateFile  /etc/apache2/ssl/apache.crt
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Stąd błąd widoczny tutaj w moim przypadku był łatwiejszy do naprawienia, po prostu poprzez podanie poprawnej lokalizacji pliku klucza certyfikatu podczas tworzenia certyfikatu ssl.

Oto polecenie, które powinienem był poprawnie stosować i pisać.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

W moim przypadku rozwiązałem ten problem, zastępując w pliku konfiguracyjnym apache ssl dla każdej zainteresowanej domeny:

ServerName mydomain.com
ServerAlias www.mydomain.com

przez :

ServerName www.mydomain.com
ServerAlias mydomain.com

Ponieważ mój certyfikat dotyczy „www.moja_domena.com”, a nie „moja_domena.com”

kompletny plik apache:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin [email protected]
        ServerName www.mydomain.com
        ServerAlias mydomain.com
    DocumentRoot /home/mydomain.com/public_html
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|ico|png)$ \ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ \no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    <Directory />
        Options +FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /home/mydomain.com/public_html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride All
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>


ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn
SSLCertificateFile /etc/letsencrypt/live/www.mydomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mydomain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Musieliśmy dodać ServerName i ServerAlias ​​do domyślnego pliku ssl, a nie tylko plik conf dla konkretnej domeny.
Pozbyło się to dla nas nieznośnego błędu.