mirror of
https://github.com/FiloSottile/mkcert.git
synced 2026-04-25 05:26:03 +03:00
[GH-ISSUE #53] Executable not found in path #29
Labels
No labels
TLS stack issue
Windows
bug
duplicate
duplicate
enhancement
help wanted
help wanted
pull-request
question
question
root store
waiting for info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mkcert#29
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @aprasadh on GitHub (Aug 13, 2018).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/53
I tried running
mkcertversion 1.1.0 in windows. I got the following error.@ajsb85 commented on GitHub (Aug 13, 2018):
@daniellockard commented on GitHub (Aug 13, 2018):
That means you don't have java's
keytoolinstalled. Might want to install it.@aprasadh commented on GitHub (Aug 13, 2018):
I ran
keytool -listand I got thiskeytool error: java.lang.Exception: Keystore file does not exist: C:\Users\XXXXX\.keystore@nickkaczmarek commented on GitHub (Aug 13, 2018):
I'm having the same issue and getting the same response as @aprasadh from
"%JAVA_HOME%\bin\keytool.exe" -listas well askeytool -list. This isn't something I recall having to do for mkcert on macos or ubuntu.@nickkaczmarek commented on GitHub (Aug 13, 2018):
@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 commented on GitHub (Aug 13, 2018):
@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/keytoolinstead ofbin/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 commented on GitHub (Aug 13, 2018):
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 commented on GitHub (Aug 13, 2018):
Yep. I missed that before, sorry. I don't have a windows machine to test with, but could y'all try this patch?
https://github.com/FiloSottile/mkcert/pull/54
@nickkaczmarek commented on GitHub (Aug 13, 2018):
@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 commented on GitHub (Aug 13, 2018):
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 commented on GitHub (Aug 13, 2018):
It's not. The difference is JRE vs JDK.
@adamdecaf commented on GitHub (Aug 13, 2018):
That makes sense. Do you know if the structure is the same across OS's? We could just check for both paths.
@cretz commented on GitHub (Aug 13, 2018):
I believe so, yes
@Suleman-Elahi commented on GitHub (Aug 14, 2018):
same here
@zanjs commented on GitHub (Aug 14, 2018):
ERROR: failed to execute "keytool -list": exec: "": executable file not found in %PATH%me too
@nickkaczmarek commented on GitHub (Aug 14, 2018):
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 commented on GitHub (Aug 14, 2018):
Why would we opt out of java? It's been useful at a previous employer to add the company CA into the truststore.
@nickkaczmarek commented on GitHub (Aug 14, 2018):
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_HOMEenvironment 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 commented on GitHub (Aug 15, 2018):
To be clear, when
JAVA_HOMEis 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 commented on GitHub (Aug 15, 2018):
In that case, no. I got around this pre @adamdecaf suggested fix by removing
JAVA_HOMEand 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 commented on GitHub (Aug 15, 2018):
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 commented on GitHub (Aug 15, 2018):
@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_HOMEand runmkcert -installandmkcert hostnameagain.@FiloSottile commented on GitHub (Aug 19, 2018):
Thanks everyone, let me know if v1.1.1 fixes this.
@wikijm commented on GitHub (Aug 23, 2018):
For Windows installation, you can use those commands:
@OwenMelbz commented on GitHub (Oct 27, 2018):
I had the same issue today on Mojave.
I ended up manually running keytool to kick it into action by doing
keytool -genkeypairwhich fixed thekeytool error: java.lang.Exception: Keystore file does not existerror.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 commented on GitHub (Apr 7, 2022):
unset JAVA_HOMEdid the trick for me@pedrovgs commented on GitHub (Jul 6, 2022):
I just deleted JAVA_HOME env var and it just worked like a charm. Thanks!
@Herz3h commented on GitHub (Nov 17, 2023):
ty @pedrovgs
go getto build from source in the README #361