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:
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 verweigertbei 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:
Bei einer Windows CA lässt sich die Eigenschaft auf der Zertifikatsvorlage festlegen:
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:
In der settings.json lässt sich dazu die Einstellung “PrivateKeyExportable” auf “True” setzen:
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
Nachdem das Zertifikat erneuert wurde, kann das Exchange Setup neu gestartet werden. Das Setup erkennt eine unvollständige Installation und wird dann abgeschlossen:
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:
