Hallo,
auf einem frisch installieren Exchange 2019 auf Server 2022 Core habe ich mittels win-acme client ein Letsencrypt-Zertifikat installiert. Das Zertifikat ist im EAC sichtbar, soweit so gut. Wenn ich jedoch die beiden Dienste IIS und SMTP zuweisen will, funktioniert das nur für den IIS-Dienst. Das Häkchen beim SMTP-Dienst ist wieder verschwunden, sobald ich auf OK geklickt habe. Auch der Weg über die EMS funktioniert nicht. Es gibt keinerlei Fehlermeldungen, und im Web finde ich nichts Hilfreiches zu dem Problem. Hat jemand eine Idee, wo man hier ansetzen kann?
Vorab Danke und VG
Stefano
Erfahrungsgemäß Zertifikat exportieren (als PFX) und aus dem System löschen. Danach mit der Exchange Management Shell wieder importieren. Danach geht's im Allgemeinen.
Bye
Norbert
Vielen Dank für die schnelle Reaktion! Im EAC fehlt bei mir die Exportfunktion, keine Ahnung warum. Weil ich remote auf den Core-Exchange zugreife? Wenn ich es direkt auf dem Exchange-Server in der EMS versuche...
$cert = Export-ExchangeCertificate -Thumbprint '50E663977CB27972072EC99E78EECE7453109136' -BinaryEncoded -Password (ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force) [System.IO.File]::WriteAllBytes('\\localhost\ExchangeCert.pfx', $cert.FileData)
...gibt es eine Fehlermeldung beim Exportieren:
"Der private Schlüssel konnte nicht als PKCS-12 exportiert werden. Entweder war kein Zugriff möglich, oder der Schlüssel kann nicht exportiert werden."
Auch löschen im EAC geht nicht:
"Ein spezieller RPC-Fehler ist auf Server Mail-EXC aufgetreten: Das interne Transportzertifikat kann nicht entfernt werden, weil dies das Beenden des Microsoft Exchange-Transportdiensts bewirken würde..."
Kannst du nochmal helfen?
Merci,
Stefano
Dann ist der Schlüssel als nicht exportierbar markiert. Und normalerweise bindet man das externe Zertifikat auch nicht als standardzertifikat für smtp ein. Ich kenne dein let’s encrypt Skript nicht, deswegen musst du selbst mal schauen.
Und normalerweise bindet man das externe Zertifikat auch nicht als standardzertifikat für smtp ein.
Hi @NorbertFe,
ich muss den Thread nochmal kurz hochholen. Welches Zertifikat wird dann für SMTP benutzt?
Weil auch Frank in seinem Artikel mit dem WIN-ACME Client (WACS) das externe Let's Encrypt Zertifikat an den SMTP-Dienst bindet.
wacs.exe --source manual --host outlook.domian.de,autodiscover.domain.de --certificatestore My --acl-fullcontrol "Netzwerkdienst,Administratoren" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.v2.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"
Oder verstehe ich etwas falsch?
Wir hatten jetzt schon 2x das Problem, dass wir ein per DNS erneuertes Let's Encrypt Zertifikat, nicht an den SMTP-Dienst binden konnten. Und da der WIN-ACME Client (WACS) das alte Zertifikat löscht, konnte der SMTP-Dienst von (Outbound to Office 365) die E-Mails von den lokalen Systemen, nicht zu Office 365 verschicken - da er das "alte" Zertifikat nicht mehr finden konnte.
454 4.7 5 the certificate specified in tlscertificatename of the sendconnector could not be found
Get-SendConnector | fl Name,Tls* Name : Outbound to Office 365 - xxx TlsDomain : mail.protection.outlook.com TlsAuthLevel : DomainValidation TlsCertificateName : <I>CN=R10, O=Let's Encrypt, C=US<S>CN=outlook.xxx.com
Einzige Lösung war bisher, das alte, aus dem Zertifikatsspeicher gelöschte Zertifikat, per Powershell vom "Outbound to Office 365 " zu entfernen.
Set-SendConnector -Identity "Outbound to Office 365 ..." -TlsCertificateName $Null
Get-SendConnector | fl Name,Tls* Name : Outbound to Office 365 - xxx TlsDomain : mail.protection.outlook.com TlsAuthLevel : DomainValidation TlsCertificateName :
Mich würde eure Meinung dazu interessieren.
Danke euch!