Root cert not installed in local store with `localias start` #30

twalling · 2024-04-23T15:01:37Z

Happy to provide more context here but we found that unless we ran localias run, we wouldn't get the root cert installed in the local store. Running it as a daemon did prompt for sudo but for some reason it wasn't the same as running it in the foreground. I wanted to report it in case other people ran into it, or if the documentation should be updated or if it's something that can actually be worked around.

The text was updated successfully, but these errors were encountered:

peterldowns · 2024-04-23T18:40:29Z

Interesting, thanks for reporting the issue, and sorry for the trouble. It's quite likely there is an issue with localias, so I'd like to be able to fix it. Could you please help me by providing a little more information?

OS / version
localias version
How you installed localias (brew, go, nix, binary download, etc.)
Output from localias debug cert
if you can reproduce this issue again, the exact steps to take so I can try to reproduce it myself, and any logs from the steps (output from localias start, localias run, file contents, etc.)

Again, thanks for taking the time to report the problem, all these additional questions will just help me fix it faster.

twalling · 2024-04-23T21:43:17Z

No problem. I didn't know where to start as far as what you wanted.

Mac Sonoma 14.4.1
2.0.3+commit.c3c6d97
installed via brew
/Users/twalling/Library/Application Support/localias/caddy/pki/authorities/local/root.crt

I'm having a hard time reproducing. I'd have to figure out how to remove the root cert from the local store I think.

twalling · 2024-04-23T21:47:14Z

If it helps. There was a difference for us when running start vs run in how the Mac asked for elevated permissions. When running start it simply asks for sudo via the terminal. When running run, I got a Mac popup asking me to input my password to give permission.

peterldowns · 2024-04-23T22:16:25Z

Interesting, thanks for the more information. I'm taking a cursory look now but I will keep investigating as I have time over the rest of the week. Thank you again for your helpful replies. I have a few more followups:

we wouldn't get the root cert installed in the local store.

How did you know that the root cert was not installed in "the local store"? I'd like to know what behavior you expected, and what behavior you observed. If the behavior involves a browser, please mention which one.

I'm having a hard time reproducing. I'd have to figure out how to remove the root cert from the local store I think.

I'm not sure exactly what you mean by "the local store", but you can remove entries from the system keychain by opening "Keychain Access.app" (search for "keychain access" with spotlight, or it should be in /Applications/Utilities/Keychain Access.app).

If you're using Firefox, you can check the Certificates manager by opening Preferences and then searching "cert" and clicking the "View Certificates" button. From there, find any localias-related certs in the Authorities tab and in the Your Certificates tabs and delete them.

If it helps. There was a difference for us when running start vs run in how the Mac asked for elevated permissions. When running start it simply asks for sudo via the terminal. When running run, I got a Mac popup asking me to input my password to give permission.

I'm on an older version of macOS but I cannot reproduce the behavior you've described about a difference between start asking for sudo in the terminal and run asking for sudo in a popup. You can check the code (cmd/localias/root/start.go, cmd/localias/root/run.go) to see that both commands begin by applying the config, which is what triggers the first request for sudo permissions (to edit /etc/hosts). So I'm not sure if this is related or not.

peterldowns · 2024-04-23T22:51:57Z

Following up — after totally removing all existing certificates on my system, I think I can explain the behavior you observed. I believe that you may have been accidentally closing the security popups prompting you to allow sudo/admin behavior when you ran localias start. Below, find all the steps of successfully accepting each sudo/security dialog prompt.

Observing the reported behavior

I think you could have observed the behavior by taking the following actions (referencing the successful flow below):

Closing the first sudo prompt in step 3 will result in seeing a password input in your terminal.
Closing the second sudo prompt will result in the daemon starting successfully, /etc/hosts being updated, but the localias certificate will not be installed in the system certificate store.
Running localias stop and localias run will re-prompt you to authorize adding the certificate to the system certificate store. Doing so successfully makes it seem like localias run installed the certificate but localias start didn't.

Successful steps / debugging process

1) Check that there are no aliases, and nothing in the system trust store, and nothing in /etc/hosts

$ cat /etc/hosts
# Default entries
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

# Custom entries

$ localias list
# ... empty result

$ localias add peterdowns.local 8080
[added] peterdowns.local -> 8080

$ localias list
peterdowns.local -> 8080

2) Run `localias start`

3) Pause at the first sudo popup

At the first sudo popup, allow the action by either using your thumbprint or "use password" in the system dialog to allow the action. This will let localias update /etc/hosts. If you hit "cancel", this will show a password entry field in the terminal, and you can enter your password there.

4) Pause at the second sudo popup

At the second sudo popup, open a separate terminal and check that /etc/hosts has been updated as expected.

$ cat /etc/hosts
# Default entries
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

# Custom entries
127.0.0.1	peterdowns.local	#{"controller":"localias"}

Search again for "localias" in Keychain Access, and confirm there is no entry.

Finally, allow this action with either your thumbprint or "use password" in the system dialog. This request is for the first part of the certificate installation process — adding the localias certificate to the system certificate store, but in an untrusted state.

5) Pause at the third sudo popup (first "security" popup)

At the third sudo popup, which is the first one labeled "security" and contains the description "You are making changes to the System Certificate Trust Settings", pause before accepting.

Search again for "localias" in Keychain Access, and confirm there is an entry, and it is untrusted.

Allow the action with either your thumbprint or "use password" in the system dialog. This will begin the process of trusting the localias certificate in the root store.

6) Pause at the fourth sudo popup (second "security" popup)

At the fourth sudo popup, which is the second labeled "security", pause before accepting. This request is to confirm

Search again for "localias" in Keychain Access, and confirm there is an entry, and it is untrusted.

Allow the action with either your thumbprint or "use password" in the system dialog. This will confirm and complete the process of trusting the localias certificate in the root store.

7) Check that the localias certificate is installed and trusted

Search again for "localias" in Keychain Access, and confirm there is an entry, and it is trusted (finally!)

twalling · 2024-04-23T23:19:38Z

This is very detailed thanks.

I do not get this behavior though, nor did the other 2 people on the team. When we run start, we only get prompted for a password on the command line. The only time I can get a sudo popup is when I use run 🤷 . Your steps break down for me at #3.

How did you know that the root cert was not installed in "the local store"? I'd like to know what behavior you expected, and what behavior you observed. If the behavior involves a browser, please mention which one.

The cert wasn't trusted when we'd use our locally running server in chrome or safari. Based on the README, I expected the root cert to be installed and trusted in chrome.

I applaud how responsive you've been and if you really want to try to get to the bottom of my particular environment (and my teammates') I'd be happy to do a screenshare sometime with you so we can try to debug it. Just let me know :)

(edit: I'll also add that I'm happy with how I at least got it working. At a minimum maybe this helps you regarding any notes or FAQ you might want to add to the README.)

peterldowns · 2024-04-24T03:42:53Z

OK, I appreciate the help and I'm sorry that I can't reproduce the issue. I won't have time to upgrade my computer for a while, so until then I don't think there's much I can do. If you can write back in with a reliable way to reproduce the issue, and clearer details on what exactly you and your team are observing (are you all on the same OS version? are there any similarities or differences in your environments? etc.) and which expectations are violated at which step, I'd be happy to pick this back up. I'll also happily accept a PR if you can fix the issue on your own by modifying the source!

Again, thank you for your patience and I'm sorry I can't fix it. I'm glad that localias run was able to resolve the problem for you and that you're able to use the software. Hopefully anyone running into this problem will find this thread and let me know.

🫡 Sincerely,
Peter

ericf89 · 2024-04-30T19:03:04Z

If it helps. There was a difference for us when running start vs run in how the Mac asked for elevated permissions. When running start it simply asks for sudo via the terminal. When running run, I got a Mac popup asking me to input my password to give permission.

I don't have anything too useful to add except that I also saw this behavior. I initially chalked it up to my user error though until I saw this issue. 😅

No problem. I didn't know where to start as far as what you wanted.

Mac Sonoma 14.4.1

2.0.3+commit.c3c6d97

installed via brew

/Users/twalling/Library/Application Support/localias/caddy/pki/authorities/local/root.crt

I'm having a hard time reproducing. I'd have to figure out how to remove the root cert from the local store I think.

I'm also on sonoma, so maybe it's something related to that. 🤔
I'm going propose adopting localias to my team in the next couple weeks so I can update if we see this behavior as well. Maybe grab a screencap of a fresh run through the install process.

peterldowns · 2024-05-06T04:08:29Z

OK, I've finally had time to upgrade my OS to Sonoma (14.4.1) and I have been able to reproduce the problem! I'm going to fix this by implementing daemonization in a slightly different way — instead of starting the Caddy server in the background/daemonized process, I'm going to start it and only then fork the daemon process. In some local testing, this seems to fix the problem. PR to come shortly, release shortly after that.

Thank you all for your patience and your help.

peterldowns · 2024-05-12T00:52:18Z

I'm very sure that the linked pr ^ will fix the issue (because I was able to repro), and I plan on merging and releasing a new version within the next week or so. If you'd like to sneak onto the next version before release, feel free to check out the PR and build a binary yourself! That branch also includes some nice quality of life changes, like localias start restarting your daemon if one is already running.

…#31) ## Bugfix Fix #30 by changing how daemonization works. - Previously: `start`/`reload` would apply the latest config in the foreground process, then fork(), then start Caddy. - Now: `start`/`reload` apply the latest config, starts Caddy in the foreground process, then fork()s. - By starting Caddy in the foreground process, any activities requiring sudo/root will happen while the program is still interactive. - This fixes the problem (adding the root cert to the system store requires sudo/root privileges, but because Caddy was running in a background process, it couldn't request that permission.) - The foreground process exits cleanly and the background process starts Caddy again, this time without any need for sudo/root privileges because any of the work it needed to do was already done in the foreground process. ## Friendlier CLI This change encouraged me to make the following improvements to the CLI commands: - `stop` just kills the daemon, if it's running. If the daemon wasn't running, `stop` will now exit cleanly. Previously, it would throw an error, but that's user-hostile because the goal of running `stop` is to ensure no running daemon — if that goal is accomplished by stopping a running daemon, or confirming no daemon was running, doesn't really matter. - `start` will start a new daemon. If one was already running, it will be killed and replaced by a new one. The user's goal is to ensure a daemon is running, with the latest config, and this is achieved regardless of whether or not there was an existing daemon. - `reload` becomes an alias for `start`, because they have the exact same behavior — ensure that a daemon is running with the latest configuiration. ## Get rid of `caddymodules` A while ago, localias was built using `gomod2nix`, and there was an incompatibility between that helper and the opentelemetry modules included in Caddy. To work around this, I created a `caddymodules` package that imported all of the Caddy modules _except_ opentelemetry, which was fine because this project doesn't use the opentelemetry modules in any way. Because localias no longer uses `gomod2nix`, this PR gets rid of the `caddymodules` hack entirely. This then allowed me to upgrade the version of Caddy that is being installed, and it will make it easier to stay up to date as Caddy receives further improvements. ## SSL renewal server With an upgraded Caddy came a problem — for SSL issuance, Caddy now requires you to implement an "automation policy" server that confirms that it can issue a new certificate for a given domain. This is primarily aimed at issuing certificates for real life domains accessible to the public, not for internal development aliases, but the restriction still stands. To do this, I used Caddy itself to respond to these requests. For more information, read: - https://caddyserver.com/docs/automatic-https#on-demand-tls - https://caddy.community/t/serving-tens-of-thousands-of-domains-over-https-with-caddy/11179 - caddyserver/caddy#6055 In the future, I could implement this by writing a custom policy module instead of using the HTTP ask, but this works for now. ## Dependencies cleanup - General updates of all imported golang packages. - Update the `flake.nix` and `flake.lock` files, switch to `buildGoModule` instead of `buildGo120Module` to make it easier to use this flake with an override `nixpkgs` upstream.

peterldowns · 2024-05-12T18:15:26Z

@twalling @ericf89 should be fixed now — if you installed via brew, you can brew upgrade localias to receive version 2.1.0+commit.46b0a47. Please let me know if for some reason this doesn't fix the issue, in which case I will investigate further.

peterldowns self-assigned this Apr 24, 2024

peterldowns added bug something isn't working needs-more-info needs more information from the reporter cli related to the CLI interface labels Apr 24, 2024

peterldowns mentioned this issue May 6, 2024

fix: install root certs correctly by changing how daemonization works #31

Merged

peterldowns removed the needs-more-info needs more information from the reporter label May 6, 2024

peterldowns closed this as completed in #31 May 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Root cert not installed in local store with `localias start` #30

Root cert not installed in local store with `localias start` #30

twalling commented Apr 23, 2024

peterldowns commented Apr 23, 2024

twalling commented Apr 23, 2024

twalling commented Apr 23, 2024

peterldowns commented Apr 23, 2024

peterldowns commented Apr 23, 2024

twalling commented Apr 23, 2024 •

edited

peterldowns commented Apr 24, 2024

ericf89 commented Apr 30, 2024

peterldowns commented May 6, 2024

peterldowns commented May 12, 2024 •

edited

peterldowns commented May 12, 2024

Root cert not installed in local store with localias start #30

Root cert not installed in local store with localias start #30

Comments

twalling commented Apr 23, 2024

peterldowns commented Apr 23, 2024

twalling commented Apr 23, 2024

twalling commented Apr 23, 2024

peterldowns commented Apr 23, 2024

peterldowns commented Apr 23, 2024

Observing the reported behavior

Successful steps / debugging process

1) Check that there are no aliases, and nothing in the system trust store, and nothing in /etc/hosts

2) Run localias start

3) Pause at the first sudo popup

4) Pause at the second sudo popup

5) Pause at the third sudo popup (first "security" popup)

6) Pause at the fourth sudo popup (second "security" popup)

7) Check that the localias certificate is installed and trusted

twalling commented Apr 23, 2024 • edited

peterldowns commented Apr 24, 2024

ericf89 commented Apr 30, 2024

peterldowns commented May 6, 2024

peterldowns commented May 12, 2024 • edited

peterldowns commented May 12, 2024

Root cert not installed in local store with `localias start` #30

Root cert not installed in local store with `localias start` #30

2) Run `localias start`

twalling commented Apr 23, 2024 •

edited

peterldowns commented May 12, 2024 •

edited