Welches Serverzertifikat exportieren für LDAPS-Verbindung?

[Cryer 17]

Ich programmiere gerade eine Webanwendung um eine LDAPS-Verbindung mit einem Server 2019 her zu stellen. (Domäne Controller, Testumgebung)

Wenn man einfach nur eine LDAP-Verbindung herstellen will funktioniert das, aber mit LDAPS funktioniert das leider nicht.

Ich bekomme dann folgende Fehlermeldung:

Zitat

Warning: ldap_bind(): Unable to bind to server: Can't contact LDAP server

 

Scheinbar muss ich ein Zertifikat (das kann auch ein selbst signiertes sein) vom Server exportieren und auf dem Webserver importieren, aber ich finde keine Angabe darüber, welches Zertifikat. In Windows Server 2019 sind ganz vuiele und ich habe keine Ahnung, welches davon das richtige ist. Angeblich soll es den Domänenamen enthalten, aber davon finde ich keins.

 

Kann mir von euch jemand weiterhelfen?

[cj_berlin 1.149]

Moin,

 

die "ganz viele", die Du da findest, sind die Root-Zertifikate, die helfen Dir vermutlich nichts.

 

Wenn Du auf dem Domain Controller certlm.msc ausführst und dort unter "Eigene Zertifikate" keines steht (alternativ Get-ChildItem "cert:\LocalMachine\My"), dann kann Dein DC gar kein LDAPS anbieten, denn es ist kein Zertifikat dort gebunden.

 

Im einfachsten Fall gelten die Regeln für TLS. d.h. das Zertifikat muss im SAN (und bei LDAPS evtl. auch im Subject, das weiß ich gerade nicht mehr) den Namen haben, unter dem Du den DC kontaktierst. Dein Anwendungsserver muss dem Zertifikat vertrauen, also der PKI-Kette, die es ausgestellt hat.

 

Willst Du die HA-Mechanismen für AD für Dich nutzen, dann muss das Zertifikat in der Tat auf den Namen der Domäne lauten (und Du musst nicht einen konkreten DC, sondern die Domäne ansprechen).

 

Microsoft Enterprise PKI hat dafür Vorlagen, aber das führt jetzt zu weit.

[testperson 1.539]

Hi,

 

in einer Testumgebung - wie in deinem Fall - sollte es ausreichen, dem DC "flott" ein Zertifikat unterzujubeln:

New-SelfSignedCertificate -FriendlyName "Mein erstes LDAPs Zertifikat" `
    -DnsName $(-join($env:COMPUTERNAME, ".", $env:USERDNSDOMAIN)), $env:COMPUTERNAME `
    -CertStoreLocation "cert:\LocalMachine\My" `
    -Subject $(-join($env:COMPUTERNAME, ".", $env:USERDNSDOMAIN)) `
    -NotAfter (Get-Date).AddYears(10) `
    -KeyLength 2048 `
    -KeyAlgorithm RSA `
    -KeyExportPolicy Exportable 

 

Gruß

Jan

bearbeitet 14. Juni 2023 von testperson

[daabm 1.187]

Entweder hat Dein DC kein Serverzertifikat, dann gibt es keinen Listener auf Port 636. Oder Du hast irgendwo anders Firewalls, die 636 nicht durchlassen. Portqry/Test-NetConnection könnte hier Klarheit schaffen.

Das hier kann das alles für Dich prüfen inkl. der verwendeten Zertifkate: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1

 

Wichtig bei LDAPS, wenn die Basis mal funktioniert: Der Client (also Dein Webserver) muß der kompletten CA-Kette vorher schon vertrauen - LDAPS liefert im Handshake die CA-Chain nicht mit aus (wie das https macht).

[NorbertFe 1.810]

vor 3 Minuten schrieb daabm:

Der Client (also Dein Webserver) muß der kompletten CA-Kette vorher schon vertrauen

Oder so wie viele andere Entwickler einen Haken programmieren, der die Kette "egalisiert". ;)

[daabm 1.187]

Jaja, weiß ich doch...

$ValidationCallback = [Net.Security.RemoteCertificateValidationCallback] { return $True }
$Socket = [Net.Sockets.Socket]::new( [Net.Sockets.SocketType]::Stream, [Net.Sockets.ProtocolType]::Tcp )
$Socket.Connect( $TargetComputer, $Port )
$NetStream = [Net.Sockets.NetworkStream]::new( $Socket, $true )
$SslStream = [Net.Security.SslStream]::new( $NetStream, $true, $ValidationCallback )