Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

Seit dem Bekanntwerden der flächendeckenden, verdachtslosen Überwachung durch die NSA und andere Geheimdienste gewinnt Verschlüsselung im Internet an Bedeutung. Vor allem die Kommunikation zwischen Browser und Webserver wird verstärkt gesichert, um privates privat zu halten. Eine solche SSL-Verschlüsselung kann auch für den eigenen Apache Server eingerichtet werden. Benötigt wird dafür das Apache Modul „ssl“:

a2enmod ssl
service apache2 restart

Da die verschlüsselte Kommunikation zwischen Browser und Webserver nicht über Port 80, sondern über Port 443 abläuft, muss für jeden Port-80 -VirtualHost eine Entsprechung mit Port 443 angelegt werden, wenn SSL für eine (Sub-/)Domain verwendet werden soll:

<VirtualHost *:443>
    ServerName beispiel.de
    DocumentRoot /var/www/beispiel.de/
    
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
#   SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
</VirtualHost>

Der untere Teil der Konfiguration legt die SSL-Einstellungen fest. Die SSL-Engine wird aktiviert und die Pfade zu den Zertifikaten festgelegt. Benötigt werden mindestens ein Public Key (CertificateFile) und ein Private Key (CertificateKeyFile). Die Zeile der dritten Pfadangabe ist auskommentiert. Sie wird häufig benötigt, wenn Zertifikate von anerkannten Zertifikatsanbietern wie z.B. StartSSL verwendet werden sollen. Aktuell werden aber keine offiziell anerkannten Zertifikate genutzt, sondern Testzertifikate, die vom Server selbst ausgestellt wurden. Die letzte Zeile wird daher nicht benötigt. Diese sind übrigens nicht vertrauenswürdig, weshalb die Browser später warnen werden, wenn eine verschlüsselte Verbindung hergestellt wird. Für Testzwecke reicht ein selbst erzeugtes Zertifikat aber zunächst aus.

SSL Sicherheit verstärken

Um größtmögliche Sicherheit zu erreichen, soll der Browser der Nutzer angewiesen werden, die stärksten verfügbaren Verschlüsselungsalgorithmen zu nutzen und erst auf schwächere auszuweichen, wenn keine stärkeren verfügbar oder möglich sind. Dazu wird der VirtualHost um folgende Zeilen erweitert:

SSLProtocol All -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On
SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
Header add Strict-Transport-Security "max-age=15768000"

(Siehe auch: „Appied crypto hardening – bettercrypto.org„)

Nach den Änderungen an der Konfiguration muss Apache neu geladen werden:

service apache2 reload

Der VirtualHost sollte nun auch über https erreichbar sein. Euch wird im Browser beim ersten Aufruf eine Warnung angezeigt, die ihr aber ignorieren könnt. Für den Einsatz von SSL in der Öffentlichkeit sollten Zertifikate von anerkannten SSL-Certificate Authorities verwendet werden, damit Besucher eurer Seite nicht durch Warnungen abgeschreckt werden. Diese sind normalerweise nicht besonders günstig. Eine Ausnahme ist hier startssl.com – die verteilen einfache Zertifikate auch kostenlos.


Post published on 17. Mai 2014 | Last updated on 27. Dezember 2016
Tags:                 

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

46 thoughts on “Apache2: SSL-verschlüsselte Verbindungen ermöglichen (Ubuntu 14.04)

  • Es freut mich sehr, die den Cipherstring von BetterCrypto.org in Blogposts zu sehen!
    Aber warum wurde SSL3 und SSL-Compression nicht deaktiviert und STS nicht aktiviert?

  • Nutze: Ubuntu 14.04

    Bei mir erscheint die Fehlermeldung – Invalid Command „Header“?

    • Alles klar, es war bei mir ein Bug mit dem Header-Modul (Das Header Module war nicht aktiviert/erlaubt), das lässt sich ganz einfach lösen:

      sudo cp -arp /etc/apache2/mods-available/headers.load /etc/apache2/mods-enabled/headers.load

      und dann:

      sudo service apache2 restart

  • Es wäre hilfreich zu wissen, in welche Dateien diese Konfigurationen geschrieben müssen

  • Aloha

    Die Konfiguration ist echt simpel und trotzdem erhalte ich bei Aufruf der Testseite den Fehler 404

    Merkwürdigerweise nur bei Aufruf über https, über http kriege ich die erwartete Seite

    Bin ich da der einzige?

    Gruß
    Pawel

  • Danke für die Zusammenfassung. Ich hätte da einen Verbesserungsvorschlag. Der Hinweis auf:

    sudo a2enmod headers

    erspart einem Beginner das Suchen.

    Der Eintrag

    Header add Strict-Transport-Security "max-age=15768000"

    im File

    /etc/apache2/sites-enabled/000-default

    erzeugt sonst eine Fehlermeldung beim Starten des apache2 services. Zumindest auf meinem Raspbian.

    Cheers
    Michi

  • Hallo Thomas,

    super Artikel.
    Mir ist aber was aufgefallen. Wenn ich die Punkte mit SSL Verstärkung hinzufüge wird beim Chrome eine schwächere genutzt.
    Vorher wird der ECDHE_RSA Mechanismus verwendet und mit den Parametern aktiv wird nur der DHE_RSA verwendet.
    Leider bin ich kein Fachmann was das Thema angeht aber laut Google-Suche wäre ECDHE besser??

    Besten Dank

    Gruß Tobias

  • Danke für den guten Beitrag!

    Zu diesem Thema stellt sich mir jedoch noch folgenden „Expertenfrage“:
    Wenn mehrere Domains auf dem Server liegen und SSL benutzt wird, so sind alle Domains auch unter der ersten definierten default SSL Seite erreichbar. Wie kann ich explizit ausschließen das nur für eine Domain SSL benutzt wird und nicht für alle?

    SNI ermöglicht mir ja nur unterschiedliche Zertifikate zu benutzen. Wenn aber wie gesagt eine Domain kein Zertifikat hinterlegt hat und man diese über https aufruft wird das default benutzt. Gibt es dort die Möglichkeit das zu deaktivieren?

    Eine Weiterleitung per htaccess ist auch keine Lösung da das default Zertifikat einen Warnhinweis bringt (da es selber erstellt ist) und die Weiterleitung erst danach wirkt.

    Vielen Dank schon jetzt.

    Grüße Max

    • Hi,

      die einfachste Lösung ist, die default-ssl Konfiguration zu löschen (weil diese eigentlich eh nur Beispielfunktion hat) und die SSL-Konfiguration für jeden VHost einzeln zu machen. So verhinderst du, dass der default-VH als Fallback genutzt wird, wenn ein bestimmter VH kein SSL kann und du trotzdem via SSL aufrufst.

      LG Thomas

      • Hi,

        danke für die schnelle Antwort und den Tipp! Hab ich so ausprobiert. Problem ist nur, dass selbst wenn die default-VH nicht vorhanden ist, der nächst VH genutzt wird der SSL konfiguriert hat und zum default gemacht wird.

        Bsp. ist example1.zz (hat SSL konfiguriert) und example2.zz (hat kein! SSL konfiguriert), default-SSL-VH wurde gelöscht:
        example1.zz funktioniert korrekt.
        example2.zz kann per https aufgerufen werden und verweist leider auf example1.zz der wohl als default dient.

        Gruß Luk

      • Gibt es dazu eine Lösung oder ist das technisch nicht umzusetzen?

        Grüße Luk

  • Header add Strict-Transport-Security „max-age=15768000“

    Da gibts die Meldung vom Apache2

    Invalid command ‚Header‘, perhaps misspelled or defined by a module not included in the server configuration

  • Hallo,

    ich bin beschäftige mich erst seit einigen Wochen mit Linux/Debian.
    Wenn ich es richtig verstehe muss ich unter /var/www/beispiel.de für ‚beispiel.de‘ meinen Domainnamen schreiben, oder?
    Doch wie finde ich heraus, was genau ich anstelle von ‚beispiel.de‘ eintragen muss?
    Danke im Voraus.
    Grüße, Caro

  • Hallo! Ich habe jetzt schon das dritte Tutorial durch, aber es funktioniert einfach nicht bei mir… Ich bekomme immer den Fehler: »Fehler: Gesicherte Verbindung fehlgeschlagen«, wenn ich via https auf den Server zugreifen will. Im apache error.log steht folgendes:
    [Tue Nov 03 16:53:25 2015] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
    [Tue Nov 03 16:53:25 2015] [warn] RSA server certificate CommonName (CN) `server.beispiel.de‘ does NOT match server name!?
    [Tue Nov 03 16:53:25 2015] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
    [Tue Nov 03 16:53:25 2015] [warn] RSA server certificate CommonName (CN) `server.beispiel.de‘ does NOT match server name!?

    Mein FQDN (‚hostename -f‘) ist in dem Fall auch server.beispiel.de und in der /etc/apache2/sites-enabled/000-default im Block auch der o.a. FQDN im ServerName angegeben. In der /etc/apache2/sites-enabled/default-ssl steht das im VirtualHost-Block nicht drin. Es ist aber ganz gleich, ob ich dort auch noch mal einen ServerName-Eintrag absetze oder nicht, es ändert sich nichts.

    Zu erwähnen ist noch, dass ich SquirrelMail über die Paketverwaltung installiert habe und es auch eine squirrelmail.conf in der etc/apache2/sites-enabled/ gibt. Da ist ein Alias-Eintrag drin und ein entsprechender Directory-Eintrag. Das dürfte nach meiner laienhaften Einschätzung aber nichts mit dem Feher zu tun haben.

    Hat jemand eine Ahnung, wie ich das glattbügeln kann?

  • als erstes würde ich alles deaktivieren, was dem grundzustand entspricht. also alles raus und mit einer ganz einfachen apache conf arbeiten, dann schritt für schritt, die oben beschriebene anleitung umsetzen.

  • Super Anleitung, ich habe so viele gesehen die mich echt verrückt gemacht haben. Einfach erklärt. Danke…dann habe ich noch Listen 80 rausgenommen und seit dem gehts nur noch über htpps :D

  • Doofe Frage, brauch ich unbedingt einen V- host für SSL oder gehts auch ohne wenn nur eine Seite auf dem apache läuft. ich habe das einfach ohne V-host gemacht, der Rechner schafft nicht mehr als eine Domain und das ganze ist dank weselnder IP mit Dyndns sync. zum Laufen gebracht. ich würde das jetzt ungern wieder ändern

  • In dem Tutorial:
    https://legacy.thomas-leister.de/internet/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/
    haben wir 4 Dateien erstellt:
    private key des Zertifikats (zertifikat-key.pem)
    public key des Zertifikats (zertifikat-pub.pem)
    private key des CA (ca-key.pem)
    public key des CA (ca-root.pem)
    Wie müssen diese in die 000-default.conf eingpflegt werden und benötige ich dafür den Befehl:
    cat ca-root.pem >> zertifikat-pub.pem ?

    • Das sieht dann so aus:


      SSLCertificateFile /etc/myssl/fullchain.pem
      SSLCertificateKeyFile /etc/myssl/zertifikat-key.pem

      .. wobei die „fullchain.pem“ erstellt wird mit


      cat zertifikat-pub.pem > fullchain.pem
      cat ca-root.pem >> fullchain.pem

      Für fullchain.pem setzt man die Rechte am besten so, dass nur root schreiben kann und alle anderen lesen dürfen … für zertifikat-key.pem werden die rechte so gesetzt, dass nur root überhaupt zugreifen kann. (Apache startet zunächst als root, kann den Zertifikatskey dann lesen und läuft dann als „www-data“ weiter.

      • Wow Danke für eine so schnelle Antwort auf einen alten Beitrag! Bei den meisten Blogs kann man damit nicht rechnen.

        Hab alles so gemacht wie beschrieben. Nach einem Neustart des Apache2 Service bekomme ich folgende Meldungen im error.log:

        [Wed Mar 23 10:26:20.088901 2016] [ssl:warn] [pid 1053] AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name

        [Wed Mar 23 10:26:20.112308 2016] [mpm_prefork:notice] [pid 1053] AH00163: Apache/2.4.10 (Raspbian) OpenSSL/1.0.1k configured — resuming normal operations

        [Wed Mar 23 10:26:20.112585 2016] [core:notice] [pid 1053] AH00094: Command line: ‚/usr/sbin/apache2‘

        Die SSL Warnung sollte eigentlich nicht auftreten oder?

        • Hmm offenbar enthält das Zertifikat, das du dem Server mitgibst, keine Domain, die dem vHost von Apache entspricht. Mehr als das kann ich aus der Fehlermeldung leider auch nicht herauslesen. Vielleicht hast du Zertifikatsdateien vertauscht? Oder vergessen, eine Domain in das Zertifikat aufzunehmen?

          • Habs nochmal neu gemacht, aber der Fehler kommt immer noch. Hmm vielleicht ist auch irgendwo der der „server name“ falsch in meiner Apache2 Konfiguration…

  • Hallo Thomas,

    vielen Dank für deine aufschlussreichen Anleitungen. Ich bin gerade nach deiner Anleitung „Eine eigene OpenSSL CA erstellen und Zertifikate ausstellen“ vorgegangen. Das hat auch alles wunderbar geklappt. Ich habe das CA-root.pem Zert in Firefox und Chrome importiert.
    Den Apache Server habe ich so konfiguriert:

    DocumentRoot /var/www
    ServerName example.ddns.net
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.ddns.net-pub.pem
    SSLCertificateKeyFile /etc/ssl/private/example.ddns.net-key.pem
    SSLCertificateChainFile /etc/apache2/ssl.crt/ca-root.pem

    Ich erhalte im Firefox dennoch:
    example.ddns.net uses an invalid security certificate.
    The certificate is not trusted because the issuer certificate is unknown.
    The server might not be sending the appropriate intermediate certificates.
    An additional root certificate may need to be imported.
    Error code: SEC_ERROR_UNKNOWN_ISSUER

    Der Sinn der eigenen CA ist doch, dass ich nicht jedes Zertifikat nochmal erneut bestätigen muss, richtig? Habe ich etwas vergessen/falsch konifiguriert? Oder liegt es einfach am Firefox/Chrome?

    Vielen Dank!

    • Hi Andreas,

      du hast schon recht – eigentlich sollten Firefox und Chrome die neue CA anerkennen und kein „Error code: SEC_ERROR_UNKNOWN_ISSUER“ ausgeben. Hast du Firefox und Chrome nach dem Import mal neu gestartet? Vielleicht hilft das. Ansonsten kannst du noch versuchen, dein CA-Zertifikat zum TLS-Zertifikat hinzuzufügen:

      cat /etc/apache2/ssl.crt/ca-root.pem >> /etc/ssl/certs/example.ddns.net-pub.pem

      LG Thomas

      • -Ja habe ich beide bereits neu gestartet… Hat leider nichts geholfen.
        – Die beiden Dateien hatte ich auch schon mal zusammengefügt und SSLCertificateChainFile auskommentiert
        – apachectl configtest liefert auch eine korrekte Syntax der apache config
        – ich habe natürlich auch einen service apache2 reload probiert

        P.S. Danke für die Anpassung ;)
        P.S.2: ich depp mach dir mehr Arbeit… jetzt habe ich ausversehen nicht ein reply gemacht…

        • Hmm, mysteriös. Im Moment fällt mir dazu leider auch nicht mehr ein. Hast du denn schon mal versucht, die CA von neuem aufzusetzen? Klingt doof, aber manchmal hilft das, weil man sich beim ersten Versuch vertippt hat… ;-)

          LG Thomas

          • Ja habe ich auch schon gemacht. Die entsprechenden CA-Import aus Firefox und Chrome habe ich vor dem Neuimport auch wieder entfernt, so dass nichts durcheinander kommen kann. Ich habe das CA-Root gerade mal in Windows importiert und es wird mir nun auch das Web Zertifikat als vertrauenwürdig angezeigt, so dass ich vermute, dass mit dem Zertifikaten alles ok ist – bleibt der Apache. Kannst du mir bitte kurz durchgeben, welche Gruppenzugehörig und RWX-Rechte dein Ordner /etc/ssl/certs hat?
            Viele Grüße aus München

            • Die Dateirechte kann man auf root:root rwxr-xr-x lassen (und für den Key nur für root lesbar). Für Apache spielen die Dateirechte keine Kontrolle, weil er als User root startet, dann Initialisiert (und die Zertifikate lädt) und dann erst zum „apache“ user downgraded. Zugriff sollte also kein Problem sein (dann würde Apache auch im Log meckern).

            • Hmm ich bin der Sache, glaube ich, gerade noch etwas mehr auf die Spur gekommen. Und zwar zeigt bspw. der owncloud client korrekt die Information „validated by“ an. Bei Firefox und Chrome heißt es, wenn ich mir die Zertifikatsinformationen anschauen will: „not specified“ – warum auch immer… Hast du eine Idee woran das liegen könnte?
              Ich habe jetzt folgende Konfigurationen durch:
              1.
              SSLCertificateFile /etc/ssl/certs/example.ddns.net-pub.pem
              SSLCertificateKeyFile /etc/ssl/private/example.ddns.net-pub.pem
              2.
              SSLCertificateFile /etc/ssl/certs/example.ddns.net-pub.pem
              SSLCertificateKeyFile /etc/ssl/private/example.ddns.net-pub-ca_included.pem
              3.
              SSLCertificateFile /etc/ssl/certs/example.ddns.net-pub.pem
              SSLCertificateKeyFile /etc/ssl/private/example.ddns.net-pub.pem
              SSLCertificateChainFile /etc/apache2/ssl.crt/ca-root.pem
              4.
              SSLCertificateFile /etc/ssl/certs/example.ddns.net-pub.pem
              SSLCertificateKeyFile /etc/ssl/private/example.ddns.net-pub.pem
              SSLCertificateChainFile /etc/apache2/ssl.crt/ca-root.pem
              SSLCACertificateFile /etc/apache2/ssl.crt/ca-root.pem

              Hast du noch Ideen?
              LG

            • Sorry Andreas, meine Ideen sind erschöpft :-/ … dein OwnCloud Client funktioniert also korrekt mit den Zertifikaten?

            • Oh man …. ich hab den Fehler gefunden. 4 Stunden später. Obwohl das Bitdefender Plugin im Firefox deaktiviert war, hat scheinbar er den Netzwerkverkehr abgefangen und die SSL-Zertifikate überprüft… da muss man erstmal draufkommen. Die Lösung war das SSL-Modul von Bitdefender zu deaktivieren bzw. einen Whitelist Eintrag für meine URL hinzuzufügen.

              Vielen Dank für deine Hilfsbereitscahft! :) An deiner Anleitung lag es keineswegs. Ich habe jetzt viel im Netz nach dem Fehler/Anleitungen gesucht, aber keine konzentriert sich so auf das wesentlich. Und dann ist es noch 1a erklärt :)

            • Haha, jetzt musste ich gerade Lachen :D … weil ich *genau* dasselbe Problem auf den Windows-Rechner meiner Familie auch mal hatte – auch wegen Bitdefender ;D Hatte es wieder vergessen (und auch nicht daran gedacht, dass so etwas wie ein Antivirus-Programm Schuld sein könnte.)

              Aber schön, dass es jetzt funktioniert! :)

              LG Thomas

            • Ah alles klar ;)
              Das Einzige, was du noch ergänzen könntest, wäre:
              sudo a2enmod headers
              wird für
              Header add Strict-Transport-Security „max-age=15768000“
              benötigt.
              Sonst jetzt alles wunderbar und bin sehr happy :)

  • Thomas Escher

    Hi Namens-Vetter :-)
    Du scheinst mir der richtige Ansprechpartner zu sein …
    Weisst Du zufällig, ob ich zwei StartSSL-Zertifkate auf einem Webserver laufen lassen kann?
    Beispiel: https://meine-erste-domain.tld und https://meine-zweite-domain.tld beides auf einem Apache …

    Kann das überhaupt funktionieren??

    LG,

    Tom

  • Thomas Escher

    Hab da auch grad was drüber gelesen, und versuch‘ mich dran :-))

  • Ich warte auf einen Artikel zum neuen Ubuntu 16.04 . Wann kommt der Thomas?

  • Das folgende hatte ich nicht verstanden !? >>>
    Da die verschlüsselte Kommunikation zwischen Browser und Webserver nicht über Port 80, sondern über Port 443 abläuft, muss für jeden Port-80 -VirtualHost eine Entsprechung mit Port 443 angelegt werden, wenn SSL für eine (Sub-/)Domain verwendet werden soll:

    ServerName beispiel.de
    DocumentRoot /var/www/beispiel.de/

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    # SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

    Wo soll das Datei? Virtuallbox=Virtualhost??
    Ich dachte es währe nativ installiert Thomas.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.