On an Exchange 2016 server that had configured its certificate from Let's Encrypt with the WIN-ACME client, the installation of a CU was aborted with an error at step 16 of 18:
Here is the complete test of the error message:
Error:
The following error was generated when "$error.Clear();
Install-ExchangeCertificate -services "IIS, POP, IMAP" -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
{
Install-AuthCertificate -DomainController $RoleDomainController
}
" was executed: "Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleCryptographicException: Due to a cryptography exception, network service access to the certificate with the fingerprint 1xxxxxxxxxxxxxxxxxxxx could not be granted. -> System.Security.Cryptography.CryptographicException: Access deniedfor Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
for Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
for 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)
- End of internal exception stack monitoring -
for Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
for Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
for Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
for Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
for Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
for Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".
The important part of the error message is as follows:
Due to a cryptography exception, network service access to the certificate with the fingerprint 1xxxxxxxxxxxxxxxxxxxxxx could not be granted
The problem at this point was that the export of the private key of the certificate was not allowed during configuration (PrivateKeyExportable). This property for the private key can be defined when importing or issuing the certificate via the certificate template:
With a Windows CA, the property can be set on the certificate template:
In this case, as already mentioned, the certificate was issued with the WIN-ACME Client. You can also set whether the private key should be exportable in the WIN-ACME Client. In the default setting, the private key is marked as non-exportable. This can be changed in the "settings.json" file of the WIN-ACME client:
The "PrivateKeyExportable" setting can be set to "True" in the settings.json:
Of course, this setting does not affect certificates that have already been issued, so the certificate must be renewed. The certificate can be renewed with the following command:
wacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org/" --force
After the certificate has been renewed, the Exchange setup can be restarted. The setup recognizes an incomplete installation and is then completed:
If the certificate was issued via a Windows CA, the template can be changed as already mentioned and the certificate renewed via MMC:
Top! Hat mir den H*ntern gerettet, gilt auch (natürlich) für den von mir aktualisierten Exchange 2019 CU12 > 13. :-)
Wie immer: Vielen Dank!
Ich hatte das Problem, dass mein Zertifikat bereits exportierbar war aber ich dennoch denselben Fehler erhalten habe.
Musste dann in der Zertifikatsverwaltung bei dem betroffenen Zertifikat, dem ausführenden User vom CU Upgrade, Besitzrechte auf’s Zertifikat geben + Vollzugriff.
Anschließend funktionierte die Installation :-)
Hallo Supajo,
wie hast du das denn hinbekommen, die Besitzrechte zu vergeben? Hast du das dementsprechende Skript abgefeuert oder durch die GUI die Besitzrechte gesetzt?
LG
Svenja
Exchange 2016 CU22 Installation, voll reingelaufen aber schon wieder hat einer deiner Beiträge geholfen die Sache unter Kontrolle zu bringen. Bis ich die Lösung bei Microsoft gefunden hätte, wäre es Mitternacht gewesen, wenn überhaupt.
Vielen Dank Frank!
Danke für die immer wieder hilfreichen Tipps!
Bei mir lief beim ersten Versuch das Setup bis Schritt 16 und brach dann mit dem beschriebenen Zertifikatsfehler ab. Ich habe das Setup abgebrochen und mit dem wacs…force Befehl das Zertifiakt wie beschrieben erneuert. Beim erneuten Start des Setup hat der Server die unvollständige Installation erkannt und begann von Neuem. Bie Schritt 16 brach das Ganze ab mit dem allgemeinen Fehler „Exchange funtkioniert nicht mehr; Mirosoft wird Sie unterrichten, wenn eine Lösung vorhanden ist“.
Danach habe ich den Server aus dem Backup wiederherstellen müssen. Danach hat es mich noch einige Zeit gekostet, den Server wieder aus dem Wartungsmodus zu holen.
Beim 2. Versuch habe ich das Zertifikat vor dem Setup erneuert. Jetzt lief alles problemlos durch
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!!
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
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
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.
Super Tillmann, hat hier bei Exchange 2016 CU22 auch funktioniert – Timing ist alles ;-)
Damit warst du für mich der Retter des Abends, zusammen mit Franky.
Vielen Dank!
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?
Das war heute auch meine Lösung! Der Austausch des Zertifikats klappte zwar als ich den Update-Befehl zu Beginn des Installationsprozesses ausgeführt hatte, aber ich vermute, dass die Setup Routine das alte Zertifikat (ohne exportierbaren private key) noch im Cache hatte … das Setup lief dann durch und nach dem anschließenden reboot lief alles … DANKE!
Super analysiert! Danke. Für mich leider zu spät, bin leider da voll reingefallen ;-)