Toggle/Change Windows Cert search context between CERT_SYSTEM_STORE_USER and CERT_SYSTEM_STORE_LOCAL_MACHINE for "MY"

[joemcse]

Since the MY path for CERT_SYSTEM_STORE_LOCAL_MACHINE\MY cert store is not inherited into CERT_SYSTEM_STORE_USER\MY, it would be useful to be able to toggle the search path between Local Machine and User certs.

So some flag that allows us to choose our Context between USER and LOCAL_MACHINE for Windows CNG Store.

[dwmw2]

This kind of thing would ideally be part of a URI rather than a separate flag. A quick glance at https://learn.microsoft.com/en-us/powershell/module/pki/get-certificate?view=windowsserver2022-ps seems to suggest PowerShell supports a pathname of the form cert:\LocalMachine\My\EEDEF61D4FF6EDBAAD538BB08CCAADDC3EE28FF

GnuTLS also has a system: URI which works with the Windows certificate store.

[joemcse]

Yeah that would work for me. My workaround is to copy a cert to another store in LocalMachine... and it get's inherited and I can use the --system-store-name (but works in the CurrentUser path due to inheritance). Trying to take advantage of existing certs placed in LocalMachine\My

[jmullaney]

I'm hitting this same issue.
It's a bit tricky on my side... this is for a complex and old system where different services are running as different users for various reasons, but may nevertheless need to access S3 using IAMRA. Customers probably cannot reliably handle putting the cert and key in multiple user's "MY" store (it is a challenge for one cert per server, now we're adding a cert and multiplying the places it needs to go). I could copy from Local Machine, but customers will probably also balk at making the key exportable. Not sure what to do... maybe I can have yet another service the others can call, that wraps the credential helper with a single user? Puzzle through performing the request myself?
Learn go and implement the proposed option myself?

[nas-ttatewaki]

I'm planning to submit a PR for this. Before that, I'd like some feedback on the approach.

My current implementation adds a --system-store-location flag (CurrentUser | LocalMachine) as a separate option from --system-store-name. I looked into the URI-based approach dwmw2 mentioned, but PowerShell and GnuTLS use different URI formats and there's no unified standard, so I went with a plain flag instead.
Another option would be to extend --system-store-name to accept a path like LocalMachine/MY, though that changes the semantics of an existing flag.

Any preference on direction?

[joemcse]

Thaks for lioking into this. I went with the separate --system-store-location flag specifically to avoid the URI ambiguity you mentioned. Since Windows treats Store Location (CurrentUser/LocalMachine) and Store Name (My/Root) as distinct hierarchical layers in the API, a flat URI string often requires custom parsing logic that varies between tools. ​By keeping them as separate flags: ​We maintain backward compatibility (defaulting to CurrentUser). ​We make it much easier for automated deployment scripts (like Intune or Group Policy) to pass simple strings without worrying about escaping slashes or colons. ​It mirrors the structure of the Windows .NET and C++ certificate APIs, which developers on this platform expect." Sent from my T-Mobile 5G Device Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: nas-ttatewaki ***@***.***> Sent: Friday, February 13, 2026 12:03:44 PM To: aws/rolesanywhere-credential-helper ***@***.***> Cc: joemcse ***@***.***>; Author ***@***.***> Subject: Re: [aws/rolesanywhere-credential-helper] Toggle/Change Windows Cert search context between CERT_SYSTEM_STORE_USER and CERT_SYSTEM_STORE_LOCAL_MACHINE for "MY" (Issue #70) [https://avatars.githubusercontent.com/u/154297195?s=20&v=4]nas-ttatewaki left a comment (aws/rolesanywhere-credential-helper#70)<#70 (comment)> I'm planning to submit a PR for this. Before that, I'd like some feedback on the approach. My current implementation adds a --system-store-location flag (CurrentUser | LocalMachine) as a separate option from --system-store-name. I looked into the URI-based approach dwmw2 mentioned, but PowerShell and GnuTLS use different URI formats and there's no unified standard, so I went with a plain flag instead. Another option would be to extend --system-store-name to accept a path like LocalMachine/MY, though that changes the semantics of an existing flag. Any preference on direction? — Reply to this email directly, view it on GitHub<#70 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHDNFE464FKCCH25L7KYKSD4LYU2BAVCNFSM6AAAAACVCJRIZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJZGE4DINJUG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>