Gelöst Fehler bei Umkonfiguration des TCP Proxy gemäß Dokumentation

[BenKr]

Hallo zusammen,

wir bekommen die Nachricht, dass wir den TCP Proxy umkonfigurieren müssen. Wenn wir dies gemäß Doku versuchen, erhalten wir bei Ausführung des PowerShell-Befehls die folgende Fehlermeldung:

Set-NspOutboundSendConnector : The certificate validation with <Name des Servers> failed.
- The host name did not match any name in the certificate (<smg.domain.de>, <disclaimer.domain.de>)

Wir verwenden dafür ein Zertifikat einer öffentlichen CA, bei dem man keine SANs zusätzlich hinterlegen kann. Wir haben auch schon den Parameter -HostNameOverride entdeckt, aber haben leider nichts in der Doku gefunden, welchen Wert man hier setzen müsste und ob er überhaupt hilft. $True und True haben nicht funktioniert.

Was müssen wir tun, damit der Befehl erfolgreich ist?

VG
Ben

 

[869288141]

Hallo Ben,

Wir verwenden dafür ein Zertifikat einer öffentlichen CA, bei dem man keine SANs zusätzlich hinterlegen kann.

das entsprechende Produkt der öffentlichen CA zu verwenden, welche weitere SANs unterstützt, ist keine Option weil?


Gruß,
Daniel

 

[BenKr]

Hi Daniel,
hm, ich meine mal gelesen zu haben, dass Zertifikate öffentlicher CAs keine SAN für interne Namen beinhalten können.
Das war dann scheinbar ein Irrtum.


Ich gebe das mal an die Kollegen weiter, die das Zertifikat beschafft haben.
Weißt Du, ob es für die Umkonfiguration irgendeine Deadline gibt?

Dann würde ich da noch ggf. aufs Gas treten.

VG
Ben

 

[869288141]

Hallo Ben,

hm, ich meine mal gelesen zu haben, dass Zertifikate öffentlicher CAs keine SAN für interne Namen beinhalten können.

woher soll ich wissen, wie euer "internen Namen" lautet? Wenn du damit z.B. nsp.firma.local meinst, dann ist das in der Tat so. dies betrifft eben alle TLDs, welche nicht öffentlich sind.

Weißt Du, ob es für die Umkonfiguration irgendeine Deadline gibt?

Laut den Release Notes der ersten Version von 15.5.0 (https://docs.nospamproxy.com/Server...ease-notes/nospamproxy-server-15-5-0-1377.htm) wird der TCP Proxy über die Konfigurationsdatei mit Erscheinen der Version abgekündigt. Daher würde ich behaupten, dass du vor Weihnachten keinen Schnellschuss mehr machen musst.

Set-NspOutboundSendConnector : The certificate validation with <Name des Servers> failed.
- The host name did not match any name in the certificate (<smg.domain.de>, <disclaimer.domain.de>)

Ich bin gerade etwas irritiert, wie es zu dieser Fehlermeldung kommt. Poste gerne einmal den vollständige Befehl, damit deine bisherige Versuche nachvollziehbar wird. Muss aber auch an der Stelle sagen, dass ich keinen TCP Proxy verwende.


Gruß,
Daniel

 

[BenKr]

Hi Daniel,

woher soll ich wissen, wie euer "internen Namen" lautet? Wenn du damit z.B. nsp.firma.local meinst, dann ist das in der Tat so. dies betrifft eben alle TLDs, welche nicht öffentlich sind.

nun ja - interne Server verwenden selten einen öffentlich routbaren Namen, aber ich gebe zu, dass das auch mal vorkommen kann. ;-)
In diesem Fall wäre es lustigerweise sogar so, dass der Server einen "öffentlichen" Namen verwendet, da er in Entra Domain Services integriert ist, wofür man ebenfalls ein Zertifikat braucht. Das nur nebenbei.

D.h. wir müssten schlicht das Zertifikat um diesen Namen ergänzen und dann sollte der Befehl klappen. Mich würde dennoch interessieren, was der Parameter "-HostNameOverride" tut und wenn er das tun soll, was ich denke, warum es nicht funktioniert. Das kann vielleicht jemand anderes beantworten.

Ich hab einen Screenshot des Befehls und der Fehlermeldung beigefügt.

VG
Ben

 

[Sören]

Ich hab einen Screenshot des Befehls und der Fehlermeldung beigefügt.

ich hab das cmdlet noch nie benutzt.. allerdings hast du das hier in PS nicht abgesetzt

connect-nsp -IgnoreServerCertificateErrors

 

[BenKr]

Aaaargh, Du hast Recht. Meine Fresse, einfach überlesen.
Vielen Dank, jetzt hat es geklappt! Manchmal ist man echt...

VG
Ben

 

[BenKr]

Zumindest hast Du noch den Parameter -IgnoreServerCertificateErrors mitgeliefert, der wird im Artikel nicht erwähnt.
Ich nehme mal an, wenn man den Befehl einfach so absetzt, macht er im Hintergrund automatisch das Connect-Nsp, aber eben ohne diesen Parameter. Wo hast Du den gefunden?

 

[Sören]

connect-nsp -IgnoreServerCertificateErrors

du musst das immer erst so benutzen, bevor du ein cmdlet des NSP nutzen willst:

 

[Sören]

ich hab es mal an die technische Redaktion gegeben das die das in der Doku korrigieren

 

[BenKr]

@Sören Super, danke Dir!
Dann kann dieser Thread geschlossen werden.

 

[869288141]

Hallo Ben,

nun ja - interne Server verwenden selten einen öffentlich routbaren Namen, aber ich gebe zu, dass das auch mal vorkommen kann. ;-)
In diesem Fall wäre es lustigerweise sogar so, dass der Server einen "öffentlichen" Namen verwendet, da er in Entra Domain Services integriert ist, wofür man ebenfalls ein Zertifikat braucht. Das nur nebenbei.

Ich kenne nur Umgebungen, in denen eine öffentliche TLD verwendet wird. Sollte man heute und seit 10 Jahren auch nicht mehr anders tun. Bringt eigentlich nur noch Vorteile...

connect-nsp -IgnoreServerCertificateErrors

Den Parameter "IgnoreServerCertificateErrors" sollte man nur verwenden, wenn man ein Self-Signed-Zertifikat verwendet. Sonst fallen mögliche Probleme mit einem Zertifikat, welches eine (interne oder öffentliche) CA ausgestellt hat, nie auf.

ich hab es mal an die technische Redaktion gegeben das die das in der Doku korrigieren

Danke. In diesem Fall ist die Fehlermeldung des cmdlets doch mehr als irreführend. Passiert mir heute noch... Wäre es nicht langfristig sinnvoller hier die entsprechend Abhängigkeit zu prüfen und ggf. eine aussagekräftige Fehlermeldung im jeweiligen cmdlet auszugeben?


Gruß,
Daniel

 

[Sören]

Wäre es nicht langfristig sinnvoller hier die entsprechend Abhängigkeit zu prüfen und ggf. eine aussagekräftige Fehlermeldung im jeweiligen cmdlet auszugeben?

bin ich komplett bei dir

was soll ich sagen ^^

 

[869288141]

was soll ich sagen ^^

Jan ist nicht da. Ich würde sagen, die Entwicklung soll gleich loslegen.