• Bewerte uns auf OMR Reviews: Klick

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

  • Wichtige Information für alle, die noch nicht auf v14.0.5.39 sind:

    Cyren Antimalware kann nicht mehr verwendet werden. Unsere Lizenz ist endgültig deaktiviert, so dass der Dienst nicht mehr nutzbar ist.
    Bitte stellt sicher, dass ihr schnellstmöglich auf die aktuelle Version aktualisiert. Bis es so weit ist, empfehlen wir die Cyren Antimalware Aktion zu deaktivieren und mindestens den lokalen Virenscanner zu aktivieren. Sollte kein anderer Scanner als Cyren aktiv sein, kommt es unweigerlich zur Abweisung von E-Mails.

    Zusätzlich raten wir dazu, die Cyren Filter zu deaktivieren, hier ist der Einfluss zwar geringer, solange alle anderen Filter korrekt durchlaufen, aber im Problemfall kommt es ebenfalls zur Abweisung.

     

    Unser Blogbeitrag wird in Kürze ebenfalls aktualisiert.

    Beste Grüße
    Euer NoSpamProxy Team

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

SwissSign neu ausgestellte Zertifikate werden nicht genutzt

MarkusB

Active member
Hallo,

Version 13.2.21327.1706

Wenn neue Zertifikate via SwissSign ausgestellt werden, sind diese korrekt an den User im NSP gebunden.
Im Message Tracking steht dann aber "Nachricht konnte nicht signiert werden, da kein Signatur Schlüssel für den Absender."

Thema tritt seit ein paar Tagen auf, scheinbar nur neue Zertifikate aus der folgenden Kette:

SwissSign Gold CA - G2
->SwissSign RSA SMIME Root CA 2021 - 1
-->SwissSign RSA SMIME LCP ICA 2021 - 2
---> CN = Secure Mail: Gateway Certificate

Es sind "perso-silver" Zertifikate 


NSP und Windows zeigen das Zertifikat jeweils als gültig an. 

Hat jemand noch eine Idee?
 
Hallo,
da fallen mir nur noch drei Dinge ein:

- Entweder ist das Zertifikat nur für Verschlüsselung zugelassen
- Oder die E-mail-Adresse, die im Header-From steht, stimmt nicht mit der Adresse im Zertifikat überein.
- Oder das Zertifikat wurde nicht ordnungsgemäß auf die Gateway Rollen synchronisiert.

Im Zweifel muss das Logfile herhalten um herauszufinden, was NoSpamProxy davon abhält, das Zertifikat zu verwenden.
Gruß Stefan
 
Hallo,

also die Zertifikate werden "irgendwann" schon verwendet, es dauert halt manchmal nur ein paar Tage.
Gleiches passiert beim "Revoken" - es dauert bis die Gatewayrolle es nicht mehr nutzt.
Manchmal funktioniert es bei einer Gatewayrolle am gleichen Tag und bei der Anderen ein, zwei Tage später.

Die ersten zwei Punkte @Stefan würde ich daher ausschließen.

Zertifikat wird nicht ordnungsgemäß auf GW Rolle synchronisiert könnte da schon eher passen.

Welche Logs genau sind hier den relevant, dann sammeln ich diese von einer Neu-Ausstellung / Revoke und sehe mir diese mit dem MS Service Trace Viewer mal an.
Bringt es hier Sinn einen Sync mit der Gatewayrolle anzutriggern und auch davon mal die Logs zu sammeln?

(Es gibt dazu auch schon ein Support-Ticket bei euch)

Danke vorab.
 
Hallo Markus,

log Seitig schau auf jeden Fall mal in das EventLog der Intranet Rolle und des Gateways.
Generelle Replikationsprobleme sollten dort gut zu sehen sein.

Ansonsten würde ich auf der Intranet Rolle folgende Logkategorien aktivieren:
Active Directory user import
Certificate Enrollment
Certificate Management
Gateway Role configuration service
Keymanagement
Replication service
UserManagement Service
Ja das sind viele, aber damit sollten alle Zusammenhänge klar sichtbar sein =)

Und beim Gateway folgende:
Advanced and qualified signature actions (dürfte unwichtig sein, bin mir aber nicht 100% sicher)
Certificate Management
Cryptography Service
Gateway Role Web Services
Keymanagement
Mail delivery service
Mailvalidation
Proxy System
Replication service


Mein erster Tipp wäre wohl wirklich die Replikation.
Hier könntest du auch manuell in der Datenbank des Gateways nachschauen ob ein entsprechendes Zertifikate vorhanden ist oder nicht.
Ein Klick auf "Konfiguration abgleichen" könnte das Problem lösen oder ggf. bei der Fehleranlayse helfen weil dann Replikationsfehler auftauchen.
Ebenfalls wäre interessant ob inder Intranet Rollen DB Replikationsartefakte in der "DataReplication.Artefact" Tabelle vorhanden sind und diese ein etwas altes Datum haben :)


Gruß
Jan
 
Hallo Jan,

bevor ich das Log erstellen konnte habe ich heute erstmal die BugFix Version 14.0.0.4510-release-75849 installiert.
(Damit auslaufende Zertifikate erneuert wurden, welche kurz vor Ablauf waren)

Danach die entsprechenden Logs aktiviert und "leider" kein Fehler mehr feststellbar.
Ich kann nun Zertifikate ausstellen und diese sind auf beiden Gateways sofort verfügbar.
Ich muss es weiter beobachten - ich kann mir nur vorstellen das etwas in der neuen Version war, was dies ebenfalls behoben hat.

Bei meinen letztens Tests (die letzten zwei Monate) war das Thema immer nachstellbar.

Beim Aufräumen der Zertifikate ist mir folgendes noch aufgefallen:
- Ein Benutzer hat zwei gültige Zertifikate (dies ist bei ganz vielen Usern leider so gewesen)
- Zertifikat A läuft 11.2022 aus
- Zertifikat B läuft 05.2023 aus und ist aktiv gesetzt
- Zertifikat A habe ich revoked
- Beim User Sync wird dann wieder ein neues Zertifikat angefragt, obwohl Zertifikat B noch gültig und aktiv (Uhrzeit alle Server i.O.)

Kann es da einen Zusammenhang geben, dass Zertifikat "B" z.B. bei einer GatewayRolle nicht bekannt war und daraufhin nach Revoke "A" keins mehr vorhanden war.
Update: Zertifikat B wurde zuvor von beiden Gateway Rollen zum Signieren benutzt laut MessageTracking

Wie erfolgt den der Check ob ein Neues benötigt wird? Macht dies alleine die IntranetRole oder spielen die GatewayRollen ebenfalls eine Rolle.

Gruß
Markus

PS: Ich installiere jetzt dann die 14.0.1. Die war heute morgen noch nicht da, um wieder in den offiziellen Versionen zu sein.
 
Zurück
Oben