Htaccess Datei mit der lmn7

Oh… Das habe ich seit LE lange nicht mehr :wink:

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 :roll_eyes:
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 … :crazy_face:

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.pem

Das 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 -- Frage zu Abfragen auf Port 636
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 :wink:

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.pem

und 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…)

  • .csr ist der request, der ist unbedeutend für diesen Zweck.
  • .csr.conf unklar.
  • .conf kenne ich auch nicht, könnte ein config snipped für den apachen sein.
  • .key ist der private key.
  • .cer ist wohl das Zertifikat, genauso wie .cert.pem (pem ist das format in dem das da alles ist).
  • .cert.nundle.pem ist vermutlich die chain - fraglich, warum ein self-signed eine chain hat… hm.
  • ca.cer wird das X3 root cert von LE sein
  • fullchain.cer ist vermutlich car.cer + serv…cer (größe passt ja)

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.

1 Like

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 … :scream:

Klar, wo du die Zertifikate hast, kannst du sie nutzen, wenn die Namensauflösung stimmt. Probieren geht über studieren :slight_smile:

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 …?!?

Wunderlich, was das sein soll, wenn es auch Cert und CACert gibt. Im Grunde sollte eins von beidem ausreichen.

Wenn da mehr Dateien sind als nötig, nenne ich sowas Müll. Die ganze benamsung da gefällt mir nicht, weil sie nix aussagt. Warum das eine .pem heisst, der key, der im selben Format vorliegt aber nicht, ist mir schleierhaft. Generell ist .pem auch keine wichtige Info, weil das heute sowieso das gängige Format ist und „private“ auch nicht, weil eben ein Schlüssel immer „private“ ist.

Wenn du im Zweifel bist, kannst du eben nachschauen, was da in so einem Zertifikat steckt:

openssl x509 -noout -in <datei> -subject

Ich habe mal ein Script geschrieben, dass so einen Müll aufräumt und man dann schön am Dateinamen ablesen kann, was was ist. Leider muss man dann natürlich alle Konfigurationen anpassen.

… also ich ahne, dass der andere -von dir zuerst vorgeschlagene- Weg viel einfacher ist:
1.) echo -n | openssl s_client -CApath /etc/ssl/certs/ -connect localhost:636
2.) alles mit -----(BEGIN|END) CERTIFICATE----- kopieren und
3.) an /etc/ssl/certs/ca-certificates.crt anfügen und
4.) den apache/samba neu starten?

Das kommt mir jetzt um einiges unkomplizierter vor …
Bleibt die Datei erhalten, wenn es irgendwelche Upgra
des gibt?

ich würde als 2b hinzufügen:

  • diesen Inhalt in eine Datei mit Endung „.pem“ in /etc/ssl/certs speichern.

dann sollte Debian bei neuen Certs deins dazunehmen.

HAHA! Sogar besser: es gibt ein update-ca-certificates :slight_smile: Das tut genau deinen Schritt 3, wenn die .pem da ist (und noch einen Symlink vom Hash, aber egal). Das wird immer dann aufgerufen, wenn es neue certs gibt.

Korrektur: Debian finds noch besser, wenn du die .pem Datei in /usr/local/share/ca-certificates speicherst.

Ok, alles gemacht-- aber leider nichts erreicht. Das Problem bleibt bestehen – es gehört eigentlich weiterhin in den anderen Thread … ich schreibe da weiter, ok?