Meine Ausgabe von dmesg war unbrauchbar geworden, da hier nur noch Zeilen der Art:

 [38929.065531] [UFW BLOCK] IN=enp1s0 OUT= MAC=01:00:5e:00:00:01:00:24:c0:ff:ee:38:08:00 SRC=192.168.1.14 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

zu finden waren.

Das sind abgelehnte Multicast-Pakete von meinem SAT>IP Receiver. An der Konsole habe ich eingegeben:

sudo ufw allow in proto udp to 224.0.0.0/4
sudo ufw allow in proto udp from 224.0.0.0/4

und dann die Datei /etc/ufw/before.rules  am Ende, vor der COMMIT-Zeile,  etwas ergänzt:

# allow IGMP
-A ufw-before-input -p igmp -d 224.0.0.0/4 -j ACCEPT
-A ufw-before-output -p igmp -d 224.0.0.0/4 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Seit dem Neustart von UFW bleiben die Meldungen aus.

 

Schulen arbeiten meist mit Proxy-Servern. Einerseits um die Internetverbindung etwas schonen zu können, aber auch um die Internetzugriffe zu filtern.

In der Regel will man dafür aber nicht jeden Browser per Hand konfigurieren müssen. Daher gibt es Mechanismen, um die Konfigurationseinstellungen automatisch vornehmen zu können.

Dazu dient in der Regel eine Datei mit dem Namen wpad.dat (einige proprietäte Systeme erwarten den Namen proxy.pac).

Die Datei hat bei unserem IServ folgenden Inhalt:

function FindProxyForURL(url, host)
 {
  if (
   isPlainHostName(host)
   || dnsDomainIs(host, "local")
   || dnsDomainIs(host, "localhost")
   || dnsDomainIs(host, "schule-rlw.de")
   || isInNet(host, "127.0.0.1", "255.0.0.0")
   || isInNet(host, "10.0.0.0", "255.0.0.0")
  ) {
    return "DIRECT";
  } else {
   return "PROXY 172.27.16.2:3128"
  }
 }

Diese Datei kann man dem Client auf folgende Arten zukommen lassen:

1. Per DHCP

In der Konfigurationsdatei DES DHCP-Servers müssen sich die folgenden Zeilen finden:

option proxy-config code 252 = text;
option proxy-config "http://schule-rlw.de/wpad.dat";

Bei TFK-Boxen ist das im Schulrouter Plus unter Dienste -> DHCP-Server zu finden, dort erfolgt der Eintrag in das große Textfenster.

Der Bezeichner, hier proxy-config, ist frei wählbar, muss nur in beiden Zeilen gleich sein. Wesentlich ist die Code-Nummer.

2. Per DNS

Viele Systeme sind in der Lage Autokonfiguration aktiv zu suchen. Dazu rufen sie die URL http://wpad/wpad.dat auf. Es muss also nur ein entsprecchender Eintrag im Nameserver vorhanden sein und die wpad.dat im Wurzelverzeichnis des Webservers liegen. Als Port kommt übrigens nur 80 in Frage, ein Zugriff per https ist nicht konfigurierbar.

 

3. mozilla.cfg

Hat man Zugriff auf eine zentrale Konfigurationsdatei für den Mozilla firefox, so kann man hier die folgenden zeilen eintragen:

pref("network.proxy.autoconfig_url", "http://schule-rlw.de/wpad.dat");
pref("network.proxy.type",2);

Damit wird die automatische Konfiguration aktiviert und gleichzeitig auch der Pfad zur Konfigurationsdatei angegeben.

Meine Schülerfirma Netthelp betreut eine Reihe von Kunden, die ihre Domains bei Domainfactory liegen haben. Wenn bei Netthelp ein Serverwechsel ansteht, dann taucht immer wieder das Problem auf, dass wir die Zugangsdaten der Kunden brauchen. Der letzte Zugriff auf die Domainverwaltung ist dann zum Teil schon mehrere Jahre her und die Zugangsdaten sind nirgends mehr im Zugriff. Dieses Problem trat bei den aktuellen Umstellungen massiv auf, da DF die Regeln für gültige Passwörter geändert hat und ungültige Passwörter dann deaktiviert hatte.

Unser erster Ansatz dieses Problem zu Lösen war eine Cluster-IP bei Strato. Diese IP ist relativ teuer 9,99€ im Monat und für uns nahezu nutzlos, da sie an einen Server-Vertrag gebunden ist. Wenn wir diesen Server wechseln, dann ändert sich auch die Cluster-IP.

Der einzige Ansatz der uns (Dank an Lukas Thiel) jetzt noch einfällt ist eine Domain-Weiterleitung auf eine Netthelp-Subdomain. Dabei muss man ein kleines bisschen tricksen, weil der Grund-Eintrag für linux-diskless.de keine cname sein darf, sondern ein A-Record erwartet wird. Der Trick besteht darin den Eintrag auf Domainfactory zu belassen und dann dort eine Header-Weiterleitung auf www.linux-diskless.de einzurichten. Der Eintrag für „www“ und sogar der für „*“ darf dann ein cname sein.

Für den MX-Eintrag wird ebenfalls linux-diskless.netthelp.de genutzt und keine Subdomain der jeweiligen Domain. Ein MX-Record muss in erster Instanz auf einen A-Record und darf nicht auf einen cname-Record verweisen.

Der einzige Schönheitsfehler besteht in der zwingenden Weiterleitung auf www.

Als Beispiel soll hier die Domain linux-diskless.de dienen:

  1. Ich lege einen A-Record linux-diskless.netthelp.de an, der auf die gewünschte Server-IP zeigt
  2. Nun gehe Ich zur Domain-Verwaltung von linux-diskless.de und lege unter Domain-Einstellungen eine Weiterleitung auf www.linux-diskless.de an (http:// oder wenn konfiguriert besser https://.
  3. Dann folgen die Verweise auf die Netthelp-Subdomain:

Für zukünftige Serverwechsel müssen wir jetzt nur noch den Eintrag für die Netthelp-Subdomain ändern Ein Zugriff auf den DF-Account des Kunden ist nicht mehr notwendig.

Weitere Informationen unter:

Bei einem Serverwechsel taucht immer wieder das Problem auf, dass man auch vorhandene Mailman-Listen umziehen möchte. Der Vorgang ist eigentlich ganz einfach. Die Beschreibung geht davon aus, dass Mailman auf dem Zielrechner bereits eingerichtet und funktionsfähig ist.

Im ersten Schritt müssen die Listen-Verzeichnisse aus den Ordnern

/var/lib/mailman/archives/private/
/var/lib/mailman/lists/

kopieren. Für jede Liste gibt es in den Ordnern ein gleichnamiges Verzeichnis und in dem Archivordner noch jeweils eines mit der Extension .mbox. Diese Verzeichnisse werden einfach auf den neuen Server kopiert und dem richtigen Eigentümer übereignet. Unter Ubuntu gehören die Dateien in der Regel lists.list und die übergeordneten Verzeichnisse root.list.

Die Eigentümer müssen jeweils noch richtig gesetzt werden.

Dann geht es noch an zwei Dateien im Verzeichnis data:

aliases
virtal-mailman

Hier finden sich für jede Liste mehrere Zeilen mit den Weiterleitungen. Die benötigten Zeilen holt man sich vom alten Server und hängt sie an die Dateien auf dem neuen Server an. Am Ende müssen die entstandenen Dateien noch in das benutzte Datenbank-Format umgewandelt werden:

/usr/lib/mailman/bin/genaliases

oder man wartet bis mailman das selber macht.

Danach kann man dann vorsichtshalber mailman neu starten.

Falls es Probleme mit der URL für die Liste gibt, so ist wichtig zu wissen, dass die Listenkonfiguration in der Datei:

/var/lib/mailman/lists/<listenname>/config.pck

steckt. Diese Datei kann man z.B. mittels

withlist -l -r fix_url <listname> -u mailman.yyy.com

bearbeiten.

 

Weitere Hinweise unter:

Gelegentlich kann es sinnvoll sein die Passworteingabe beim SSH-Login zu vermeiden. Wenn man den SSH-Login z.B. aus einen Script heraus vornehmen will oder wenn andere Nutzer das Passwort auf dem Server ändern können.

In solch einem Fall kann man mit vorab ausgetauschten Schlüsseln arbeiten.

Dazu meldet man sich einmal normal per SSH- mit Passwort an:

ssh benutzer@server

Das kann auch schon lang vorher einmal geschehen sein. Dann erzeugt man sich sein Schlüsselpaar:

 ssh-keygen -t rsa

Auf eine Passphrase kann man verzichten, wenn man den Zugang für ein Script benötigt.

Es werden hiermit zwei Schlüsseldateien im Ordner .ssh erzeugt:

  • id_rsa
    das ist der private Schlüssel den man nicht weitergegeben darf
  • id_rsa.pub
    das ist der öffentliche Schlüssel, den wir auf den Zielrechner übertragen

An einfachsten kann man mit folgendem Befehl den Schlüssel in einem Rutsch übertragen:

 cat .ssh/id_rsa.pub | ssh benutzer@server 'cat >> .ssh/authorized_keys'
Veröffentlicht unter linux.

Auf meinem Server war die letzte Aktualisierung auf Version 8.1.x schon vor längerer Zeit. Mir war nicht klar, wie weit ich mit den Aktualisierungen kommen würde. Die Version 10.0.x läuft anscheinend nur noch mit PHP7.x.

Die Aktualisierung bis auf 9.1.5 habe ich mit folgenden Etappen vorgenommen:

  • Version 8.2.11
  • Version 9.0.9
  • Version 9.1.5

Bezogen habe ich die Archive von https://owncloud.org/changelog/ .

Der erste Schritt war relativ problemlos.

cd mein-onwncloud-verzeichnis
mv httpdocs httpdocs.81
tar xvfj owncloud-8.2.11.tar.bz2
cp -a httpdocs.81/config owncloud
mv owncloud httpdocs
chown -R wwwrun.www httpdocs
cd httpdocs
sudo -u wwwrun php occ upgrade

Das Update deaktiviert immer die Apps für Kalender und Kontakte.

Die weiteren Schritte erfolgen analog, aber ab 9.0 muss man wirklich aufpassen, das man nicht alte Daten im httpdocs-Verzeichnis liegen hat. Vorher hatte ich immer einfach die neuen Dateien in das Verzeichnis hinein kopiert, das lief dann aber nicht mehr. Der oben beschrieben Weg klappt aber weiterhin.

Ich musste auf meinem alten SuSE-System den erlaubten Speicher erhöhen in der

/etc/php5/cli/php.ini

Dann musste ich für MySQL die Blockgröße erhöhen in der /etc/my.cnf

max_allowed_packet=256M

Vorher brach das Upgrade-Tool von 9.0.9 immer wieder ab. Zusätzlich wurde über unzulässige Dateien gemeckert.

Es stellte sich heraus, dass vier Dateien gelöscht werden mussten, es war aber mein Ordner für die Owncloud-Dateien fast vollständig geleert worden. Das habe ich erst einmal ignoriert.

Das Upgrade auf 9.1.5 lief dann problemlos.

Zum Glück hatte ich das komplette Datenverzeichnis datadirectory gesichert, das Update hatte es mir gelöscht. Ich habe dann diese Dateien einfach wieder an ihren Platz kopiert und im Owncloud Web-Frontend neu prüfen lassen, danach war alles ok.

Was mir noch auffällt ist die Tatsache, dass Owncloud meldet, es hätte keine Internetverbindung. Auch zusätzliche Apps kann ich aus der Oberfläche heraus nicht installieren, auch Updates werden nicht angeboten.

Ich habe gelesen, dass das an einer defekten Curl-Version liegt. Naja, ich muss den kompletten Server sowieso mal aktualisieren.

Was mich etwas wundert ist die Tatsache, dass sich anscheinend die Kalender-Links etwas geändert haben, von caldav zu dav im Pfad. Meine Synchronisation klappt aber trotzdem, also werde ich das erst einmal nicht weiter verfolgen.

Da der Zugriff auf das Mailsystem auch immer häufiger mobil erfolgt scheint mir eine Verschlüsselung der Verbindung unvermeidlich. Dazu muss man in die Konfiguration von Postfix und Dovecot eingreifen. Ausgangspunkt für meine Konfiguration ist die Server-Beschreibung unter http://www.debacher.de/wiki/Root-Server_mit_OpenSuSE_13.2 .

letsencrypt

Da mir das System von letsencrypt sehr zusagt möchte ich die zugehörigen Zertifikate auch für das Mailsystem nutzen. Dazu habe ich mir einen virtuellen Apache-Server eingerichtet, der auf http://imap.meine-domain.de hört und ansonsten keinen Inhalt zur Verfügung stellt. Der virtuelle Server ist nur für die Erstellung und Verlängerung der Zertifikate wichtig.

Hierfür habe ich mir eine letsencrypt.ini angelegt:

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

# allgemeine Angaben
email = <name>@<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 = imap.debacher.de, smtp.debacher.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/imap.debacher.de/httpdocs/

Dann mittels

/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/imap.debacher.de/letsencrypt.ini

das Zertifikat erzeugt.

Dovecot

Für Dovecot müssen dann folgende Informationen in der Konfigurationsdatei stehen:

protocols = imap pop3 lmtp sieve
ssl = yes 
ssl_cert = </etc/letsencrypt/live/imap.debacher.de/fullchain.pem 
ssl_key = </etc/letsencrypt/live/imap.debacher.de/privkey.pem

Nach einem Neustart greift Dovecot dann auf das Zertifikat zu.

Abfragen kann man das Zertifikat dann mittels:

openssl s_client -connect imap.debacher.de:pop3s

oder

openssl s_client -connect imap.debacher.de:imaps

oder

openssl s_client -connect imap.debacher.de:smtp -starttls smtp

Postfix

Für Postfix muss etwas mehr gemacht werden. Wir haben ja zwei Richtungen zu beachten, Postix kann als Client und als Server dienen. Wenn er Mails an andere Rechner abliefert, dann ist er Client (smtp_…), ansonsten Server (smtpd_…).

Ich habe an die Konfigurationsdatei /etc/postfix/main.cf folgende Zeilen angehängt:

# tls config
smtp_tls_note_starttls_offer = yes

# eingehende Verbindungen
smtpd_use_tls = yes
smtpd_enforce_tls = no
# Obiges kann zusammengefasst werden zu smtpd_tls_security_level=may
smtpd_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3
#tls_random_source = dev:/dev/urandom
#tls_random_prng_update_period = 3600s

# ausgehende Verbindungen
smtp_use_tls = yes
smtp_enforce_tls = no
# Obiges kann zusammengefasst werden zu smtp_tls_security_level=may
smtp_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem
smtp_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols=!SSLv2, !SSLv3

Nun muss noch in der Datei /etc/postfix/master.cf eine Zeile auskommentiert werden:

tlsmgr unix - - n 1000? 1 tlsmgr

Thunderbird

Etwas mehr Aufwand bedeutet es den Nutzern der eMail-Domain die Konfiguration ihrer Mail-Clients zu beschreiben. Zumindest für Thunderbird gibt es eine genial einfache Lösung dafür, Danke an Lukas Thiel für den Hinweis.

Thunderbird unterstützt eine Autokonfiguration. Für die großen Anbieter greift es dazu auf eine eigene Datenbank zu, als kleiner Anbieter kann man die notwendigen Informationen nach folgender Anleitung erstellen: https://developer.mozilla.org/de/docs/Mozilla/Thunderbird/Autokonfiguration.

Der Anleitung folgend habe ich mir im Webserververzeichnis httpdocs meiner Domain eine Datei .well-known/autoconfig/mail/config-v1.1.xml angelegt mit folgendem Inhalt:
autoconfig1

Thunderbird sucht beim Anlegen einer neuen Mailadresse nach dieser Datei in der zugehörigen Domain. Wenn die Datei gefunden wird, dann konfiguriert sich das Mailprogramm ganz automatisch nach diesen Einstellungen.

Für den Fall, dass die automatische Konfiguration nicht möglich ist findet sich eine Konfigurationsbeschreibung unter http://www.debacher.de/ublog/2016/10/thunderbird-konfigurieren/.

In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:

2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>

Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:

2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Links

Bei den neuen Ubuntu-Versionen ist anscheinend kein Oracle-Java mehr dabei. Das ist nicht weiter schlimm, da das Oracle-Java nicht wirklich installiert werden muss, es langt, wenn man die Archive an einem geeigneten Ort entpackt.

Es mach aber Sinn diese Version in die alternatives Verwaltung einzubinden.

Hat man also das Oracle-Java im Pfad /opt/oracle/jre entpackt, dann muss man es noch in das System einbinden mittels:

sudo update-alternatives --install "/usr/bin/java" "java" "/opt/oracle/jre/bin/java" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/opt/oracle/jre/bin/javaws" 1

Aktivieren kann man es nun mittels:

sudo update-alternatives --set "java" "/opt/oracle/jre/bin/java"
sudo update-alternatives --set "javaws" "/opt/oracle/jre/bin/javaws"

oder über

sudo update-alternatives --config java

Hier kann man dann die gewünschte Version auswählen.

Weitere Hinweise unter:

  • https://wiki.ubuntuusers.de/Java/Installation/Oracle_Java/Java_8/
  • https://wiki.ubuntuusers.de/Java/Oracle_Java/

Aus alter Gewohnheit läuft man Arbeitsplatzrechner noch mit einem 32-Bit Ubuntu. Das möchte ich ändern und habe testweise ein 64-Bit Ubuntu 16.04 installiert.

Nun habe ich eine Anwendung, für die ich kein aktuelle Download-Verzeichnis kenne und für die ich keine 64-Bit Version bekommen kann. Diese Anwendung ist der PDF-Editor Cabaret Stage.

Im Prinzip lässt sich auch ein 32-Bit Java auf einem 64-Bit Linux installieren. Dazu holt man sich bei Oracle einfach die entsprechende Version, z.B. jre-8u102-linux-i586.tar.gz . Dieses Archiv kann man dann z.B. im Verzeichnis /opt entpacken. Ich habe das entstandene Verzeichnis dann etwas umbenannt, so dass mein Java unter /opt/jre32 erreichbar ist.

Im Startprogramm cabaretstage.sh habe ich dann die Zeile mit dem eigentlichen Programmaufruf erweitert zu:

/opt/jre32/bin/java -classpath "$MY_CLASSPATH" -Xms64m -Xmx256m com.cabaret.claptz.stage.main.StandardStage $*

Dadurch wird das systemweit installierte Java überhaupt nicht gestört.

Leider gibt es nun das Problem, dass im Zusammenhang mit dem Java AWT eine Reihe von 32-Bit Bibliotheken benötigt wird. Zum Glück kann man die auch auf einem 64-Bit System zusätzlich installieren.

sudo apt install libgtk2.0-0:i386 libxtst6:i386 libfreetype6:i386 libxrandr2:i386 libglib2.0-0:i386 libpulse0:i386 libgdk-pixbuf2.0-0:i386
sudo apt install libnspr4:i386 gtk2-engines-murrine:i386 libgail-common:i386 gnome-session-canberra:i386
sudo apt install libfreetype6:i386 unity-gtk3-module:i386 unity-gtk2-module:i386 atk-bridge2.0-0:i386 libcurl3:i386

Es werden dann noch einige Pakete aufgrund von Abhängigkeiten installiert.

dpkg-query -l *:i386

liefert bei mir als Ergebnis insgesamt 169 Pakete.

Dann noch

cd /usr/lib/i386-linux-gnuln -s libfreetype.so.6 libfreetype.so
Veröffentlicht unter linux.

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