Hallo liebe Exchange-Experten,
leider stehe ich gerade auf dem Schlauch, benoetige Hilfe und hoffe, ihr koennt mir weiterhelfen.
Ausgangssituation
Gerne wuerde ich die SMTP-Zertifikatserneuerung automatisieren.
Einen Automatismus, der uns im Dateiverzeichnis ein neues und gueltiges Zertifikat in Form einer
.p12
-Datei zur Verfuegung stellt, haben wir bereits. Es geht lediglich darum, das Zertifikat unbeaufsichtigt zu importieren und zuzuweisen, ohne dabei das Standard-SMTP-Zertifikat zu ersetzen.
Alles Weitere, wie das Aufraeumen von nicht mehr gebrauchten Zertifikaten etc., ist ebenfalls bereits einsatzbereit.
Bisheriges Vorgehen
Bisher haben wir neue Zertifikate bezueglich SMTP stets manuell eingebunden, in unserem Fall ueber EAC/ECP.
Beim Zuweisen des SMTP-Dienstes fragt Exchange stets ab, ob man auch das derzeitige Standard-SMTP-Zertifikat entsprechend ersetzen moechte. Dies haben wir bisher immer mit „Nein“ beantwortet.
Das bedeutet: Das
InternalTransportCertificate
ist und war bei uns stets das self-signed Default-Zertifikat von Exchange.
Da das neue Zertifikat dadurch dennoch dem SMTP-Dienst zur Verfuegung gestellt wird, wird es dank „opportunistic TLS“, dem passenden FQDN im Zertifikat und einer oeffentlich vertrauten CA dem selbstsignierten Zertifikat fuer externe Verbindungen vorgezogen.
Script zum Import des Zertifikats
Jetzt wird es gegebenenfalls etwas wild.
Ich habe ein Script erstellt, welches den Import des Zertifikats ueber das Windows-Cmdlet
Import-PfxCertificate
realisiert:
$importedCert = Invoke-Command -ComputerName $TargetServer -ScriptBlock {
param($RemotePfxPath)
$cert = Import-PfxCertificate `
-FilePath $RemotePfxPath `
-CertStoreLocation Cert:\LocalMachine\My `
-Exportable
return [PSCustomObject]@{
Thumbprint = $cert.Thumbprint
}
} -ArgumentList $RemotePfxPath
Dies mache ich, da ich beim Import über
Import-ExchangeCertificate
stets das Problem hatte, dass der Private Key nicht importiert wurde:
$importedCert = Import-ExchangeCertificate `
-Server $TargetServer `
-FileData $fileBytes `
-PrivateKeyExportable:$true
Das heißt: Beim Import ueber
Import-PfxCertificate
funktioniert es mit dem Private Key und das Zertifikat ist fuer Exchange ebenfalls sichtbar.
Auch eine Zuweisung zum SMTP-Dienst funktioniert. Doch hier kommt nun die Crux an der Sache...
Zuweisung des Zertifikats zum SMTP-Dienst
Ich habe folgenden Befehl fuer die Zuweisung verwendet:
Enable-ExchangeCertificate -Server $TargetServer -Thumbprint $thumbprint -Services POP,IMAP,IIS,SMTP -Force
Den Parameter
-Force
habe ich verwendet, um die Abfrage zu unterdruecken.
Gleichzeitig war mir bewusst, dass damit auch das Standard-SMTP-Zertifikat und somit auch das
InternalTransportCertificate
ersetzt wird. Dies sollte bei uns jedoch auch kein Problem darstellen, da interne sowie externe Servernamen identisch sind.
Leider kam es dabei aber zu folgender Fehlermeldung:
A special Rpc error occurs on server SERVERNAME: The new internal Transport certificate with thumbprint ABCDEF1234567890ABCDEF1234567890ABCDEF12 you are about to configure on the local server isn't a Cryptographic API certificate.
The internal Transport certificate is also used by EdgeSync. EdgeSync only supports CAPI certificates. Try to generate a new CAPI certificate for the internal transport certificate.
Umgebung
Zur weiteren Info:
Wir setzen zwei Mailbox-Server in einer DAG inklusive Witness, sowie zwei Edge-Transport-Server in einer DMZ ein.
Den Befehl hatte ich per
New-PSSession
auf dem zweiten Mailbox-Server ausgefuehrt.
Auswirkungen des Befehls
Im Anschluss war EdgeSync auf dem entfernten Mailbox-Server gebrochen.
Außerdem sind weitere Health-Probes wie zum Beispiel
EWS.Proxy
oder
OAB.Proxy
organisationsweit mit dem Fehler
401 unauthorized
fehlgeschlagen.
Ich weiß nicht genau, was passiert ist, aber auf jeden Fall hat der Befehl:
Enable-ExchangeCertificate ... -Force
der Organisation und dem Mailbox-Server selbst geschadet.
Ich weiß... wenn man nicht weiß was man tut, soll man lieber nichts machen. Jedoch dachte ich bis zu dem Zeitpunkt, dass ich weiß was ich da tue...
Wiederherstellungsversuch
Anschließend habe ich versucht, das alte self-signed Exchange-Zertifikat wieder als
InternalTransportCertificate
zu setzen.
Das hat jedoch nur bei dem Mailbox-Server funktioniert, auf dem ich den oben genannten Befehl nicht ausgefuehrt hatte.
Der Mailbox-Server, auf dem ich den Befehl hatte anwenden lassen, meldete beim Versuch, das alte self-signed Exchange-Zertifikat wieder zum
InternalTransportCertificate
zu machen, dass dies nicht moeglich sei und ich ein komplett neues Exchange-Zertifikat erstellen lassen muesse.
Dies habe ich anschließend entsprechend gemacht.
Zusaetzlich habe ich die Edge-Subscriptions fuer beide Edge-Transport-Server auf beiden Mailbox-Servern erneuert.
Damit war ich dann sozusagen wieder an dem Punkt wie vor dieser Odyssee.
Eigentliche Frage
Long story short:
Meine eigentliche Frage ist also, wie bereits oben erwaehnt:
Wie importiere ich unbeaufsichtigt ein Zertifikat und weise es dem SMTP-Dienst zu, ohne dabei das Standard-SMTP-Zertifikat zu ersetzen?
Vermutung zum Parameter
-Force
Wie ich aus Unwissenheit nun gelernt habe, macht der Parameter
-Force
anscheinend noch etwas anderes, als „nur“ das InternalTransport-Zertifikat zu ersetzen.
Dies habe ich daraus geschlossen, dass nichts bricht, wenn ich das Ganze ebenfalls ueber die GUI beziehungsweise EAC/ECP durchfuehre und dort per „Ja“ erlaube, dass das Standard-SMTP-Zertifikat ersetzt wird.
Mein Gedanke war nun, den Befehl nicht mit
-Force
, sondern mit
-Confirm:$false
auszufuehren, also so:
Enable-ExchangeCertificate -Server $TargetServer -Thumbprint $thumbprint -Services POP,IMAP,IIS,SMTP -Confirm:$false
Allerdings bin ich aus der Microsoft-Dokumentation nicht wirklich schlau geworden, ob dies nicht gegebenenfalls das Gleiche beziehungsweise dasselbe macht wie
-Force
.
Es geht konkret um folgenden Microsoft Artikel: Enable-ExchangeCertificate
Man koennte auch das Zertifikat auch fest den einzelnen Connectoren zuweisen ohne es direkt dem SMTP Dienst aufzudruecken, dass moechte ich jedoch nicht, da ich die „opportunistic TLS-Logik" von Exchange dafuer gern beibehalten wuerde.
Koennt Ihr mir ggf. sagen, wie ich das loesen kann? Bin ich ggf. komplett auf dem Holzweg? Ueber jeden Tipp bin ich dankbar.
Vielen Dank und liebe Grueße
Tom
Ich hab das jetzt etwas überflogen und das grundsätzliche Problem verstanden. ;) Eine Lösung habe ich aktuell nicht, aber zum Thema internes SMTP Zertifikat evtl. der Hinweis auf https://microsoft.github.io/CSS-Exchange/Admin/MonitorExchangeAuthCertificate/ schau dir mal an, wie MS das löst. ;)
Hallo Norbert,
vielen Dank fuer Deine rasche Antwort und den Artikel, den ich mir durchgelesen habe.
Es ist interessant zu sehen, dass Microsoft selbst das „Problem“ wohl kennt und anscheinend ebenfalls nur mit einem Workaround arbeitet.
Ich hatte tatsaechlich auch schon darueber nachgedacht, das
InternalTransportCertificate
im Nachgang einfach wieder automatisch auf den alten Stand zurueckzusetzen.
Leider ist es aber so, dass es nicht ausreicht, das existierende Zertifikat einfach wieder zu setzen. Stattdessen muss ein neues self-signed Zertifikat erstellt werden und zusaetzlich wird dabei auch noch EdgeSync zerschossen, zumindest alles auf dem ausfuehrenden Mailbox-Server.
Sich im Nachgang zusaetzlich auch noch um EdgeSync kuemmern zu muessen, ist mir leider zu viel, was dabei kaputtgeht — nur weil man eine Abfrage nicht automatisiert verneinen kann.
Ich habe stark das Gefuehl, dass ich den Elefanten im Raum uebersehe und grundsaetzlich bei meinem Vorgehen etwas falsch mache beziehungsweise falsch an die Sache herangehe.
Vielleicht gibt es ja auch ein Microsoft-Script fuer dieses Szenario? Leider konnte ich dazu bisher nichts finden.
Noch einmal vielen Dank fuer Deine Unterstuetzung.
Ich wuerde mich freuen, noch einmal von Dir zu hoeren, falls Du noch eine Idee haben solltest. Falls jemand anderes ebenfalls eine Idee hat, bin ich natuerlich auch fuer jeden Tipp sehr dankbar.
Liebe Gruesse
Tom
Wobei ich mich frage, warum die Edge Sync dabei kaputt geht, denn dafür ist afair doch das Zertifikat des Edge Servers relevant und nicht das der Mailbox Server.
Hallo Norbert,
das habe ich mich auch gefragt! Und ich kann es nicht beantworten. Leider moechte ich das nicht noch einmal mit dem Befehl "testen". Im aller schlimmsten Fall muss ich eine Testumgebung aufsetzen, in der ich mich austoben kann. Ist derzeit fuer mich aber zeitlich schwierig.
Falls noch Ideen da sind, gerne her damit :-)
Liebe Grueße
tom
Diesen Fehler hatten wir früher auch. Die Fehlermeldung lautet:
"A special Rpc error occurs on server SERVERNAME: The new internal Transport certificate with thumbprint XYZ you are about to configure on the local server isn't a Cryptographic API certificate.
The internal Transport certificate is also used by EdgeSync. EdgeSync only supports CAPI certificates. Try to generate a new CAPI certificate for the internal transport certificate."
Ursache: The private key of the current Exchange Transport default certificate of the internal Exchange servers uses a CNG private key. EdgeSync requires a CAPI1-based private key.
Lösung: Zertifikat beim Importieren konvertieren (Provider anpassen). Dann das konvertierte Zertifikat weiterverwenden.
certutil -p "<password>" -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx "xyz.pfx"
Nachtrag: "Enable-ExchangeCertificate -Force" überschreibt das existierende Zertifikat.
Wenn du das SMTP-Zertifikat vom Edge Server erneuerst, mußt du die Edge Subscription neu erstellen. Wenn du nur einen Edge Server hast, geht dabei der Sendconnector verloren.
Hallo Jenny,
vielen lieben Dank fuer Deinen Tipp.
Ja genau, die Fehlermeldung kenne ich ja bereits :-)
Nur ist es so, dass ich das self-signed default ITC gar nicht mehr ersetzen moechte. Dies habe ich zuvor auch nie gemacht, da es fuer mich bisher nie einen Grund dazu gab das zu machen. Da ich nun einmal damit auf die Nase gefallen bin, moechte ich das auch weiterhin nicht machen u.a. auch deshalb nicht, da Microsoft dies ebenfalls nicht fuer noetig haelt Assign certificates to Exchange Server services (auch wenn nicht alles Gold ist, was Microsoft so alles sagt *g*). Und dank funktionierenden „opportunistic TLS“, moechte ich dabei bleiben.
Hast Du oder sonst noch jemand einen Tipp, wie ich unbeaufsichtigt ein Zertifikat importiere und dieses dem SMTP-Dienst zuweise, ohne dabei das Standard-SMTP-Zertifikat zu ersetzen?
Vielen Dank und lieben Gruß
tom