Private key is not exportable about win-acme

[lug-gh]

Hi, I'm facing the same issue, but as I use the Microsoft Exchange install (https://www.win-acme.com/manual/advanced-use/examples/exchange),
i use --acl-fullcontrol "network service,administrators"
When initially creating the certificate, the key is exportable by the administrator, but after renewal, the administrator has no access to the private key, thus the Exchange update fails. Is this related?
As far as I understand it, fullcontrol should include read. The certificate was created with version 2.2.6

[woutertinusf19]

Maybe thats because the system language of that server is german.

Possibly, you could try with the German translations for those two roles/groups.

[lug-gh]

Maybe thats because the system language of that server is german.

Possibly, you could try with the German translations for those two roles/groups.

I exchanged it with "Netzwerkdienst,Administratoren", now the errors are gone. I'll see in 2 months if the renew succeeded, but I'm confident. Maybe this should be added to the documentation, but first I'll wait to check it.

[WouterTinus]

I was able to reproduce this. The certificate is actually marked as exportable in the store, but you don't have access to its private key as a regular admin, only SYSTEM does, hence you still cannot export it.

As a workaround, you can use psexec to run the certificate manager as system to export it, or have win-acme add you (or your group) to the ACL by providing the command line parameter --acl-read when you create the certificate.

In the next version I will automatically grant the local administrators group read access if the certificate is requested to be exportable.

[mont-foray]

Great and thank you for the suggestions.

[WouterTinus]

Can you post a log of your renewal?

[webprofusion-chrisc]

We have a similar issue over here: https://community.certifytheweb.com/t/exchange-2019-failing-to-install-cu14-with-installed-certificate/2173/8

I think this is an assumption about private key access that the exchange update script is making.

[lug-gh]

Can you post a log of your renewal?

Maybe I found the issue in the logs, but if you need the full log, just tell me ;)

BUT: This error happens on creation AND on renewal. But the newly created cert can be exported by administrators, the renew cannot. Should I create a new issue?

cert creation:

2023-11-16 15:14:58.647 +01:00 [WRN] Unable to set full control rights for network service: Some or all identity references could not be translated.
2023-11-16 15:14:58.669 +01:00 [VRB]    at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.NTAccount.Translate(Type targetType)
   at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified)
   at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
   at PKISharp.WACS.Plugins.StorePlugins.CertificateStore.SetAcl(X509Certificate2 cert, List`1 fullControl)
2023-11-16 15:14:58.672 +01:00 [WRN] Unable to set full control rights for administrators: Some or all identity references could not be translated.
2023-11-16 15:14:58.672 +01:00 [VRB]    at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.NTAccount.Translate(Type targetType)
   at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified)
   at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
   at PKISharp.WACS.Plugins.StorePlugins.CertificateStore.SetAcl(X509Certificate2 cert, List`1 fullControl)
2023-11-16 15:14:58.675 +01:00 [VRB] Autofac: creating PluginBackend<IInstallationPlugin> scope with parent PluginBackend<ICsrPlugin>
2023-11-16 15:14:58.677 +01:00 [VRB] Autofac: creating PluginBackend<IInstallationPlugin> scope with parent PluginBackend<ICsrPlugin>

cert renewal:

2024-01-11 09:50:31.568 +01:00 [WRN] Unable to set full control rights for network service: Some or all identity references could not be translated.
2024-01-11 09:50:31.595 +01:00 [VRB]    at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.NTAccount.Translate(Type targetType)
   at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified)
   at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
   at PKISharp.WACS.Plugins.StorePlugins.CertificateStore.SetAcl(X509Certificate2 cert, List`1 fullControl)
2024-01-11 09:50:31.598 +01:00 [WRN] Unable to set full control rights for administrators: Some or all identity references could not be translated.
2024-01-11 09:50:31.598 +01:00 [VRB]    at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.NTAccount.Translate(Type targetType)
   at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified)
   at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
   at PKISharp.WACS.Plugins.StorePlugins.CertificateStore.SetAcl(X509Certificate2 cert, List`1 fullControl)

Maybe thats because the system language of that server is german.

[rgomezc]

Hello. I am experiencing something similar.

My original certificate did not include the ACL option. I was actually looking for weeks how to modify the command line used for the renewal without luck.

Until I entered to "modify" the certificate on WACS directly. Doing so, and after a while, I managed to pass the --acl-fullcontrol option for the task. I first tried with ".\IME_SYSTEM" without luck, then using the name of the computer, also without working. Until I used the name of the account only, without the .\ or the , then win-acme managed to identify (at least for what it showed on the screen) the account. The command line was modified.

But renewing the certificate, force, no cache, does not change the permissions for the certificate in the certificate store. I can see this on the log:

2024-02-20 15:50:10.994 -06:00 [VRB] Private key found at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\84369fa9a3045bf8bcc8fe186ac7ba7d_1dd83ba5-f0ef-4fb0-8000-c32110fdceb5
2024-02-20 15:50:10.997 -06:00 [INF] Add full control rights for ime_system
2024-02-20 15:50:10.998 -06:00 [VRB] Autofac: creating PluginBackend<IInstallationPlugin> scope with parent PluginBackend<ICsrPlugin>
2024-02-20 15:50:11.005 -06:00 [VRB] W3SVC detected and running
2024-02-20 15:50:11.005 -06:00 [VRB] No FTPSVC detected
2024-02-20 15:50:11.046 -06:00 [INF] Installing with IIS...

But still, when checking the certificate it doesn't show the account. Only SYSTEM and the group Administrators.

I don't know if the next renewal will use or not the account. All the tests I have done is renewing directly from the CLI, using the force, no cache option. I have also tried with the --acl-read option, but it appears to be the same.

This is, BTW, so my Mail Server (MailEnable) can use the certificates, so in a sense is similar to what is needed for Microsoft Exchange.

I am on the latest available version as of today: 2.2.7.1612.

[WouterTinus]

That's curious. If you check the ACL of that file logged in Explorer (C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\84369fa9a3045bf8bcc8fe186ac7ba7d_1dd83ba5-f0ef-4fb0-8000-c32110fdceb5) does in include ime_system?

And if it does, how do you conclude that there are insufficient permissions? Please note that for the certificate to be exportable, there's only a global setting ("PrivateKeyExportable": true), which needs to be enabled in addition to having the right permissions.

[rgomezc]

Thanks for the reply, @WouterTinus - I have just checked the file on Explorer and it in fact includes IME_SYSTEM.

So, it probably is my misunderstanding of what or where the ACLs are applied.

At the end, what I have needed to do for MailEnable to be able to read the certificate is add that user, IME_SYSTEM, to the list shown when entering via: the Certificates (certlm.msc), then select the Personal Folder, Certificates, select the Certificate, then "all tasks" and then, "manage private keys". I don't know if this are the correct steps, I'm translating from a Spanish locale Windows. That is where I don't see the IME_SYSTEM being added.

Regarding the "PrivateKeyExportable": true, I do have that setting on my settings.json file.

[WouterTinus]

Hi Rgomez, that's weird. I have no idea how to add permissions if not by editing the ACL on that file. What happens to the ACL if you add another random user on the control panel?

[rgomezc]

Hello Wouter. Sorry for the late reply.

I have just made some tests, and effectively, adding a user in the control panel changes the ACLs on the file, and viceversa. So I am not sure why I haven't seen that "correctly" happening when renewing the certs.

I will try again a renewal and see what happens. Maybe the problem is elsewhere, between the keyboard and the chair...

[mont-foray]

I can confirm that v2.2.8 can now export private keys from a certificate renewed via Windows task.