Meine (ungeprüfte) Lösung wäre, das Zertifikat in /etc/ssl/certs/ zu kopieren (Welt-Lesbar), an das zusammengefasste ca-certificates.crt anzuhängen und den Apachen zu restarten.
Es könnte sein, dass der Apache seine Zertifikate woanders herholt, das kann ich grad nicht testen, aber wo immer er sie liest, da sollte’s hin.
… also müsste man z.B. ein LE-Zertifikat, das auf den Server in der DMZ ausgestellt wurde, an diese Stelle kopieren? Damit wäre das Konzept mit dem HAProxy und LE über den Haufen geworfen, oder??
nein, ein LE Zertifikat hat ein bereits als vertrauenswürdig eingestuftes root-Zertifikat, was bereits installiert ist.
Meine Lösung betrifft sogenannte self-signed Zertifikate, wo also issuer und subject gleich lauten.
na gut – wie hast du sie erzeugt?
Oh… Das habe ich seit LE lange nicht mehr 
openssl x509 -req -days 365 -in SUBJECT.csr -signkey SUBJECT.key -out SUBJECT.selfsiged
Davor machst du ein csr (certificat signing request) wie du es mit LE machst (SUBJECT ersetze ich entsprechend). Aber das solltest du ja für deinen LDAP getan haben, oder?
Ich habe das nicht getan … vielleicht wird’s bei der Installation automatisch gemacht? Wer kann das beantworten??
Und vielleicht erklärt das auch die Probleme, die ich im Moment mit ldaps://-Abfragen habe??
Ich hatte eigentlich (laut Anleitung von Holger @baumhof ) versucht, moodle mit dem AD zu verbinden. Das soll über Port 636 laufen, liefert mir aber immer nur
" Das LDAP-Modul kann keine Serververbindung herstellen: Server: ‚ldaps://server.linuxmuster.meine-schule.de:636‘, Connection: ‚Resource id #536‘, Bind result: ‚‘
Als ldap Server hast du vermutlich slapd. Der hat eine Konfiguration in /etc/ldap/slapd.d, allerdings im .ldif format.
Ich würde erstmal schauen, wo der Knabe lauscht: netstat -lptun|grep slapd sollte zeigen, ob er 389 (ldap) oder 636 (ldaps) anbietet oder noch weitere ports.
Dann kannst du per echo -n | openssl s_client -CApath /etc/ssl/certs/ -connect localhost:636 schauen, was er für ein Zertifikat anbietet. Das würde ich erstmal von der Box schauen, wo der ldap-Server läuft und dann auf den Boxen, die dahin verbinden sollen. Da sollte natürlich immer dieselbe Antwort kommen, ansonsten hast du ein Firewall-Problem.
Als nächstes kannst du per
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=config'
die config auslesen - da sollte unter olcTLSCertificateFile der Name der Zertifikats-Datei erscheinen (und entsprechend auch die Datei mit dem Schlüssel).
vermute ich nicht … v7 macht ja alles anders 
OpenLDAP ist jedenfalls als „Zusatz-Server“ gestrichen – stattdessen liefert Samba4 jetzt selbst das AD.
Auf Client und Server erhalte ich jeweils das gleiche Zertifikat; denke aber nicht, dass es das LE-Zertifikat ist…
Nein, das ist ein offizielles für „aussen“, denke ich.
Was kommt denn da? Diesen Base64-Teil (zwischen den -----(BEGIN|END) CERTIFICATE----- inkl den ----Zeilen), den du da siehst kannst du in eine Datei packen und dem Apachen geben…
Ah verdammt: Eins vergesse ich immer. Das ganze braucht natürlich korrekte Server-Namen. Wenn alles über die IP läuft, geht natürlich kein SSL oder TLS. Der Name ist der cn im Zertifikat.
funktioniert nicht: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
Nur so als Vermutung:
[root@server:/etc/ldap]$ cat ldap.conf
Da steht:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Kann es sein, dass man das DA auf das LE-Zertifikat umbiegen muss??
Das ist für den Client, nicht den server. Da steht wo er die Zertifikate sucht.
Ich hab grad geschaut: LDAP / AD aus Samba wird (tata!) in smb.conf konfiguriert. Da stehen die Direktiven:
tls enabled = yes
tls keyfile = /.../key.pem
tls certfile = /.../cert.pem
tls cafile = /.../root.pem
Es würde mich wundern, wenn LE da eine Rolle spielt, da ja der Samba-Server nur Intern genutzt wird und mit LE das nicht möglich ist (naja, kommt auf den cn an, klar…).
Was sagen die openssl-Befehle, die ich oben geschrieben habe?
Also diese Zertifikate können einen ja echt bekloppt machen … 
Ich habe für das interne Netz (aus diversen Gründen) einen FQDN gewählt, der auch extern auflösbar ist. Von daher habe ich auch ein LE-Zertifikat, das auf meinen Server ausgestellt werden konnte. Im LAN funktioniert das: https://server.linuxmuster.meine-schule.de liefert eine gesicherte Verbindung („grünes Schloss“)
Die Verbindung klappt, ich bekomme ein Zertifikat, das aber wesentlich kürzer als das LE-Zert ist. Nun habe ich in die smb.conf geschaut und siehe da:
tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pemDas sind also scheinbar alles die selbst erzeugten Zertifikate, die beim Setup erzeugt wurden!?!
Eigentlich gehört dieser Thread ab #13 ans Ende von Nochmal ldaps -- Abfragen auf Port 636 und 3269 (HowTo) - #4 von Michael
Irgendwas ist da durcheinander geraten…
Und welchen issuer und cn hat es?
Gib das dem Apachen (und jedem andren client) als vertrauenswürdigem Zertifikat (also vermutlich in /etc/ssl/certs), dann sollte’s gehn.
Oder stell die Einstellungen da um, offizielle LE Zertifikat zu ziehen, wenn die Namen stimmen (cn muss in den client-Einstellungen genutzt werden und zu der IP führen).
naaa… eigentlich ist das alles ganz einfach
ja, „eigentlich“ … ich finde es im Moment eher … äh, … „unübersichtlich“.
Unter der alten Version 6.x haben viele die Option TLS_REQCERT never gesetzt – könnte mir denken, dass das genau aus diesem Grund war: wenn man den Server über Port 636 abfragen wollte und kein signiertes Zertifikat vorweisen konnte, kam die Verbindung nicht zustande, richtig?
Jetzt habe ich unter v7 diese Files auf dem Server:
-rw-r--r-- 1 root ssl-cert 5528 Nov 22 08:11 server.cert.bundle.pem
-rw-r----- 1 root ssl-cert 1257 Sep 14 16:28 server.cert.pem
-rw-r----- 1 root ssl-cert 1033 Sep 14 16:28 server.csr
-rw------- 1 root ssl-cert 1675 Sep 14 16:28 server.key.pemund diese LE-Zertifikate auf der FW:
-rwxr-x--- 1 root wheel 1648 Nov 21 15:57 ca.cer*
-rwxr-x--- 1 root wheel 3933 Nov 21 15:57 fullchain.cer*
-rwxr-x--- 1 root wheel 2285 Nov 21 15:57 server.linuxmuster.meine-schule.de.cer*
-rwxr-x--- 1 root wheel 957 Nov 21 15:57 server.linuxmuster.meine-schule.de.conf*
-rwxr-x--- 1 root wheel 1700 Nov 21 15:57 server.linuxmuster.meine-schule.de.csr*
-rwxr-x--- 1 root wheel 220 Nov 21 15:57 server.linuxmuster.meine-schule.de.csr.conf*
-rwxr-x--- 1 root wheel 3243 Nov 21 11:32 server.linuxmuster.meine-schule.de.key*Ich nehme stark an, dass ich den LE-Krempel rüberholen und die selbst erzeugten Zertifikate ersetzen kann (wenn ich weiß, welche Datei welcher entspricht…)
du hast immer noch nicht gesagt, was cn und issuer von dem selfsigned sind. aber nehmen wir an, dass du die nicht nutzen willst, siehts wohl nach dem kopieren so aus in der config:
tls enabled = yes
tls keyfile = /.../se....key
tls certfile = /.../ser...cer
tls cafile = /.../ca.cer
Allerdings wundert mich noch, dass LE eigentlich eine Kette von 3 Teilen hat, nicht zwei:
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = emdete.de
verify return:1
Dazu müsste man die ca.cer sich mal anschauen.
ich nehme an, dass du das hier meinst:
-----END CERTIFICATE-----
subject=O = Meine Schule, OU = LINUXMUSTER, CN = server.linuxmuster.meine-schule.de, subjectAltName = server.linuxmuster.meine-schule.de
issuer=O = Meine Schule, OU = LINUXMUSTER, CN = LINUXMUSTER.MEINE-SCHULE.DE, subjectAltName = LINUXMUSTER.MEINE-SCHULE.DE
---Das Kopieren der „richtigen“ Zertifikate kommt mir aber sinnvoller vor??! Da ich aber nicht weiß, welche anderen Dienste noch auf /etc/linuxmuster/ssl zugreifen und ein gültiges Zertifikat erwarten, ist es vermutlich noch sinnvoller, die alten Namen auf dem v7-Server beizubehalten…?!!
übrigens: Das hier gibt’s auch noch auf dem v7-Server:
-rw-r----- 1 root ssl-cert 1359 Sep 14 16:28 cacert.crt
-rw-r----- 1 root ssl-cert 1359 Sep 14 16:28 cacert.pem
-rw-r----- 1 root ssl-cert 1812 Sep 14 16:28 cacert.pem.b64
-rw-r----- 1 root ssl-cert 41 Sep 14 16:28 cacert.srl
-rw------- 1 root ssl-cert 1766 Sep 14 16:28 cakey.pem?? OPNSense hat das für mich geholt … 
Klar, wo du die Zertifikate hast, kannst du sie nutzen, wenn die Namensauflösung stimmt. Probieren geht über studieren 
Ja, bei den beiden Dateien server.cert.pem und server.key.pem kann ja nicht viel passieren … bin nur unsicher, was cacert.pem angeht, da dort ja noch mehr Dateien liegen. Wenn ich nur die eine Datei des Paketes ersetze, passt das nach meinem Verständgnis nicht mehr zusammen, oder?
Also cacert,crt, cacert.pem.b64, cacert.srl und cakey.pem habe ich bei den LE-Zert. nicht
ein cert signiert ein konkretes anderes cert oder einen key. wenn du die mischst, funktioniert’s nicht mehr.
wenn du die einen dateien auf den anderen rechner kopierst, wird ja nichts ueberschrieben. dann stellst du die konfig um und startest den samba server wieder.
die originalzeilen kannst du ja auskommentiert drin lassen, dann kannst du schneller zurückrollen.
wenn du unsicher bist, was da wie zusammengehört, kannst du ja mal schauen, wie das da im haproxy konfiguriert ist.
Ja, in der .conf der OPNSense steht (nachvollziehbar):
Le_RealCertPath='... cert.pem'
Le_RealCACertPath='... chain.pem'
Le_RealKeyPath='.... private.key'
Le_ReloadCmd=''
Le_RealFullChainPath='.... fullchain.pem'Das ist nachvollziehbar und wird dann scheinbar passend umbenannt. Aber auf dem v7-Server sind da neben die server*-Files eben auch noch die ganzen cacert.*-Files. Weiß der Geier, wo die herkommen …?!?