Gelöst Let's Encrypt Zertifikate für cloud.nospamproxy.com

[zuberth]

Hallo zusammen

Ich habe derzeit ein Verständnis-Problem. In der Zertifikatsverwaltung finde ich für jede Kunden-Domäne mit einem EXO-Tenant je ein Let's Encrypt Zertifikat mit dem Namensschema %kundentenant%.o365.cloud.nospamproxy.com. Ich mag mich nicht erinnern, dass ich oder einer unserer Techis die eingerichtet hat. Dort, wo die Zertifikate manuell konfiguriert werden können, ist ein Wildcard SwissSign-Zertifikat hinterlegt. Die Erneuerungen der gefundenen Let's Encrypt Zertifikate laufen automatisiert ab. Ein ACME-Tool ist auf diesem Server nicht installiert. Dazu meine Fragen:

-> wo werden diese Zertifikate genutzt (der Name weist auf Routing-Konnektoren der EXO-Server hin)?
-> läuft der Erneuerungs-Prozess über ein lokales ACME-Protokoll?
-> Falls ja (was ich eher nicht annehme): Welche Firewall Exeptions sind erforderlich?
-> wir betreiben eine 2. Instanz für den Eigenbedarf. Dort finde ich im NSP kein Let's Encrypt Zertifikat. Gibt es den Bedarf erst, wenn mehrere 365-Tenants in der gleichen Instanz betrieben werden?

Sorry für die Fragerei, ich konnte dazu nirgends etwas finden und in der Regel ist es wünschenswert, die Mechanik von Programmen zu verstehen, die man auf eigener Plattform betreibt und in Verantwortung gegenüber den Kunden steht .

Kann mir da jemand auf die Sprünge helfen?

LG Thomas

 

[Sören]

Das Zertifikat wird ausgerollt, wenn du das hier am M365 Konnektor im NSP aktiv hast:

 

[JanJäschke]

Hallo Thomas,

da helfe ich gerne weiter
In den E-Mail Servern des Unternehmens hast du einen O365 Eintrag, vlt auch mehrere.
Innerhalb dieser Einträge bzw. bei der Erstellung hast du folgende Auswahl:


Die obere Option, welche der Standard ist, verursacht genau diese Zertifikatsanfragen. Hierbei handelt es sich um ein Zertifikat welches immer für einen O365 Tenant ausgestellt wird und im Exchange Online Konfigurations Skript/Guide namentlich angegeben wird. Damit wird sichergestellt, dass der NoSpamProxy mit diesem Zertifikat als Client-Identität eindeutig am Exchange identifiziert werden kann und somit ein korrektes Routing ermöglicht wird. NoSpamProxy kümmert sich dann vollständig automatisch um eine Verlängerung des Zertifikates und aktualisiert entsprechend auch die Konfiguration.

Alternativ kannst du im zweiten Punkt ein eigenes Zertifikat auswählen, dsa übernehmen wir dann auch überall verwendet, hier musst du jedoch als Admin darauf achten, dass das Zertifikat aktuell gehalten wird.

Wir läuft das nun mit der Ausstellung ab:
Sobald du den Server anlegst bzw. die Option aktivierts wird über einen Cloud Dienst hinter service.nospamproxy.com das entsprechende Zertifikat angefragt. Dies passiert bei Lets Encrypt mittels ACME.
Das bedeutet euer O365 Tenant Name wird an uns übermittelt, wir fragen das Zertifikat an und liefern das Zertifikat zurück bzw. genau genommen holt der NoSpamProxy das dann später ab. Das passiert dann alle 30 Tage erneut.


Wieso du nun in deiner Testumgebung kein Zertifikat siehst kann zwei Gründe haben:

1. kein O365 E-Mail Server des Unternehmens
2. du hast die zweite Option gewählt

Da wir natürlich einen Schutz implementiert haben damit niemand einfach so ein ausgestelltes Zertifikat hijacken kann, kannst du nicht einfach so in jeder Instanz den tenant Namen eintragen und bekommst direkt immer ein neues Zertifikat. Hier kommt deine Lizenz nämlich mit ins Spiel

Hilft dir das erstmal weiter?

LG
Jan

 

[zuberth]

Hallo Jan, hallo Sören,

danke für die Rückmeldungen, Dir Jan, dass Du Dir die Zeit für die Beschreibung der Prozesse genommen hast. So was in der Art war auch meine Vermutung, jetzt ist es Gewissheit. Das Design passt auch, es entlastet von der Pflicht bei der Nutzung von Let's Encrypt, passende DNAT-Regeln für ACME auf der eigenen Firewall zu pflegen.

Auf der 2. Instanz, die wir für unsere eigene Mail-Kommunikation nutzen und jeweils als Test-Umgebung für neue Versionen und Tests herhalten muss, habe ich die 365er-Anbindung jetzt auf automatische Identität umgestellt (zuvor wurde das eigene Zertifikat genutzt). Das hat dann den Bezug eines Let's Encrypt Zertifikats ausgelöst.

LG
Thomas

 

[Sören]

365er-Anbindung jetzt auf automatische Identität umgestellt

dann musst du aber im EXO am Konnektor aber auch den Namen angeben...der hat sich dadurch ja nun geändert und im schlimmsten Fall, sofern du das nicht tust, nimmt euer EXO die Mails nicht mehr vom NSP ab

 

[zuberth]

Danke für den Hinweis. Funktioniert bisher alles ohne Namensanpassung. In EXO gab es mit der Umstellung im NSP (bisher) keine Veränderung bei den Konnektoren. Das ist jetzt bereits seit zwei Stunden so in Betrieb. Mails kommen rein und gehen raus. Ich behalte ein Auge drauf ...

 

[Sören]

Wenn du den Konnektor nach unseren Vorgaben eingerichtet hast im M365, dann akzeptiert dieser nur Mails von einem Server, dass sich mit entsprechenden Namen im Zertifikat meldet... da du das nun geändert hast, hat sich auch der Name des CN geändert... wollte es nur angemerkt haben.

 

[zuberth]

Daran liegt es: Die Konnektoren sind auf IPv4-Adressen konfiguriert (restriktiert) und nicht den Zertifikatsnamen. Unsere Installation ist mittlerweile 10 Jahre alt, vielleicht war es damals so üblich. Ich werde die Konnektoren gelegentlich löschen und neu erstellen, damit wir uns hier im Standard bewegen ...