SSL intern und extern

Infrastruktur
1

Hi Jörg, Stefan, Max, Michael,

in der Tat will ich generisch wissen, wie es läuft, nicht unbedingt, weil meine cloud jetzt Probleme macht. In Zukunft sollte mal geklärt sein, wie die lmn aufgesetzt wird: intern - kein Problem, aber da sind die Zertifikate halt selbstsigniert und Dienste nach außen brauchen letsencrypt-Zertifikate (ich denke das funktioniert schon einigermaßen jetzt).
Die Alternative ist letsencrypt für alle Zertifikate zu nutzen und dann sollte klar sein unter welchen Rahmenbedingungen das läuft:

Ok. ersteres war mir nicht richtig klar. letzteres wusste ich.

Szenario: ich nehme humbi.de, wenn ich eine externe Domäne meiner Schule meine und linuxmuster-net.lokal, wenn ich intern meine.
server.humbi.de - FQDN des Servers inkl. SSL-services: Schulkonsole/horde(https), imap+postfix, cups, ldaps, samba
cloud.humbi.de - FQDN des Cloudservers inkl. SSL-services: https
moodle.humbi.de - FQDN des Moodleservers inkl.: https
mail.humbi.de - FQDN des Mailservers falls imap+postfix oder alleine horde/roundcube ausgelagert wurden

ich weiß, letztere sind etwas konstruiert aber die ersten zwei Server zu haben ist gang und gäbe.

Gute Idee:

Dann habe ich mind. zwei Möglichkeiten:

  1. humbi.de auf unsere externe IP zeigen lassen und jeweils beide Namen im Zertifikat zu haben.
  2. server.humbi.de, cloud.humbi.de usw. beim DNS-Provider als aliase, die alle auf unsere externe IP zeigen (mehrere IPs macht es natürlich einfacher, aber das dürfte nicht die Mehrheit sein). Pound in IPFire verteilt die Anfragen auf die tatsächlichen Server. Ich hoffe das geht trotz SSL. Ich brauche möglicherweise mehrere SSL-Zertifikate, oder es klappt mit einem, der alle Namen drin hat.
  3. … es fällt mir nicht mehr ein, warum zefanjas Idee noch zu einer weiteren möglichkeit führen kann.

Huch, jetzt hab ich schon mein Problem:
Ich kann letsencrypt nur dann dazu bringen, für humbi.de und für server.humbi.de ein Zertifikat auszustellen, wenn sich beide auflösen lassen, d.h. andersherum: wenn ich nur einen dyndns- oder Belwue-Namen von außen habe, kann ich keine gültige letsencrypt-Zertifikate ausstellen.
Momentan heißt das für mich weiterhin (da ich nicht weiß, ob mir belwue mein server.humbi.de auflöst), dass ich ein Zertifikat für die externe Adresse ausstelle und das intern in die Browser “importieren” muss. Nicht so schön.

vG, Tobias

2

Ich formuliere mal noch ein einfacheres Szenario:

  1. Ich will von extern auf meine Cloud zugreifen: https://humbi.de/cloud - kein Problem
  2. ich will von intern auf meine Cloud zugreifen: https://humbi.de/cloud - hm, wenn ich in /etc/hosts die IP des Cloud servers nicht nur zu cloud.humbi.de mappe, sondern noch humbi.de, dann klappt auch noch lokal. Firefox macht das mit, mount.davfs auch noch.

Jetzt kommt das Problem: Ich will noch auf horde zugreifen. Horde liegt auf einem anderen Server. Von extern wird aber https://humbi.de/horde umgebogen. Von intern könnte ich das wieder nur lokal mit dem hack in /etc/hosts machen.

Oder: Die Schulkonsole: Anderer Server als der mit der Cloud, das Zertifikat ist aber auf humbi.de ausgestellt. Ich muss auf dem selben Client jetzt aber server.humbi.de:242 nehmen und das Zertifikat als Ausnahme hinzufügen. Firefox macht das mit, mount.davfs macht das nicht mit, soviel ich weiß.

Und ich glaube da hört es auf: Ich kann nicht Zertifikate für externe “Hostnamen” ausgeben, die intern in Wirklichkeit eine Domäne sind. Sobald ich mehr als einen Server habe, brauche vermutlich auch mehr als einen von außen erreichbaren Hostnamen.

vG, Tobias

3

Hi,

k.A. ob meinen Problemen jemand gefolgt ist:

  1. ich habe belwue ohne Probleme um einige subdomains gebeten, alles aliase auf die domäne (z.B. server.humbi.de -> humbi.de)
  2. ich kann jetzt mit linuxmuster-dehydrated ein letsencrypt-Zertifikat für alle relevanten hostnamen, die hinter meiner IP von außen stehen erstellen (inkl. der domäne selbst z.B. siehe: https://humboldt-gymnasium.ka.schule-bw.de)
  3. jetzt kann ich auf die Schulkonsole von außen wie innen mit einem gültigen Zertifikat zugreifen (von BLAU hab ich noch nicht probiert), d.h. (Beispiel) https://server.humbi.de:242 liegt in meinem Client als Lesezeichen und würde auch von zu Hause funktionieren bei entsprechender Portweiterleitung. Genauso funktioniert https://cloud.humbi.de von innen (und wenn ich pound noch dazu kriege, auch von außen).

Ein gültiges LE-Zertifikat für slapd/cyrus/apache2 auf dem linuxmuster.net-Server und auf den anderen Servern, die ich per SSL ansprechen will (cloud/horde/younameit)
Ich glaube, das ist zufriedenstellend.
Grüße, Tobias
(ps.“Gut” wäre, wenn ich den coova noch dazukriege das Zertifikat …)

4

Hallo,
ich habe die Artikel jetzt mehrmals gelesen und habe noch einige Fragen, da ich auch für einen Unifi-WLAN Controller gerne ein Zertifikat hätte. Der Linuxmuster-Server hat bei mir schon ein Lets Encrypt Zertifikat und die Schulkonsole geht wunderbar. Unsere Domain ist bei INWX und ich habe über alle Subdomains Kontrolle.

Holt sich bei der oben genannten Lösung der Linuxmuster Server auch Zertifikate für Subdomains, die auf andere Server zeigen?

Müsste man dann das Zertifkat von Hand rüber kopieren?

Welche Subdomains muss ich wo in den apaches hinterlegen?

Viele Grüße
Manuel

5

Hallo Tobias,

Habe ich auch gemacht. Habe neben meine-schule.de auch noch server.meine-schule.de und cloud.meine-schule.de als subdomains freischalten lassen. Beide zeigen bei Aufruf von extern auf meine-schule.de .

Ich habe nun zwei Fragen: 1. Wie bekomme ich die neuen Adressen ins Zertifikat rein? Muss ich dazu in der Konfigurationsdatei von linuxmuster-dehydrated zu let’sencrypt einfach die beiden weiteren Domains zu der anderen Domain dazu schreiben?
2. Wie bekomme ich die Weiterleitung von cloud.meine-schule.de auf den Cloud-Server hin? Meine Nextcloud läuft auch auf einer separaten virtuellen Maschine.

VG Daniel

6

Scheine es hinbekommen zu haben.
Zu den Domains im Zertifikat: Ich habe einfach probiert, bis es passte (alle Domains in eine Zeile)
Zur Weiterleitung: Pound im IPFire nach folgender Anleitung installiert:

VG Daniel

7

Klingt gut! Ich frage mich aber nicht zum ersten Mal, ob alle Settings, die man jetzt im IPFire einträgt, später mit lml 7.0 und OPNSense (?) auch laufen werden? Das frage ich mich umso mehr, je mehr man vom Standard abweicht und z.B. Zusatz-Plugins wie POUND installiert. Weiß da schon einer genaueres?

Ich frage auch deshalb, weil hier etwas anderes steht als hier. Wohin geht die Reise?

8

Hallo Michael!

Es sieht gerade nach OPNsense aus.
Hab es im wiki angepasst.

Gruß - Rainer

9

Danke für die Info – dann stellt sich aber umso mehr die Frage: Wird man seine Settings exportieren/importieren können? Oder ist das noch Zukunftsmusik?

Ich habe mir die VirtualBox von OPNSense mal angesehen. Läuft ja ganz gut aber man muss sich völlig neu orientieren im Vergleich zum IPFire. Könnt ihr die Gründe für die Umstellung evtl nochmal unter “Was gibt es Neues” oder so posten?

10

Hallo Michael,

Klingt gut! Ich frage mich aber nicht zum ersten Mal, ob alle Settings,
die man jetzt im IPFire einträgt, später mit lml 7.0 und OPNSense (?)
auch laufen werden?

also ich würde sagen:
Die Standard-LMN Settings werden sicher sofort nach einer Migration LMN
6 --> LMN 7 wieder vorhanden sein.

Aber…

Das frage ich mich umso mehr, je mehr man vom
Standard abweicht und z.B. Zusatz-Plugins wie POUND installiert.

… wie immer:
Out of the box werden eigene Anpassungen erst mal nicht mehr vorhanden
sein / funktionieren.

Woher soll das Migrationsskript dein Setting kennen, wenn es nicht das
Standardsetting ist. Pound gehört sicher nicht dazu.

Auch ich nutze Pound. Aber das wird man eh anpassen (oder durch eine
entsprechende andere Lösung auf der neuen Firewall ersetzen) müssen:

z.B. verzweigt bei mir Pound momentan für https://unserserver.de/horde3
auf den LMN-Server, also auf die 10.16.1.1

Bei LMN 7 wird der Mailserver nicht mehr auf dem LMN Server laufen, also
muss man das Setting ohnehin anpassen / neu machen.

Viele Grüße
Steffen

11

Hallo Manuel,

Der Server kann sich auch die Zertifikate für andere Subdomains holen. Bei mir deshalb, weil port 80 immer auf den Server zeigt, d.h. server.bla.de, cloud.bla.de und bla.de landen (wenn man http also port 80 nimmt) immer beim server-apache.

Dann musst du tatsächlich die Zertifikate auf die anderen Server kopieren und dafür sorgen, dass https-Anfragen eben auf den richtigen Servern beantwortet werden. Dazu benutze ich “pound” im IpFire, siehe hier: https://www.linuxmuster.net/wiki/anwenderwiki:webapps:ipfire_pound .
Der IPFire (vor allem der) muss dafür auch das Zertifikat bekommen.
Das kopieren “per Hand” macht bei mir ein hook-skript in linuxmuster-dehydrated, hab die URL grade nicht parat.

Die subdomains musst du für den Zertifizierungsprozess nicht im apache des servers hinterlegen, ich denke auch überhaupt nicht in irgendeiner apache-config, außer du hast z.B. cloud.server.de und mail.server.de beide auf einem eigenen Server aber nicht auf dem linuxmuster-net server.

VG, Tobias

12

Hi Ihr,

Warum opnsense statt ipfire kann ich heute nicht beantworten. Es wird triftige Gründe geben.
ich habe aber: relayd (https://github.com/opnsense/plugins/blob/master/net/relayd/pkg-descr) gefunden, das als Ersatz für pound gelten könnte. Ausprobieren geht über studieren… https://calomel.org/relayd.html

VG, Tobias

13

Hallo Tobias,
vielen Dank. Ich werde das bei Gelegenheit mal testen und dann hier eine Rückmeldung hinterlassen.
viele Grüße
Manuel