valet install asking for certificate permission for each existing site
#1226
Comments
datashaman
changed the title
datashaman
changed the title
|
Posting a diagnosis seems to leak a lot of my work information, is there a less public way for this information to be sent? It includes my local machine's userid (which leaks my real name) and the names and locations of all of my projects on the filesystem. |
datashaman
changed the title
valet install asking for certificate permission for each existing site
|
@datashaman best to filter that out manually. There isn't a secure way to share this right now. Seems to be related to #1224 probably? |
|
You can try the workaround in this comment which disables the pop-ups whenever I was looking into this very issue myself yesterday as well, but it seems that you have to trust on a per-certificate basis (you can't use The workaround: Might be worth adding something akin to |
|
These password prompts are pretty annoying when you have lots of secured sites. One of my colleagues has 15+ secured sites and he's using an older MacBook that doesn't have a Touch ID. Running valet install is a nightmare in that situation. I'm wondering if it would be a good idea to submit a PR with a flag like |
I think that sounds like an improvement over the potentially many prompts you'd have to wrestle through today. You could probably even do it without needing the flag? (I imagine most folks will not look up the possible flags for |
|
@nicoverbruggen, I experienced a flawless handsfree installation after running those commands, thanks. |
|
@nicoverbruggen @NasirNobin I think it's worth exploring to update the install command like that, however, I'm a bit cautious as to what would happen if the command fails in the middle of execution and the settings aren't reverted? |
|
My initial idea on handling exceptions was to wrap the whole process in a try/catch. So we can still revert in case of errors. But there could always be other cases, like if the user or any other application forcefully kills the process in the middle. I guess we can print some info and link to the doc about this in the output, so the user is aware of what's happening and can revert back manually if something like this happens. Also, we can add another logic, like Valet would only disable password prompts, if the user's machine has 2+ SSL sites. So users with 2 or fewer SSL sites won't be affected at all. |
|
Yeah the exception handling would be useful but indeed, there can always be manual termination or other things that can happen. I'm not sure about checking the amount of sites. I'd just make the behavior the default one regardless of amount of sites. But maybe @mattstauffer has a different opinion? |
But this also applies to Homebrew and such. You can break your installation easily if you keep manually terminating the terminal/proces while Homebrew is working, I wouldn't worry about that too much.
I agree with this. I'd also like to add: Whenever I build something like this, I generally write a file to disk (or persist some information somewhere) that indicates that a sensitive or important operation did not complete successfully. That way, if something failed, you can check for the file's existence the next time you use the program (whether app or CLI) and perhaps restore the original configuration before resuming whatever the user has asked to do. This already happens here: The particular .plist file (authorizationdb configuration) prior to modification is written to a file. You could theoretically restore it after securing the domains, and if that failed somehow the |
|
I think @nicoverbruggen's suggestion here is likely our best option. @driesvints and I have been digging into this because he's the first person I've been able to reproduce this issue with, and so far the only idea we have is to go with Nico's suggestion:
Any thoughts/concerns? |
|
I've just spent the past 2 hours struggling with the same issue described by @driesvints in #1224 — I see that issue was closed, but it seems related to this one. I tried to upgrade Valet this evening and couldn't get past the "Installing nginx directory..." prompt either. I followed all the usual suggestions ( Still no luck! So I thought I'd have another go, and whilst reviewing the instructions from Weirdly, trying to delete the Valet certificate caused Keychain Access to stop responding. macOS started hanging too, until eventually allowing me to force-quit Keychain Access. By the time I was even trying this, all other Valet services had been uninstalled. I verified with Sounds like a macOS bug to me...? With that in mind, I was finally able to install Valet by NOT using Touch ID when prompted — just typing my password manually instead. 🤨 Like others in #1224, I'm on a 2021 M1 MacBook Pro running Monterey 12.3.1. |
|
@jackwh there's no macOS bug. Just tighter restrictions around keychain access in Monterey. |
|
@driesvints Sorry if I wasn't clear, this was about an observation related to #1224 (which has been closed), but I thought it might relate to this issue too. The OS chooses whether to show a password dialog or a TouchID prompt automatically, and only when using TouchID do future auth prompts stop appearing (and Keychain Access hangs). So the issue in #1224 must be a bug in macOS, surely? |
|
Hi all. Since there's no clear and good solution to this without fiddling with macOS security settings, we're going to close this one as a no-fix. For now, this is going to be the behavior until a better solution presents itself. I'll pin this tweet so people can find it when trying to find answers to this. Thanks all. |
|
According to an Apple dev, it looks like it would be possible to write a utility that could accomplish this without having to change that
Unfortunately, at this point, I have no idea how to build that tool, but I thought it was worth documenting here in case someone else has the skills/desire to work on that. (Found this thread because I usually have 15+ secure sites locally, and this makes running |
If I find the time I would't mind trying to build a small CLI app that you can give a list of certificates to trust... Been a while since I last wrote Obj-C though. I won't guarantee I can produce anything workable but I want to look into this for sure. |
|
So... I made a proof-of-concept test CLI app that attempts to add the (self-generated) Laravel Root CA certificate to the The method responsible for actually marking the cert as trusted ( It's likely that trusting multiple certs in one go is simply not possible, as looping over an array of items would simply result in the same outcome as before. Even Keychain.app sadly pops up multiple alerts when you want to add/remove in bulk. So this may not be fixable... However! Adding the root CA authority worked, and doing this was actually sufficient for Safari and Microsoft Edge to start serving my sites! This being the case, there may not be any need for a separate app if we can do a single auth prompt like this (trusting only the CA cert, since that implicitly makes the other certs trusted as well). So, only trusting the CA certificate works with Safari and Edge. What about Firefox? You need to manually import the certificate authority there, it doesn't use the system wide CA list. That has been the case for a while now. Sadly, Chrome also does not seem to want to play nice with this. After doing some searching, the reason for this may be a missing Testing `subjectAltName` theory (not sure if this is the actual cause)After installing and the extension appears to be missing on my system. Perhaps if the root CA is generated with The root cert is generated here and seems to be lacking this TL;DR: I think that trusting a correctly-generated single root CA cert is actually sufficient to have most browsers work with Valet out of the box (with Firefox as the only exception since it doesn't make use of keychain's certificates to check if a domain is trusted). To be clear, you obviously still need to generate individual certificates but they I believe they don't all need to be individually trusted with a password prompt. This means that the only time a user will see that auth pop-up is when the CA cert needs to be trusted (once every 24 months?). I am uncertain what one has to do to make the certificate authority valid for Chrome, however. Anyone else have experience with this? |
Description:
Running valet install after upgrade to version 3 results in a seemingly endless loop of asking for permission to alter the certificate store.
Steps To Reproduce:
Now it asks for permission to alter certificate trust. Over and over and over again.
Once I manage to Cancel then the process continues as follows (I must press Cancel for each one too):
I have 24 secure sites in valet. Can this permission not be asked for once? I don't know if it's endless, it might be only 24 times I have to do this. EDIT: It's 26 times. Yay.
I've just had to cancel the thing 26 times (2 extra for 2 non-secure sites). So it's doing it for each site.
Diagnosis
Details Diagnosis
</performnud,dad></rxcsum,txcsum,txstatus,sw_timestamp></up,loopback,running,multicast>
The text was updated successfully, but these errors were encountered: