Ldaps nicht erreichbar

[NorbertFe 1.805]

vor 54 Minuten schrieb daabm:

Bei LDAPS kannst Du nicht festlegen, welches Zertifikat verwendet wird

kann man schon, hat aber andere Nachteile. :/

[todde_hb 4]

vor einer Stunde schrieb daabm:

So einfach ist das jetzt leider nicht. Bei LDAPS kannst Du nicht festlegen, welches Zertifikat verwendet wird... Da mußt dann "remote" schauen, welches im SSL-Handshake präsentiert wird. Soweit ich weiß, wird von allen, die "Server-Auth" haben, das neueste genommen. Test:

 

https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1

Aufrufen mit -Ports 636 -IncludeSSL -SSLPorts 636, dann siehst zumindest mal welche SAN und so im Cert stehen. Wenn Du's genauer weissen willst: -PassThru anhängen und das Ergebnis speichern, dann hast ein Objekt, in dem das Cert drinsteckt inkl. .Save( "Dateiname" ) Methode. Aber jetzt wird's zu esoterisch

Das mit "muß der CA-Kette vertrauen" steht oben ja schon. Ich weiß übrigens nicht, ob LDAPS mit SelfSigned überhaupt funktioniert, nie probiert mangels Umgebung ohne CA

 

 

Interessant. -IncludeSSl gibt es nicht.  Ist -VerifySSL das gleiche?

 

Aber so richtig verstehen tue ich das Problem aber nicht. Schaue ich in die Nextcloud Dokus, oder lese Anleitungen dazu, dann klappt es anscheinend bei allen mit den Einstellungen wie oben beschrieben.

 

bearbeitet 19. Oktober 2023 von todde_hb

[daabm 1.185]

Ja ok, manchmal vergesse ich wie meine Parameter heißen Wenn da überal N/A steht, klappt der SSL-Handshake nicht. Netzwerktrace sagt Dir, was genau schiefgeht. CA-Kette nicht vertrauenswürdig vermutlich, obwohl ich das eigentlich ignoriere (extra einen Verificaction Callback eingebaut, der immer $True liefert).

Oder falsche Namen/SAN im Zertifikat.

[todde_hb 4]

Am 22.10.2023 um 17:50 schrieb daabm:

Ja ok, manchmal vergesse ich wie meine Parameter heißen Wenn da überal N/A steht, klappt der SSL-Handshake nicht. Netzwerktrace sagt Dir, was genau schiefgeht. CA-Kette nicht vertrauenswürdig vermutlich, obwohl ich das eigentlich ignoriere (extra einen Verificaction Callback eingebaut, der immer $True liefert).

Oder falsche Namen/SAN im Zertifikat.

 

Ich führe das Skript lokal auf dem DC aus, der auch die Enterprise-CA beherbergt. Sicher, dass das was netzwerktechnisches sein kann? Bin da stark am zweifeln. Auch chain of trust sollte doch in der Konstellation gegeben sein.

[daabm 1.185]

Wie gesagt: In einem Netzwerktrace kannst Du den SSL-Handshake nachvollziehen und da siehst Du auch, was schiefgeht.

Und daß das "lokal auf der CA" läuft, bedeutet erst mal nichts. Das Windows-OS muß dieser CA ja auch erst mal vertrauen.