Description below copied from an issue reported by Tjalfe Krause on the security-dev list: https://mail.openjdk.org/pipermail/security-dev/2025-November/049398.html

Regarding the fix for unprivileged read access to the Windows truststores (JDK-8313367 [1]) it seems it results in some problematic behavior.

If the user used to access the "Windows-MY-LOCALMACHINE" keystore has write access to the store but is not an administrator it is possible to read certificates from "Windows-MY-LOCALMACHINE", but when importing or deleting certificates the store used is "Windows-MY-CURRENTUSER".
After the (JDK-8313367) change an executing account can read certificates in the "Windows-MY-LOCALMACHINE" keystore without issue. The issue arises when using the same keystore to import or delete certificates in the then the "Windows-MY-LOCALMACHINE " store, they are unexpectedly targeting the "Windows-MY-CURRENTUSER" keystore instead do to the fact that the changes from (JDK-8313367) is not implemented in the store/delete operations.

Steps to reproduce:

1: Give an account write access to "Windows-MY-LOCALMACHINE" by setting "Full control" permissions on " HKLM:\SOFTWARE\Microsoft\SystemCertificates\MY"
2: In Java: Open "Windows-MY-LOCALMACHINE" keystore as the account
3: In Java: Import at certificate into the keystore
4: The certificate ends up in "Windows-MY-CURRENTUSER" instead of the specified "Windows-MY-LOCALMACHINE" keystore.

The fix seems be quite simple:
Implement the same logic that was introduced in PR #8211 [2].

In security.cpp: Add "jint jCertStoreLocation" parameter to "Java_sun_security_mscapi_CKeyStore_storeCertificate" and "Java_sun_security_mscapi_CKeyStore_removeCertificate"
In sun/security/mscapi/CKeyStore.java: pass in the "getLocation()" value in setCertificateChain/delete

If you need a working code to reproduce the error or a diff of the suggested fix, I can provide these as well.