On Wed, 10 Apr 2024 14:43:27 GMT, Weijun Wang <wei...@openjdk.org> wrote:

>> rebarbora-mckvak has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   8313367: signHash looks for a key in either user or machine store
>
> The code change looks good to me. I think it's OK to show an entry as a 
> certificate entry if the private key is not available. After all, the 
> certificates in both entries are treated as trusted. I'll run some tests and 
> approve it.
> 
> BTW, please update the copyright year of the class.

@wangweij , per the suggestion from @rebarbora-mckvak , it is possible to 
extract the public certificate, and use it to facilitate runtime verifications. 
  For example, after following the steps to reproduce, run the following to 
save it to disk:

`keytool -exportcert -alias JDK-6782021 -keystore NONE -storetype 
Windows-My-LocalMachine -providername SunMSCAPI -file MyPublicKey.cer`

Next, double click MyPublicKey.cer, click "Install Certificate ...", and use 
the Certificate Import Wizard to import it to the Local Computer "Trusted Root 
Certification Authorities" keystore.  If you create a PFX file including only 
this certificate, it will show as a "trustedCertEntry in the output of a 
`keytool -list` command.  By contrast, if you export the code signing 
certificate to a PFX, it will show as a "PrivateKeyEntry" as you have observed.

The user's access to the private key is controlled via the ACL that is modified 
in Step 3 of the steps to reproduce.   If the user lacks access, that is where 
to fix it.  The step above facilitates cleaner runtime verification but does 
not control access.

NOTE:  _The `keytool` command above will work on a non-elevated command prompt, 
but only if it is built including the fix for JDK-8313367.  Otherwise, it will 
get the same "Access Denied" error as `jarsigner` when accessing a Local 
Computer certificate.  In that case, the temporary workaround is to run it from 
an elevated prompt._

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-2048565670

Reply via email to