Skip to content

Fatal error when JAVA_HOME is set incorrectly #472

Closed

Description

@Hacksore

Environment

  • Operating system (including version): macOS 12.4 (21F79)
  • mkcert version (from mkcert -version): v1.4.4
  • Server (where the certificate is loaded): N/A
  • Client (e.g. browser, CLI tool, or script): N/A

What you did

Ran mkcert -install

What went wrong

Error for reference

$ mkcert -install
The local CA is now installed in the system trust store! ⚡️
ERROR: failed to execute "keytool -list": exit status 1

keytool error: java.lang.Exception: Keystore file does not exist:

I have my JAVA_HOME ($HOME/homebrew/opt/openjdk) set to a user based homebrew location but it seems that neither of the following files exists causing the util to fatally abort.

This forces the util to execute an invalid command with a missing param passed to -keystore.

$HOME/homebrew/opt/openjdk/bin/keytool -list -keystore  -storepass changeit

tl;dr when using a java install via homebrew set your JAVA_HOME to somewhere that has the file mkcert is looking for 😅.

This is ultimately what worked for me 🥳.

JAVA_HOME=<homebrewDir>/Cellar/openjdk/19/libexec/openjdk.jdk/Contents/Home"

Hope this helps anyone else who runs into a similar issue.

Activity

  1. changed the title [-]Fatal error when `JAVA_HOME` is set[/-] [+]Fatal error when `JAVA_HOME` is set incorrectly[/+] on Oct 13, 2022
  2. Hacksore commented on Oct 30, 2022

    @Hacksore
    Author

    I've opened a PR with a fix here #474

  3. fcorneli commented on Nov 9, 2022

    @fcorneli

    Would be nice if, on Mac OS, every JVM under /Library/Java/JavaVirtualMachines would be like "root infected", not only the JAVA_HOME one.

  4. joelpittet commented on Dec 17, 2022

    @joelpittet

    Thanks @Hacksore I was using jenv https://www.jenv.be/ and it's openjdk64-11.0.15 java version had a path
    ~/.jenv/versions/openjdk64-11.0.15/libexec/openjdk.jdk/Contents/Home before those sub paths were correct like your fantastic issue summary indicated. openjdk64-11.0.17 or 11.0.17 had the paths needed for this fix.

  5. Hacksore commented on Dec 17, 2022

    @Hacksore
    Author

    @joelpittet glad it helped you.

    Still waiting for @FiloSottile to have a look at the open PR to at least warn for this.

  6. Hacksore commented on Jun 17, 2023

    @Hacksore
    Author

    Lost interest in this in favor of caddy. Maybe this will get traction at some point but at least there is a workaround now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions