Thanks for reporting this issue. I added a comment to
https://bugs.openjdk.org/browse/JDK-8313367 and asked Mat Carter if he
could take a look at the issue.
--Sean
On 11/11/25 5:19 AM, Tjalfe Krause wrote:
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
