Wechsel von SSL-Kaufzertifikat auf Let's Encrypt

crazy-to-bike · 7. Mai 2019 um 15:49

Hallo,

noch haben wir ein gekauftes Zertifikat auf server.schuldomain.de

Ich möchte allmählich mal den Umstieg auf Let’s Enctypt planen.

Bislang habe ich eine interne „Startseite“ unter /var/www liegen, Nextcloud liegt unter /var/www/nextcloud, analog andere Dienste je in ihrem Unterordner.

Mit /etc/apache2/sites-enabled/000-default.conf

<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    Header always set Referrer-Policy no-referrer
    Redirect 301 /.well-known/carddav /schulcloud/remote.php/dav
    Redirect 301 /.well-known/caldav /schulcloud/remote.php/dav
     </IfModule>

ServerName Nextcloud

<Directory /var/www/nextcloud/>
AllowOverride All

Bei den gelesenen Anleitungen heißt es immer, man solle die Domain(s) als Virtual Host anlegen.

Also für die (Sub)Domain nextcloud.schuldomain.de ein Verzeichnis /var/www/nextcloud.schuldomain.de
und
/etc/apache2/sites-available/nextcloud.schuldomain.de

<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName nextcloud.schuldomain.de
ServerAlias nextcloud.schuldomain.de
DocumentRoot /var/www/nextcloud.schuldomain.de
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

<Directory /var/www/nextcloud.schuldomain.de/>
AllowOverride All

Imho sollte ich das aber doch so lassen können wie es ist, wenn ich nur eine Subdomain habe (wobei ich natürlich drüber nachdenken könnte, von https://server.schuldomain.de/nextcloud auf https://nextcloud.schuldomain.de zu wechseln), oder kommt cerbot damit dann nicht klar, wenn ich mit

certbot --apache -d server.schuldomain.de

das Zertifikat beziehe?

Was ich in der zitierten Anleitung (Tutorial: Apache & Let’s Encrypt für SSL-Schutz – Webhosting Vergleich) auch komisch finde, dass da <VirtualHost *:80> steht statt <VirtualHost *:443> ?!?

Irgendwas habe ich zwar im Hinterkopf, dass der Server per http (Port 80) erreichbar sein muss…

Wobei, das wäre eh ein Problem, ist er nämlich nicht.

Viele Grüße
Steffen

luftikuss · 7. Mai 2019 um 16:37

Hi Steffen,
ich stehe vor der gleichen Aufgabe und möchte meine Nextcloud let’sencrypten. Ein Problem ist, dass certbot keine Subdomains akzeptiert.
Folglich wirst du mit server.schuldomain.de nicht weit kommen - fürchte ich.

Gruß
Roland

crazy-to-bike · 7. Mai 2019 um 19:06

Hallo Roland,

ich stehe vor der gleichen Aufgabe und möchte meine Nextcloud
let’sencrypten. Ein Problem ist, dass certbot keine Subdomains akzeptiert.
Folglich wirst du mit server.schuldomain.de
http://server.schuldomain.de nicht weit kommen - fürchte ich.

hm… aber wenn ich richtig erinnere, haben hier doch etliche so was wie
cloud.schuldomain.de in Verwendung?!?

schuldomain.de und www.schuldomain.de sind halt schon für die Homepage
weg, und die liegt nicht in der Schule sondern bei Belwü.

Also wie löst man das dann?

Viele Grüße
Steffen

crazy-to-bike · 7. Mai 2019 um 19:07

Hallo Roland,

ich stehe vor der gleichen Aufgabe und möchte meine Nextcloud
let’sencrypten. Ein Problem ist, dass certbot keine Subdomains akzeptiert.
Folglich wirst du mit server.schuldomain.de
http://server.schuldomain.de nicht weit kommen - fürchte ich.

hm… aber wenn ich richtig erinnere, haben hier doch etliche so was wie
cloud.schuldomain.de in Verwendung?!?

schuldomain.de und www.schuldomain.de sind halt schon für die Homepage
weg, und die liegt nicht in der Schule sondern bei Belwü.

Also wie löst man das dann?

Viele Grüße
Steffen

tjordan · 7. Mai 2019 um 19:49

Hallo Steffen,

mittlerweile kann LetsEncrypt auch Wildcard-Zertifikate erstellen.

Du beantragst also für *.schuldomain.de das Zertifikat und sicherst damit alles ab. Funktioniert sehr elegant auch mit einem nginx als Reverse Proxy.

Viele Grüße
Thomas

Tobias · 7. Mai 2019 um 20:15

Hi Steffen,hi Roland

certbot würde ich schon gleich mal gar nicht nehmen. Installiere doch linuxmuster-dehydrated und suche den entsprechenden Thread hier im ask.
Ich habe zwar damit noch nicht die Wildcard-Zertifikate ausprobiert, aber ich verwende sehr wohl cloud.schule.de sowie server.schule.de usw. und im Prinzip rufe ich dehydrated für jede Domäne extra auf. Falls das mit den Wildcard-Zertifikaten irgendwo klemmt, kannst du immer auf diese Variante zurück.

Von außen muss halt nur die entsprechende Seite aufrufbar sein, z.B. http://server.schule.de/.well-known/acme/anyfile_that_lies_here
damit LE das zertifiziert.

immer erst mit „staging“ testen, nicht vergessen.

(die dritte Variante, dass du alle deine Domänen in ein zertifikat packst habe ich lange auch gemacht, das ging auch, da gilt weiterhin obiges, dass http://server.schule.de/.well-known/acme/… und http://cloud.schule.de/.well-known/acme/… usw zugreifbar sein muss. Da kam dann ein Zertifikat dabei raus, das für alle angegebenen Domänen funktionierte. Jetzt würde ich das nicht mehr machen: entweder Pro domäne ein eigenes Zertifikat (variante 1) oder ein Wildcard, wie Tjordan vorschlug.)

Vg, tobias

ironiemix · 9. Mai 2019 um 06:08

Hallo,

un der Vollständigkeit halber: Bei neueren ubuntu und debian Installationen kann man einfach das Paket “dehydrated” installieren. linuxmuster-dehydrated ist vor allem für den LMN6 Server gedacht. Selbstverständlich kann man mit letsencrypt subdomains bedienen.

Darüberhinaus gibt es noch acme.sh https://github.com/Neilpang/acme.sh, das wird bei Projekten der CT oft verwendet. Man muss also für so einfache Aufgabenstellungen keine viele MB große Certbot-Installation machen.

Auf einem meiner Server holt dehydrated Zertifikate für >40 verschiedene “sub”-Domains, das klappt ohne Probleme und ohne Wildcard.

Wildcard ist IMHO v.a. dann interessant, wen ich Zertifikate für Rechner benötige, die nicht von letsencrypt für die Challenge erreichbar sind, denn damit kann ich ein Zertifikat beziehen, das für alle meine Subdomainnamen gilt, das ich dann im Intranet verteile.

VG

FRank

crazy-to-bike · 9. Mai 2019 um 09:05

Hallo,

es ist halt kein LMN-Server sondern einfach ein Ubuntu 18.04-Server.

Dann kann ich dehydrated nicht nehmen, oder?

Und der Server muss für Let’s Encrypt auch auf Port 80 erreichbar sein, oder?

Vielehrer Grüße
Steffen

jrichter · 9. Mai 2019 um 10:26

Hallo Steffen,

klar kannst Du Dehydrated nehmen, nur halt vermutlich nicht das
Linuxmuster-Paket.

Für Dehydrated muss Port 80 nicht erreichbar sein, für Certbot schon. Es
kann aber auch eine permanente Weiterleitung auf Port 443 sein (das ist
meiner Meinung nach sowieso sinnvoller als Port 80 zu schließen).

Beste Grüße

Jörg

crazy-to-bike · 9. Januar 2020 um 14:18

Hallo,

nachdem es langsam dringlich wird, weil das gekaufte Zertifikat ausläuft, habe ich mich mal mit Dehydrated auseinandergesetzt. So wirklich viele und v.a. eindeutige Anleitungen finde ich da aber nicht. Am Vielversprechendsten sah mir das aus:

Hier stockt das Ganze aber:

Damit die Zertifizierungsstelle überprüfen kann, ob die Domain einem auch wirklich gehört, muss im Apache der wellknown Ordner für alle Domains freigegeben werden. Deshalb muss ein Alias gesetzt werden. Dafür folgende Apache Config anlegen:
/etc/apache2/conf-available/dehydrated.conf
Alias /.well-known/acme-challenge /usr/share/apache2/dehydrated
<Directory /usr/share/apache2/dehydrated>
        Options None
        AllowOverride None
        # Apache 2.x
        <IfModule !mod_authz_core.c>
                Order allow,deny
                Allow from all
        </IfModule>
        # Apache 2.4
        <IfModule mod_authz_core.c>
                Require all granted
        </IfModule>
</Directory>

Bei mir gibt’s kein /.well-known und demnach auch nix mit acme-challenge. Leider bleibt mir völlig unklar, wo ich das her kriege bzw. wie ich das anlegen muss ?!?

Viele Grüße
Steffen

crazy-to-bike · 9. Januar 2020 um 14:31

Hallo Jörg,

hm, bist du sicher?

At the moment you’ll need to have that location available over standard HTTP on port 80 (redirect to HTTPS will work, but the starting point is always HTTP!).

Viele Grüße
Steffen

crazy-to-bike · 9. Januar 2020 um 19:38

Hallo Tobias,

genau da hänge ich leider. Das mit dem .well-known gibt’s bei mir alles nicht und bislang bin ich einfach zu doof, da irgendeine Anleitung zu finden, die mir das so erklärt, dass ich raffe, was genau ich da einrichten / tun muss.

Zumindest bin ich der Ansicht, dass der Server auch bei dehydrated tatsächlich über Port 80 erreichar sein muss. Das wäre dann auch noch eine Baustelle, die sich spannend gestalten wird, ob und wann unser „Dienstleister“ die Weiterleitung in der Fritzbox auf die Reihe kriegt.

Viele Grüße
Steffen

Tobias · 14. Januar 2020 um 22:30

Hi Steffen,

crazy-to-bike:

Alias /.well-known/acme-challenge /usr/share/apache2/dehydrated
<Directory /usr/share/apache2/dehydrated>
        Options None
        AllowOverride None
       # Apache 2.x
        <IfModule !mod_authz_core.c>
                Order allow,deny
                Allow from all
        </IfModule>
        # Apache 2.4
        <IfModule mod_authz_core.c>
                Require all granted
        </IfModule>
</Directory>

Bei mir gibt’s kein /.well-known und demnach auch nix mit acme-challenge. Leider bleibt mir völlig unklar, wo ich das her kriege bzw. wie ich das anlegen muss ?!?

das „/.well-known“ ist der Alias, den du von außen ansteuerst, also der hintere Teil der URL. In der obigen Anweisung ist der Teil „/usr/share/apache2/dehydrated“ der, der auf dem Server im Dateisystem existieren muss und die richtigen Rechte haben sollte (www-data sollte lesen können).
VG, Tobias

crazy-to-bike · 16. Januar 2020 um 16:38

Hallo Tobias,

das ist schon klar, nur war in dem /usr/share/apache2/dehydrated eben nix drin und die Erstellung tat auch nicht. Ich dachte, da muss doch was von außen findbares drin liegen.
Aber inzwischen tut’s ja - seit Port 80 offen ist. Also alles gut.

Viele Grüße
Steffen