Executable not found in path

[aprasadh]

I tried running mkcert version 1.1.0 in windows. I got the following error.

$ mkcert-v1.1.0-windows-amd64.exe example.org
Using the local CA at "C:\Users\XXXXX\AppData\Local\mkcert"
ERROR: failed to execute "keytool -list": exec: "": executable file not found in %PATH%

[ajsb85]

mkcert-v1.1.0-windows-amd64.exe -install
Using the local CA at "C:\Users\XXXXX\AppData\Local\mkcert" ✨
The local CA is now installed in the system trust store! ⚡️
Note: Firefox support is not available on your platform. ℹ️
ERROR: failed to execute "keytool -list": exec: "": executable file not found in %PATH%

keytool -list
keytool error: java.lang.Exception: Keystore file does not exist: C:\Users\alexa\.keystore

[daniellockard]

That means you don't have java's keytool installed. Might want to install it.

[aprasadh]

I ran keytool -list and I got this

keytool error: java.lang.Exception: Keystore file does not exist: C:\Users\XXXXX\.keystore

[nickkaczmarek]

I'm having the same issue and getting the same response as @aprasadh from "%JAVA_HOME%\bin\keytool.exe" -list as well as keytool -list. This isn't something I recall having to do for mkcert on macos or ubuntu.

[nickkaczmarek]

@cretz Is this something you encountered in your local instance of mkcert? Seems to be looking for a java tool to created a keystore.

[cretz]

@nickkaczmarek - No it is not, and I use the JVM frequently. I didn't even know that added the root in my Java keystore, heh. This appears to be a new thing @adamdecaf added in #38. There appear to be some things wrong such as in its java check it calls keytool even if hasKeytool is false. Also, it assumes it's a JDK and not a JRE by its cert path lookup.

It's going to happen on all Windows OS's, because it looks for bin/keytool instead of bin/keytool.exe (Windows support was just merged after that). So someone needs to Windows-ify it, change the checkJava to stop assuming the keytool is there, and change the cert path lookup to respect JREs instead of just JDKs.

[nickkaczmarek]

I saw that jre path also and thought it looked fishy. I ended up removing Java from my machine to get past it but fixing the project is probably a more sustainable route.

[adamdecaf]

Yep. I missed that before, sorry. I don't have a windows machine to test with, but could y'all try this patch?

#54

[nickkaczmarek]

@adamdecaf that might work, but I think the jre path might be problematic as well. I can take a look tomorrow if no one else does.

[adamdecaf]

Ah okay. If the install path for java (or the extracted file structure) is different for windows we can probably work around the differences.

[cretz]

If the install path for java (or the extracted file structure) is different for windows

It's not. The difference is JRE vs JDK.

[adamdecaf]

That makes sense. Do you know if the structure is the same across OS's? We could just check for both paths.

[cretz]

I believe so, yes

[Suleman-Elahi]

same here

[zanjs]

ERROR: failed to execute "keytool -list": exec: "": executable file not found in %PATH%

me too

[nickkaczmarek]

So @cretz, it looks like when you implemented the windows functionality, the java change was unnecessary for a CA to be created in windows. Is it worth allowing an opt out of using java? I'm not sure how the keystore works, but it seems to be unnecessary. @adamdecaf or @FiloSottile, what do you think about a java opt out? I really don't know how this works, but I'd prefer to have mkcert not use java even if it's installed on my machine.

[adamdecaf]

Why would we opt out of java? It's been useful at a previous employer to add the company CA into the truststore.

[nickkaczmarek]

I was referring to having the option to choose to not use it when generating a CA or certificate. My knowledge is really lacking around what mkcert really does so forgive me if I'm super off base and my specific use case is to generate certificates for local development. I'm simply saying that this worked without using Java when @cretz added windows support so in theory it should work without using Java and therefore possible to pass an option to not use Java when installing a CA or creating certificates.

Edit:
So for instance, allow a user to pass an option to use the native truststore rather than the java one, even if the JAVA_HOME environment variable is set. I'm looking into how this can be done because I have to have java installed on my work machine, but I'd rather use the native truststore to handle this action.

[FiloSottile]

To be clear, when JAVA_HOME is set, both the Java and the system trust stores have the certificate installed. Would you still want to selectively disable that, even if this issue was fixed? If so, please open a separate issue for that feature request.

[nickkaczmarek]

In that case, no. I got around this pre @adamdecaf suggested fix by removing JAVA_HOME and some other path specific stuff so this could give me an opportunity to see what a fresh install of java installs and sets so I could contribute to what @adamdecaf is working on in #54. I'm not sure having the option to selectively disable the java truststore step is necessary if it works because my impression is these truststore files are OS specific and the only reason to have the opt-out capability would be for this particular use case.

[nickkaczmarek]

In any case, I have this working on my mac at home and windows pc at work and I'm so glad there is such a simple tool to do this. I've seen there are others, but this piques my interest especially since it's written in go.

[nickkaczmarek]

@FiloSottile @adamdecaf I don't know if this is the correct way of doing it, but as a stop gap for the people experiencing this issue until @adamdecaf has #54 finished and accepted, the temporary solution seems to be delete or rename JAVA_HOME and run mkcert -install and mkcert hostname again.

[FiloSottile]

Thanks everyone, let me know if v1.1.1 fixes this.

[wikijm]

For Windows installation, you can use those commands:

REM Define %JAVA_HOME% variable
    for /d %%i in ("\Program Files\Java\jdk*") do set JAVA_HOME=%%i

REM Add %JAVA_HOME% VARIABLE to %PATH% variable
    setx PATH "%JAVA_HOME%\bin";"%PATH%" -m

[OwenMelbz]

I had the same issue today on Mojave.

I ended up manually running keytool to kick it into action by doing keytool -genkeypair which fixed the keytool error: java.lang.Exception: Keystore file does not exist error.

However then still had the odd JAVA_HOME issue - I used a pretty dodgy workaround and added an bash alias of alias mkcert="unset JAVA_HOME && mkcert"

So just for that terminal session it would unset it - and it seems to then work!

[noway]

unset JAVA_HOME did the trick for me

[pedrovgs]

I just deleted JAVA_HOME env var and it just worked like a charm. Thanks!

[Herz3h]

ty @pedrovgs