ADDITIONAL SYSTEM INFORMATION :
OS:  Windows 11 version 22H2, or Windows Server 2022

OpenJDK: 17.0.8, or 20.0.2


A DESCRIPTION OF THE PROBLEM :
The enhancement developed to allow keystore access provider SunMSCAPI to access the Windows Local Computer keystore, JDK-6782021, works as expected only if processes are run as elevated.

https://bugs.openjdk.org/browse/JDK-6782021

But with non-elevated access, the SunMSCAPI provider fails to access a read only private key from the Local Computer certificate store.

StackOverflow user "Andreas Gusenbauer" posted a question on this issue in January, 2023:

https://stackoverflow.com/questions/75255985/java-keystore-type-windows-my-root-localmachine-requires-administrator-permissio





STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The StackOverflow post includes an answer from user "Snaps-A-Lot", which includes instructions on how to reproduce the issue complete with images and references.   But for this bug report, here is a top-down written instruction:

To reproduce the issue:

1)  Login to Windows using an account with membership in the local Administrators group.

2)  Create a self signed code signing certificate using the Powershell:
    $cert = New-SelfSignedCertificate -DNSName "JDK-6782021 Read Only Test" -CertStoreLocation Cert:\LocalMachine\My -Type CodeSigningCert -FriendlyName "JDK-6782021"

3)  Open the Control Panel, search for "certificates", click Manage Computer Certificates, expand Personal Certificates, right click the certificate issued to "JDK-6782021 Read Only Test".  From the menu, click "All Tasks / Manage Private Keys...".  In the pop-up dialog, add your user name, grant it "Allow" Read access (and nothing else), and click Okay to save your changes.

4)  Install a recent version of Visual Studio, such as Visual Studio 2019, if it is not already installed.  Locate singtool.exe on the system, and add its folder to the Path.

5)  Install OpenJDK 17.0.8, if it is not already installed. Add its "bin" folder to the Path.

6)  Open a non-elevated (Not "Administrator"" command prompt.

7)  Create a temporary folder, and make it current:
    md C:\temp\JDK-6782021_test
    cd C:\temp\JDK-6782021_test

8)  Copy any EXE file to the temporary folder, and rename it to MyApp.exe.

9)  Copy any JAR file to the temporary folder, and rename it to MyPkg.jar.

10) From the non-elevated command prompt, enter the following commands:

    signtool sign /sm /i "JDK-6782021 Read Only Test"  MyApp.exe
    jarsigner -keystore NONE -storetype Windows-MY-LocalMachine -providerClass sun.security.mscapi.SunMSCAPI MyPkg.jar JDK-6782021


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
C:\temp\JDK-6782021_test> signtool sign /sm /i "JDK-6782021 Read Only Test"  MyApp.exe
Done Adding Additional Store
Successfully signed: MyApp.exe

C:\temp\JDK-6782021_test> jarsigner -keystore NONE -storetype Windows-MY-LocalMachine -providerClass sun.security.mscapi.SunMSCAPI MyPkg.jar JDK-6782021
jar signed.
ACTUAL -
Microsoft's signtool.exe successfully complete a code signature based on a read only ky from the Windows Local Computer keystore:, while the OpenJDK jarsigner.exe utility fails to do likewise:

C:\temp\JDK-6782021_test> signtool sign /sm /i "JDK-6782021 Read Only Test"  MyApp.exe
Done Adding Additional Store
Successfully signed: MyApp.exe

C:\temp\JDK-6782021_test> jarsigner -keystore NONE -storetype Windows-MY-LocalMachine -providerClass sun.security.mscapi.SunMSCAPI MyPkg.jar JDK-6782021
jarsigner error: java.lang.RuntimeException: keystore load: java.security.KeyStoreException: error 5, Access is denied.

CUSTOMER SUBMITTED WORKAROUND :
There is no true workaround for a high security environment, since the functionality added for JDK-6782021 cannot be used in a secure environment.    Instead, users must resort to pre-JDK-6782021 techniques.

Running the test from an elevated prompt will yield the expected success, but that would violate basic security policy due to the requirement for the user to be a member of the Local Administrators group.

To proceed with signing code, a better approach is to revert to using the "Windows My-CurrentUser" key store (or simply "Windows My") keystore, as was done prior to the JDK-6782021 enhancement.  Private key access control is not available, although export can still be disabled.  The certificate would also have to be deployed once for each user, but at least they can run without elevated access.

FREQUENCY : always