Ich versuche, SSL auf meinem Apache2-Webserver einzurichten, aber es scheint, dass es überhaupt nicht funktioniert.

Ich habe ein Tutorial zum Erstellen von Zertifikatsdateien mit openssl befolgt und das /etc/apache2/sites-available/default-ssl.confrichtig konfiguriert .

Jedes Mal, wenn ich versuche, meine Website mit https zu öffnen, kann mein Browser aus Sicherheitsgründen keine Verbindung herstellen. Es heißt, dass ich meine Website nicht richtig konfiguriert habe.

In meinem werden /var/log/apache2/error.logWarnungen angezeigt, die besagen, dass mein Serverzertifikat keine ID enthält, die mit dem Servernamen übereinstimmt.

[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'

Haben Sie Ideen, wie Sie das lösen können? Danke in Bezug!

Okay, mir ist aufgefallen, dass dieser Beitrag in letzter Zeit ziemlich oft aufgerufen wurde und es scheint, dass viele Leute mit dem gleichen Problem konfrontiert sind wie ich. Wenn ja, könnte Ihnen dies helfen.

Ich habe eine einfache Schritt-für-Schritt-Anleitung durchgearbeitet, um eine SSL-Zertifizierung für meinen Webserver zu erstellen. Wie so viele andere Tutorials war das Ergebnis des Tutorials, an dem ich teilgenommen habe, ein selbstsigniertes Zertifikat, das OpenSSL verwendet. Ja selbst signiert , das war das Problem. Der Browser konnte dem Server nicht vertrauen, da sein Zertifikat von ihm selbst signiert ist. Nun, ich würde es auch nicht tun ...

Ein Zertifikat muss von einer externen vertrauenswürdigen Zertifizierungsstelle (CA) signiert werden. Also bin ich auf Let's Encrypt gestoßen, das die ganze Arbeit für Sie erledigt und noch einfacher einzurichten ist. Das Beste ist: Es ist absolut kostenlos.

Installation

1) Löschen Sie Ihre alten SSL-Zertifikatsdateien, die Sie mit OpenSSL erstellt haben

2) Öffnen Sie Backports, um den Certbot-Client auf Debian zu installieren. Sie sollten wissen, dass dies ein Loch für unfertige Software öffnet! Installieren Sie nur die Pakete, wenn Sie wissen, was Sie tun.

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

3) Aktualisieren Sie Ihr Linux-System

sudo apt-get update

4) Installieren Sie certbot

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

5) Richten Sie Apache ServerName und ServerAlias ​​ein

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

6) Bearbeiten Sie die Apache-Konfigurationsdatei

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

7) Überprüfen Sie die korrekte Syntax

sudo apache2ctl configtest

8) Wenn die Konfigurationsdatei gut aussieht, starten Sie den Apache-Server neu

sudo systemctl restart apache2

9) Richten Sie mit certbot ein Zertifikat ein und folgen Sie den Anweisungen auf dem Bildschirm.

sudo certbot --apache

Erneuerung

Alle Zertifikate von Let's Encrypt sind 3 Monate gültig. Zum Erneuern kann man das manuell ausführen

sudo certbot renew

Oder automatisieren Sie diesen Dienst als Cron-Job

sudo crontab -e

und geben Sie die folgende Zeile ein, um jeden Montag um 2:30 Uhr eine Verlängerung zu veranlassen.

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

Ein detaillierteres Tutorial finden Sie hier: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8

Wenn keine weiteren SSL-Fehler angezeigt werden und Sie versucht haben, 'LogLevel-Debug' in der Datei httpd.conf festzulegen, kann diese Fehlermeldung auch darauf hindeuten, dass 'Listen 443' in der Datei httpd.conf fehlt.

Das sind keine Fehler - es sind Warnungen. Es ist durchaus möglich, mod_ssl mit einem Zertifikat auszuführen, das nicht mit den definierten Servernamen übereinstimmt, solange Sie einen Standard-SSL-Host definiert haben und der allgemeine Name auf dem Zertifikat mit dem Hostnamen übereinstimmt, der von den Clients für die Verbindung verwendet wird.

Letzteres scheint in Ihrem Fall nicht zu stimmen. Wie Jacob sagt, müssen Sie den richtigen Hostnamen als allgemeinen Namen (oder Alias) angeben, wenn Sie eine CSR erstellen .

So sehen Sie, welche Namen sich derzeit auf dem Zertifikat befinden:

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

Wenn auf dem Computer mehrere Zertifikate installiert sind, die unter derselben IP-Adresse bereitgestellt werden, gilt Folgendes:

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

(wobei die $ {...} Werte Platzhalter sind, die Sie durch die entsprechenden Werte ersetzen sollten).

Dieses Problem trat kürzlich auf, als mein selbstsigniertes Zertifikat abgelaufen ist. Ich habe gegoogelt und nur den Befehl zum Erstellen eines neuen Zertifikats von einer Website kopiert.

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

In meiner Apache-Konfigurationsdatei: /etc/apache2/sites-available/default-ssl.conf. Die Zertifikatsdatei und die Schlüsseldatei beziehen sich auf den folgenden Dateinamen.

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

Daher war der hier in meinem Fall festgestellte Fehler einfacher zu beheben, da beim Erstellen des SSL-Zertifikats lediglich der korrekte Speicherort der Zertifikatschlüsseldatei angegeben wurde.

Hier ist also der Befehl, den ich hätte verwenden und richtig eingeben sollen.

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

In meinem Fall habe ich dieses Problem gelöst, indem ich in meiner Apache SSL-Konfigurationsdatei für jede betroffene Domain Folgendes ersetzt habe:

ServerName mydomain.com
ServerAlias www.mydomain.com

durch :

ServerName www.mydomain.com
ServerAlias mydomain.com

Weil mein Zertifikat für "www.meinedomain.com" und nicht für "meinedomain.com" ist

Komplette Apache-Datei:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin noreply@mydomain.com
        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>

Wir mussten den Servernamen und die ServerAlias ​​zur Standard-ssl-Datei hinzufügen, nicht nur zur conf-Datei für die bestimmte Domäne.
Dies hat den lästigen Fehler für uns beseitigt.