Umzug auf neuen Server mit anderem Hostname

[obraun]

Hallo,

ich versuche, entsprechend der Anleitung https://docs.nospamproxy.com/Server...t/How-tos/how-to-migrate-nospamproxy-14-x.htm eine 15.4.0 auf eine neue Maschine umzuziehen.

Allerdings ist der Hostname ein anderer (Single-Server, keine Domäne). Ich habe in der Intranet Role.config außer den in dem Artikel geforderten Änderungen auch den Hostnamen geändert.

So ganz hat das noch nicht geklappt, ich bekomme keine Verbidnung zur Gatewayrolle (Dienste laufen alle, Server wurde neu gestartet, Server 2022 und SQL 2022):



Wo kann ich denn da schauen? Ein passendes SSL-Zertifikat habe ich bei den Computerzertifikaten hinterlegt.

Die Hash-Werte unten passen auch zu vorhandenen Zertifikaten:

netsh http show sslcert


SSL-Zertifikatbindungen:
-------------------------






    IP:Port                      : 0.0.0.0:6061
    Zertifikathash              : 8ee00e011043264d098b5c541b74d258467576de
    Anwendungs-ID               : {6d46c289-5847-4017-bcef-72920bd7e01f}
    Zertifikatspeichername       : (null)
    Clientzertifikatsperre überprüfen : Enabled
    Zur Sperrüberprüfung ausschließlich zwischengespeichertes Clientzertifikat verwenden : Disabled
    Verwendungsüberprüfung                  : Enabled
    Sperraktualisierungszeit    : 86400
    Zeitlimit für URL-Abruf        : 30
    Steuerelement-ID               : (null)
    Steuerelement-Speichername               : (null)
    DS-Zuordnungsverwendung              : Disabled
    Clientzertifikat aushandeln : Disabled
    Verbindungen ablehnen           : Disabled
    HTTP2 deaktivieren                : Not Set
    QUIC deaktivieren                 : Not Set
    TLS1.2 deaktivieren               : Not Set
    TLS1.3 deaktivieren               : Not Set
    OCSP Stapling deaktivieren        : Not Set
    Tokenbindung aktivieren: Not Set
    Erweiterte Ereignisse protokollieren: Not Set
    Frühere TLS-Versionen deaktivieren  : Not Set
    Sitzungsticket aktivieren        : Not Set
 Erweiterte Eigenschaften:
    PropertyId                   : 0
    Empfangsfenster               : 1048576
 Erweiterte Eigenschaften:
    PropertyId                   : 1
    Max. Einstellungen pro Frame       : 2796202
    Max. Einstellungen pro Minute      : 4294967295
 Erweiterte Eigenschaften:
    PropertyId                   : 2
 Erweiterte Eigenschaften:
    PropertyId                   : 3
 Erweiterte Eigenschaften:
    PropertyId                   : 4




    IP:Port                      : 0.0.0.0:6062
    Zertifikathash              : cff90f911df72482a1ccc29a9668030d7d1d2dfa
    Anwendungs-ID               : {6d46c289-5847-4017-bcef-72920bd7e01f}
    Zertifikatspeichername       : (null)
    Clientzertifikatsperre überprüfen : Enabled
    Zur Sperrüberprüfung ausschließlich zwischengespeichertes Clientzertifikat verwenden : Disabled
    Verwendungsüberprüfung                  : Enabled
    Sperraktualisierungszeit    : 86400
    Zeitlimit für URL-Abruf        : 30
    Steuerelement-ID               : (null)
    Steuerelement-Speichername               : (null)
    DS-Zuordnungsverwendung              : Disabled
    Clientzertifikat aushandeln : Enabled
    Verbindungen ablehnen           : Disabled
    HTTP2 deaktivieren                : Not Set
    QUIC deaktivieren                 : Not Set
    TLS1.2 deaktivieren               : Not Set
    TLS1.3 deaktivieren               : Not Set
    OCSP Stapling deaktivieren        : Not Set
    Tokenbindung aktivieren: Not Set
    Erweiterte Ereignisse protokollieren: Not Set
    Frühere TLS-Versionen deaktivieren  : Not Set
    Sitzungsticket aktivieren        : Not Set
 Erweiterte Eigenschaften:
    PropertyId                   : 0
    Empfangsfenster               : 1048576
 Erweiterte Eigenschaften:
    PropertyId                   : 1
    Max. Einstellungen pro Frame       : 2796202
    Max. Einstellungen pro Minute      : 4294967295
 Erweiterte Eigenschaften:
    PropertyId                   : 2
 Erweiterte Eigenschaften:
    PropertyId                   : 3
 Erweiterte Eigenschaften:
    PropertyId                   : 4

 

[StefanCink]

Ich würde die Gateway Rolle einfach kurz entbinden und neu einbinden. Dann wird das korrekte Zertifikat hinterlegt. Du musst danach jeden Konnektor noch einmal anfassen und die „neue“ Gateway Rolle auswählen. Dann sollte es klappen.
Gruß Stefan

 

[obraun]

Vielen Dank für die schnelle Reaktion, Stefan, das hat funktioniert.

Was noch fehlt, vor einem Livegang, ist der Schutz sensibler Daten. Beim Versuch, dort ein Kennwort zu hinterlegen, kommt eine Fehlermeldung. Aber das ist vielleicht der frischen NoSpamProxy-Version geschuldet? Tatsächlich hat sich auch das Control Center zweimal geschlossen, als ich die Gateway-Rolle neu verbunden habe.

 

[StefanCink]

In diesem Fall muss Punkt 4 aus der Anleitung noch einmal genau geprüft werden. Es stehen noch verschlüsselte Passwörter in der Konfigurationsdatei. Das ist der Abschnitt den ich meine:
Passen Sie die Konfigurationsdatei Intranet Role.config wie folgt an:

 

[obraun]

Hm, ich hätte behauptet, dass ich diesen Abschnitt durchgearbeitet habe. Aber ich werde es beim nächsten Umzugsversuch nochmal prüfen.

Jetzt habe ich noch das Problem, dass Exchange online die E-Mails nicht annimmt. Den EXO-Empfangskonnektor habe ich angepasst (also die IP des neuen NSP-Servers eingetragen).

Ich finde bei M365 gerade keine Einstellungs, die falsch ist.



Nur zur Sicherheit - wegen der seltsamen "Letzer Fehler"-Meldung in der Warteschlange - gefragt, könnte das Problem womöglich doch in der NoSpamProxy -Konfiguration liegen?

 

[obraun]

Womöglich liegt das an der unverschlüsselten Verbindung Richtung EXO. Finde nur nicht, wo ich das im NSP beeinflussen kann.

 

[869288141]

Hallo obraun,
die mir einzig bekannte Stelle ist beim E-Mail-Server des unternehmens.

Hast du evtl. ein Zertifikat angegeben, welches auf dem neuen Server nicht existiert?


Gruß,
Daniel

 

[obraun]

Hi Daniel,

ich habe den Punkt auch da oben. Es ist wohl doch nicht die Verschlüsselung, da die Nichtzustellbarkeitsbenachrichtigungen vom NSP dann an verschiedene Server verschlüsselt übergeben wurden. Darunter ein M365. Es ist also nur unser eigener M365, der nicht annimmt.

Viele Grüße
Oliver

 

[StefanCink]

Ich könnte mir vorstellen dass der TLS Handshake aufgrund des verwendeten Client-Zertifikat nicht funktioniert. Die Frage ist, wie ist O365 konfiguriert? Schaut er auf die einliefernde IP-Adresse oder eine Client-ID? Empfohlen ist letzteres.

 

[obraun]

Vielen Dank für die Weihnachtliche Antwort. Mal schauen, ob ich über die Feiertage weiterprobiere.

Heute fiel mir noch auf, dass es Schwierigkeiten gibt, die IP-Adresse hinzuzufügen (möglicherweise war die doppelt, ich muss mal schauen). Habe bisher die IP benutzt. Eine gute Idee, mal den anderen Weg zu versuchen.

Wobei ich erst verstehen muss, was mit "you must not use this certificate as a client identity for outbound emails" bedeutet, oder was für ein Zertifikat erzeugt wird, wenn ich den Punkt bei "Automatically provision an identity (recommended)" auswähle. Letzteres wäre dann ja dem EXO bekanntzumachen.

 

[obraun]

So, zwischen den Jahren hinbekommen, es funktioniert jetzt (anders als vor dem Umzug) nur mit einem EXO-Empfangskonnektor, bei welchem auch ein Zertifikat enthalten ist, vorher genügte die IP des NSP, aber das ist ja eher eine Frage, die man Microsoft stellen müsste. https://www.msxfaq.de/cloud/exchang...htm#connector_mit_source_ip_zertifikat_domain war hilfreich.

• Es muss sich um ein gültiges, vertrauenswürdiges Zertifikat handeln, also nicht das vom NSP bei der Installation selbst erstellte.
• Den Hinweis im NSP-Command Center "you must not use this certificate as a client identity for outbound emails" verstehe ich immer noch nicht und habe ihn ignoriert. Das Zertifikat, welches ich in Richtung Exchange online bei von extern eingehenden Mails nun benutze, ist das gleiche, welches der NSP bei von EXO durch den NSP Richtung Außenwelt gerouteten E-Mails verwendet, also zB bei SMTP Richtung mail.gmx.de.

Erstellt habe ich per Powershell, und ich kombiniere Zertifikat und IP:

New-InboundConnector -Name "Vom NoSpamProxy eingehend empfangend – Wildcard - IP" -ConnectorType Partner -SenderDomains * -SenderIPAddresses IP -RestrictDomainsToIPAddresses $true -RequireTLS $true -RestrictDomainsToCertificate $true -TlsSenderCertificateName "*.domain.de"

 

[869288141]

@JanJäschke @StefanCink
Bitte die persönlichen Informationen noch entfernen.

 

[Sören]

entfernen

du meintest die IP oder hab ich noch was anderes übersehen?

 

[869288141]

Hallo Sören,
danke dir. Ja, ich meinte das IP-Subnetz.

Gruß,
Daniel

 

[869288141]

Es muss sich um ein gültiges, vertrauenswürdiges Zertifikat handeln, also nicht das vom NSP bei der Installation selbst erstellte.

D.h. du hast ein Zertifikat für den FQDN bei Let's Encrypt abgerufen?

 

[obraun]

Vielen Dank noch für das entfernen der IP-Adresse, das war aber gar nicht die IP des hier verwendeten NoSpamProxy.

@869288141 - Nein, es handelt sich um ein gekauftes Zertifikat. Und ich hatte die letzten zwei Wochen kein Problem mehr mit der Installation außer dem Problem, dass der Schutz sensibler Daten nicht aktiviert werden konnte.

Das lag zunächst einmal daran, dass ich die DKIM-Schlüssel nicht entfernt hatte. Leider geht es aber auch danach nicht, es kommt eine Meldung mit dem gleichen Text, den ich weiter oben schon als Fehleranzeige in der Warteschlange erwähnt hatte.

 

[nsp-support]

Das Problem hinsichtlich des Kennworts zum Schutz sensibler Daten konnte durch einen leeren Eintrag in der Intranetrole.config beseitigt werden:

<netatwork.nospamproxy.security.securedataservice>
<encryptionSettings password="" />
</netatwork.nospamproxy.security.securedataservice>

Sobald dieser vorlag, konnte das Kennwort wieder gesetzt werden.

 

[obraun]

Genau, daran lag es, und an einem Missverständnis hinsichtlich des Schutzes sensibler Daten. Herzlichen Dank an den Support für die geduldige Hilfe!

Eine weitere Frage: Die Archivierung ins Dateisystem funktioniert nicht mehr. Es wurden die Einstellungen vom alten Server übernommen, aber es wird nichts archiviert. Welche Berechtigungen sind denn notwendig? "Jeder"-Vollzugriff auf das Archivverzeichnis passt leider nicht.

 

[JanJäschke]

@obraun "Please provide an absolute path on the Gateway Roles to which the service account NT Service\NoSpamProxyGatewayRole has write permissions to, e.g.: 'C:\archive'."
Steht sogar so in der UI

Damit sollte das dann auch funktionieren, falls es aber Rechte Probleme gibt sollte im Eventlog eigentlich etwas auftauchen.