Greetings, I'm new to OpenJDK development so please forgive if this is not the correct protocol.
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. Regards, Tjalfe [1] https://bugs.openjdk.org/browse/JDK-8313367 [2] https://github.com/openjdk/jdk/pull/8211
