Bei vielen Typo3-Seiten gibt es Einträge der Art

config.baseURL= http://<domain>/

im root-Template. Will man dem Benutzer die Wahl lassen zwischen http und https ist das ein Problem, weil dann bei einer sicheren Verbindung Inhalte unsicher nachgeladen werden. Firefox blockt diese Inhalte. Da das  dann oft CSS-Dateien oder ähnliches sind wird die Seite ziemlich verunstaltet.

Eine Lösung besteht darin das benutzte Protokoll zu erfragen. Dazu gibt man im Template unter Konstanten folgenden Code ein:

protocol = http
[globalString = IENV:TYPO3_SSL=1]
  protocol = https
[global]

Nun kann man im Setup darauf Bezug nehmen:

# Das Protokoll wird unter Constants ermittelt
config.baseURL= {$protocol}://<domain>/

Nun klappt das auch mit der sicheren Verbindung.

Veröffentlicht unter typo3.

Mit letsencrypt soll es für alle Webseiten einfach und erschwinglich werden eine Verschlüsselung zu ermöglichen.

Eine schöne Beschreibung findet sich unter https://lukasthiel.de/wiki/SSL-Zertifikate_mit_Let%27s_Encrypt

Installation

Die Installation erfolgt mittels:

cd /root
git clone https://github.com/letsencrypt/letsencrypt

Das Script lädt notwendige Pakete und Aktualisierungen beim ersten Aufruf nach, hier z.B. über den Aufruf der Hilfefunktion:

/root/letsencrypt/letsencrypt-auto -h

Dabei werden einige Pakete über die Paketverwaltung der Distribution ergänzt und zusätzlich einiger Python-Code nach /root/.local/share/letsencrypt/ gebracht.

Bootstrapping dependencies for openSUSE-based OSes...

The following 8 NEW packages are going to be installed:
  dialog libdialog11 libffi48-devel python-devel python-pip python-setuptools 
  python-virtualenv python-xml 

The following package is suggested, but will not be installed:
  terminfo 

8 neue Pakete zu installieren.
Gesamtgröße des Downloads: 5,8 MiB. Nach der Operation werden zusätzlich 26,8 
MiB belegt.
Fortfahren? [j/n/? zeigt alle Optionen] (j): j
Creating virtual environment...
Installing Python packages...
...

Am Ende wird der Hilfe-Text ausgegeben.

Das Tool legt an einer Reihe von Stellen Dateien ab:

  • /etc/letsencrypt/  hier liegen die Zertifikate und die zugehörigen Einstellungen
  • /root/.local/share/letsencrypt/ in diesem Verzeichnis liegen die benötigten Python Scripte
  • /var/log/letsencrypt hier liegt die Logdatei und die zugehörigen Archive
  • /var/lib/letsencrypt für Backups
  • /root/letsencrypt vom Benutzer festgelegtes Verzeichnis für das Programmpaket, denkbar z.B. auch /opt/letsencrypt

Zertifikats-Erzeugung im Dialog

Der Aufruf von

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly

erzeugt dann im Prinzip das Zertifikat. Bei mit (OpenSUSE) wollte das nicht funktionieren, weil das Tool das Verzeichnis /etc/apache2/sites-enabled vermisste. Nachdem ich das Verzeichnis angelegt hatte (das Verzeichnis selber kann leer bleiben) ließ sich das Zertifikat erzeugen.

Es startet ein fensterbasiertes Tool an der Konsole. Im ersten Schritt gibt man an, wie sich der Webserver gegenüber dem Zertifikats-Aussteller authentifizieren soll. Die einfachste Version besteht darin das Script eine Datei im Webroot der Seite plazieren zu lassen. Dazu muss das Script die Pfade kennen:

letsencrypt-1

letsencrypt-2

letsencrypt-3

letsencrypt-4

Wenn die Datei über den Webserver erreichbar war, dann kommt die Erfolgsmeldung:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/elearn-server.de/fullchain.pem. Your cert will
   expire on 2016-09-14. To obtain a new or tweaked version of this
   certificate in the future, simply run letsencrypt-auto again. To
   non-interactively renew *all* of your certificates, run
   "letsencrypt-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to <admin>@<domain>.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Zertifikats-Erzeugung mit Parametern

Man kann sich den Ablauf auch etwas einfacher machen, vor allem, wenn man mehrere Domains betreut, indem man statt der Dialog orientierten Variante eine Parameter orientierte Variante benutzt (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly --webroot -w /srv/www/vhosts/elearn-server.de/httpdocs/ -d elearn-server.de -d www.elearn-server.de

Für umfangreiche Nutzung kann es noch geschickter sein sich für jede Domain eine Konfigurationsdatei, z.B. letsencrypt.ini, anzulegen

# Wir nutzen 4096 bit RSA key statt 2048
rsa-key-size = 4096

# allgemeine Angaben
email = <admin>@<domain>
authenticator = webroot

# Domains fuer die wir Zertifikate beantragen, die erste in
# der liste legt den Hauptnamen fest. Alle Domains müssen beim
# Aufruf erreichbar sein
domains = elearn-server.de, www.elearn-server.de

# Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in
# /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden
webroot-path = /srv/www/vhosts/elearn-server.de/httpdocs/

Aufgerufen wird letsencrypt-auto dann mittels (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/elearn-server.de/letsencrypt.ini

Aufpassen muss man aber unbedingt mit Subdomains. Letsencrypt lässt nämlich nur etwa 5 Aufrufe pro Domain und Woche zu. In dem Beispiel sind dann schon zwei Aufrufe verbraucht. Mehr als 5 Subdomains im gleichen Zertifikat sind wohl nicht möglich.

Im Laufe der Erzeugung legt letsencrypt in der Wurzel des angegebenen Servers ein Verzeichnis .well-known an. Das Zertifikat selber wird unter /etc/letsencrypt/live/<domain>/ abgelegt und besteht aus den vier Dateien

  • cert.pem
  • chain.pem
  • fullchain.pem
  • privkey.pem

dies sind Links auf die Dateien

  • /etc/letsencrypt/archive/<domain>/cert1.pem
  • /etc/letsencrypt/archive/<domain>/chain1.pem
  • /etc/letsencrypt/archive/<domain>/fullchain1.pem
  • /etc/letsencrypt/archive/<domain>/privkey1.pem

Diese Verlinkung soll vermutlich die Aktualisierung der Zertifikate vereinfachen.

Apache konfigurieren

Jetzt muss nur noch der Apache-Webserver von den neuen Möglichkeiten wissen. Die notwendigen Einstellungen für den Host sind in der Datei /etc/letsencrypt/options-ssl-apache.conf zu finden:

# Baseline setting to Include for SSL sites

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log

# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"

Testen kann man das Zertifikat dann unter https://www.ssllabs.com/ssltest/

Weitere Informationen

Möchte man sein Zertifikat um weitere Subdomains erweitern, so ist das kein Problem. Hat man z.b. nur für <domain> und www.<domain> ein Zertifikat erstellt und möchte jetzt auch blog.<domain> mit aufnehmen, so erweitert man einfach die Liste der Domains entsprechend und löst die Erstellung des Zertifikats erneut aus. Es erscheint jetzt ein Dialog, der nachfragt, ob man das Zertifikat erweitern möchte. Hier klickt man auf Expand und wenn die Subdomain erreichbar ist, dann wir das Zertifikat neu erzeugt.
Laut https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 gilt hierfür nicht das Limit von 5 pro Woche.

Unter /etc/letsencrypt/csr/ findet man die Key-signing-requests, ein Hinweis darauf, dass das Schlüsselpaar auf dem eigenen Server erzeugt wurde und der private Schlüssel auch letsencrypt nicht bekannt ist.

Bei owncloud gibt es einen Abschnitt in der .htacess, der die Überprüfung durch letsencrypt verhindert:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/carddav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/caldav/ [R=301,L] 
RewriteRule ^apps/calendar/caldav\.php remote.php/caldav/ [QSA,L]
RewriteRule ^apps/contacts/carddav\.php remote.php/carddav/ [QSA,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L] 
</IfModule>

Das Einfügen der Zeile

RewriteRule ^\.well-known/acme-challenge - [L]

löst das Problem. Mal sehen,  ob es Seiteneffekte gibt.

 

Löschen von Schlüsseln

Mit

/root/letsencrypt/certbot-auto certificates

kann man abfragen, wie die Zertifikate auf dem Server genau heißen und die zugehörigen Dateien dann mittels

/root/letsencrypt/certbot-auto delete --cert-name <gefundener Name>

vom eigenen Server entfernen.

Mit folgendem Kommando kann man abfragen, welche Domains im Zertifikat eingetragen sind:

openssl x509 -in /etc/letsencrypt/live/<domain-bezeichnung>/cert.pem -text -noout | grep DNS

Mit den Schritten ist das Zertifikat selber aber nicht gelöscht, das wäre dann erst nach einigen Tagen automatisch der Fall. Noch nicht getestet habe ich die Schritte:

certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem

das müsste natürlich vor dem Löschen der lokalen Dateien erfolgen.

 

Links

Einige Provider haben Sender Policy Framework (SPF) aktiviert. Damit kann der empfangende Server erreichen, dass er nur noch Mails von Servern annimmt, die im SPF-Record der absendenden Domain eingetragen sind. Das sollte theoretisch SPAM verhindern. Mehr Informationen zu dem Problem unter https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf/ .

Leider verhindert das auch alle Weiterleitungen von Mails der absendenden Domain. Eine Lösung für dieses Problem ist ein Umschreiben der Absenderadresse bei der Weiterleitung mittels Sender Rewrite Schema (SRS). Da Postfix dafür von Haus aus keine Komponenten mitbringt braucht man zusätzliche Software.

Im Web finden sich mehrere Projekte für diesen Zweck, die in der Regel mit einem zusätzlichen Dämon arbeiten:

Ich habe mich für postsrsd entschieden und bin der Anleitung unter https://seasonofcode.com/posts/setting-up-dkim-and-srs-in-postfix.html gefolgt.

zipper -i cmake
cd /tmp
wget https://github.com/roehling/postsrsd/archive/master.zipunzip -e master.zip
cd postsrsd-master
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../
make
sudo make install

Der letzte Befehlt hat dann folgende Aktionen ausgelöst:

[100%] Built target postsrsd
Install the project...
-- Install configuration: ""
-- Installing: /usr/sbin/postsrsd
-- Installing: /usr/share/doc/postsrsd/README.md
-- Installing: /usr/share/doc/postsrsd/README_UPGRADE.md
-- Installing: /usr/share/doc/postsrsd/main.cf.ex
-- Chroot jail: /usr/lib/postsrsd
-- Installing: /etc/default/postsrsd
-- Installing: /etc/systemd/system/postsrsd.service
-- Generating secret key
-- Installing: /etc/postsrsd.secret

Danach waren die notwendigen Dateien vorhanden. Ein

service postsrsd status

liefert aber die Fehlermeldung:

systemd[1]: [/etc/systemd/system/postsrsd.service:13] Unknown lvalue 'RuntimeDirectory' in section 'Service'

Anscheinend gibt es den Wert RuntimeDirectory in der auf dem Server vorliegenden Version von Systemd noch nicht https://www.freedesktop.org/software/systemd/man/systemd.exec.html . Konsequenterweise startet des Dämon auch nicht, ich musste erst das Verzeichnis /run/postsrsd/ per Hand anlegen.

Danach muss man dann noch die Postfix-Konfiguration zu erweitern, dass der neue Dämon auch eingebunden wird:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

Ich muss das alles einmal in Ruhe testen.

Weitere Anleitungen, die ich testen will: