WIN-ACME: Installation eines Exchange CUs schlägt fehl

Bei einem Exchange 2016 Server, der sein Zertifikat von Let’s Encrypt mit dem WIN-ACME Client konfiguriert hatte, ist die Installation eines CUs mit einem Fehler bei Schritt 16 von 18 abgebrochen worden:

WIN-ACME: Installation eines Exchange CUs schlägt fehl

Hier der komplette Test der Fehlermeldung:

Fehler:
Der folgende Fehler wurde generiert, als „$error.Clear();
Install-ExchangeCertificate -services „IIS, POP, IMAP“ -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
{
Install-AuthCertificate -DomainController $RoleDomainController
}
“ ausgeführt wurde: „Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleCryptographicException: Aufgrund einer Kryptografieausnahme konnte konnte kein Netzwerkdienstzugriff auf das Zertifikat mit dem Fingerabdruck 1xxxxxxxxxxxxxxxxxx erteilt werden. —> System.Security.Cryptography.CryptographicException: Zugriff verweigert

bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ManageExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services, String websiteName, Boolean requireSsl, ITopologyConfigurationSession dataSession, Server server, List`1 warningList, Boolean allowConfirmation, Boolean forceNetworkService)
— Ende der internen Ausnahmestapelüberwachung —
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

Der wichtige Teil der Fehlermeldung ist folgender:

Aufgrund einer Kryptografieausnahme konnte konnte kein Netzwerkdienstzugriff auf das Zertifikat mit dem Fingerabdruck 1xxxxxxxxxxxxxxxxxx erteilt werden

Das Problem Problem war an dieser Stelle, dass der Export des privaten Schlüssels des Zertifikats bei der Konfiguration nicht erlaubt wurde (PrivateKeyExportable). Diese Eigenschaft für den privaten Schlüssel lässt sich beim Import oder beim Ausstellen des Zertifikats via Zertifikatsvorlage festlegen:

PrivateKeyExportable

Bei einer Windows CA lässt sich die Eigenschaft auf der Zertifikatsvorlage festlegen:

PrivateKeyExportable Template

In diesem Fall wurde das Zertifikat wie bereits erwähnt mit dem WIN-ACME Client ausgestellt. Auch im WIN-ACME Client lässt sich einstellen, ob der private Schlüssel exportierbar sein soll. In der Standardeinstellung wird der private Schlüssel als nicht exportierbar markiert. Ändern lässt sich dies in der Datei “settings.json” des WIN-ACME Clients:

WIN-ACME settings.json

In der settings.json lässt sich dazu die Einstellung “PrivateKeyExportable” auf “True” setzen:

WIN-ACME settings.json

Diese Einstellung wirkt sich natürlich nicht auf bereits ausgestellte Zertifikate aus, daher muss das Zertifikat erneuert werden. Die Erneuerung des Zertifikats kann mit dem folgenden Befehl durchgeführt werden:

wacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org/" --force

Zertifikat erneuern

Nachdem das Zertifikat erneuert wurde, kann das Exchange Setup neu gestartet werden. Das Setup erkennt eine unvollständige Installation und wird dann abgeschlossen:

image

Wenn das Zertifikat über eine Windows CA ausgestellt wurde, lässt sich wie bereits erwähnt die Vorlage ändern und das Zertifikat via MMC erneuern:

image

8 Gedanken zu „WIN-ACME: Installation eines Exchange CUs schlägt fehl“

  1. Ich habe das gleiche Problem festgestellt, aber eine andere Lösung gefunden: der Task zum Erneuern läuft mit Systemrechten, also auch die Installation des Zertifikats. Hab also mit Systemrechten (PSEXEC) die Zertifikats-MMC geöffnet und in der Verwaltung des privaten Schlüssels für das Zertifikat die Domänen-Admins mit Vollzugriff hinzugefügt. So konnte das ausführende Administrator-Konto bei der CU-Installation auf den Schlüssel zugreifen.
    Da der privaten Schlüssel bei WinACME geheim, also auf dem Gerät, bleiben sollte, hält die Maßnahme hoffentlich bis mindestens zum nächsten CU.

    PS: Wie hast du es gelöst, dass dir das „bald ablaufende“ LE-Zertifikat nicht das Eventlog vollballert?

    Antworten
  2. Hallo Franky,

    vielen Dank für den Tipp:

    Aber:
    Wenn die Installation fehlerhaft ist, kann man nicht einfach via ACME das Zert erneuern via force, da ja wichtige Exchange-Dienste nicht laufen (auch nicht die componentstates);

    Bei mir half hier nur:
    1. Restore / ggf. Reparatur der Dienste und manuelles Setzen der Componentstates? (nicht versucht)
    2. dann ACME wacs –force (siehe oben):
    wacs.exe –renew –baseuri „https://acme-v02.api.letsencrypt.org/“ –force

    Antworten
    • Ja, das ist mir auch aufgefallen.

      Das hier hat mir geholfen: den wacs…-force Befehl erst abschicken, wenn der erneute Aufruf des CU gestartet wurde. Dort heißt es nach Schritt 1 ganz kurz „Systemdienste werden wiederhergestellt“, dann kommt „Schritt 2 von 11 Sprachen“. Wenn man dann den wacs…-force abschickt, läuft er durch. Habe das mit zwei verschiedenen Exchange-Installationen (EX19 auf W19 und EX16 auf W12R2) ausprobiert.

      Antworten
  3. Danke Deine Tips haben mir schon oft aus der Klemme geholfen!
    Diesmal ging gar nichts mehr da ich in das Rate Limit bei Letsencrypt reingerutscht bin (zuerst lesen und nicht immer gleich ENTER drücken LOL)

    Zertifikat im IIS löschen – irgendein Selfsigned Exchange Cert sowohl für die default website als auch dem Exchange Backend zuordnen
    – Setup erneut ausführen – und das wars
    Nachher natürlich ein neues Cert anfordern

    Antworten
  4. Bei mir war es auch mal wieder Zeit für Frankysweb. Was ich schon gek..zt habe weil irgend eine schei.. Meldung gekommen ist und Frankysweb hat immer was kompaktes als Lösung gehabt wie auch dieses mal. Jedenfalls sollten sich mal Microsoft und andere ein Beispiel daran nehmen.
    Bei mir hat es auch genau so gelappt wie oben beschrieben.
    Ich bin euch allen dankbar das Ihr eurer KnowHow teilt.
    Danke an Dich Frank das Du so eine Seite pflegst!!

    Antworten

Schreibe einen Kommentar