mirror of
https://github.com/AdguardTeam/AdGuardHome.git
synced 2026-03-04 00:01:12 -05:00
Expand symlinks when loading certificate and key files content #2569
Labels
No labels
P1: Critical
P2: High
P3: Medium
P4: Low
UI
bug
cannot reproduce
compatibility
dependencies
docker
documentation
duplicate
enhancement
enhancement
external libs
feature request
good first issue
help wanted
infrastructure
invalid
localization
needs investigation
performance
potential-duplicate
question
recurrent
research
snap
waiting for data
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AdGuardHome#2569
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 @Aesir on GitHub (Mar 16, 2021).
Originally assigned to: @ainar-g on GitHub.
Issue Details
Expected Behavior
My certs are pem files from LetsEncrypt generated by Swag. Under Settings -> Encryption Settings -> Certificates I should be able to point my certificate path to the
fullchain.pemfile and the private key file path toprivkey.pem. If there are issues with the certificates themselves, the UI should just say so and not tell me that there's no such file or directory or the cert chain is invalid when the issue is with the key file.Actual Behavior
As far as I can tell, the only way to get the files to work at all is to set both fields to point to
priv-fullchain-bundle.pem. The UI will give various spurious missing file errors and invalid key errors until both fields are set to point to this combined cert/private key file.Screenshots
This is what I would expect to put into these fields. These files work perfectly when copied and pasted into the text fields but for some reason don't work when I just point to the files. Notice that the UI is giving a spurious "No such file or directory" error. It gives this for files it does not like regardless of whether or not they actually exist.
Here I have the cert pointing to the file that will eventually work while the private key is still pointing to the `privkey.pem` file. Notice that the UI tells me my cert chain is invalid, even though it is not, and it's also telling me that the privkey file now doesn't exist.
Same with the other way around only now it's the `fullchain.pem` file that it claims doesn't exist.
And here we have it set up in the only way I can find to make it happy. It's only by accepting both files that it stops throwing spurious errors and for some reason it wants the full chain and key pair for the files whereas it's perfectly happy to take them separately when pasting the keys in as text.
@ameshkov commented on GitHub (Mar 16, 2021):
Well, if it says that the file does not exist, it either really does not exist by that path, or there's a permission problem.
One more possibility: could it be that you're using symlinks?
@Aesir commented on GitHub (Mar 16, 2021):
It's using symlinks within the Swag container, but I'm not sure which direction they point. I also expose the certs to docker with a volume mapping, which I believe use symlinks. It would be very weird that it can see one file in the same folder as the other two and has no problem seeing the files themselves under certain file combinations (see the screenshots).
It's much more likely that it can see the files and it's just throwing the error every time the file fails to pass all of the validation passes.
@ameshkov commented on GitHub (Mar 16, 2021):
All three are the same - it tries to open the first file, can't find it and returns "no such file" error without even trying to open the second one.
It would've shown a different error then.
@Aesir commented on GitHub (Mar 16, 2021):
The first and 3rd are fullchain, the 2nd is privkey.
I didn't include screenshots of every combination I tried while trying to get a key file to work. When messing around with different keys files, it becomes very clear that it's giving the file not found error regardless no matter what if it doesn't like the key file. It isn't doing it because the file isn't there. There is a bug in the logic that displays the error, probably some sort of top-level handler that adds the message whenever there's an issue during file loading.
@ameshkov commented on GitHub (Mar 17, 2021):
The problem is that I cannot reproduce it.
It shows a human-readable error to me. For instance, when I try to point the cert to the key file, it shows "You have specified an empty certificate" error, and when I specify key file instead of crt, I am getting "No valid keys were found" which is also a proper error.
Let's try taking a look at the verbose log.
@Aesir commented on GitHub (Mar 17, 2021):
Not too helpful, I got one line for every letter typed.
2021/03/17 07:56:02 1#89 [debug] POST /control/tls/validate2021/03/17 07:56:03 1#91 [debug] POST /control/tls/validate2021/03/17 07:56:04 1#93 [debug] POST /control/tls/validate2021/03/17 07:56:04 1#95 [debug] POST /control/tls/validate2021/03/17 07:56:05 1#97 [debug] POST /control/tls/validate2021/03/17 07:56:08 1#99 [debug] POST /control/tls/validate2021/03/17 07:56:12 1#101 [debug] POST /control/tls/validate2021/03/17 07:56:15 1#103 [debug] POST /control/tls/validate2021/03/17 07:56:15 1#105 [debug] POST /control/tls/validate2021/03/17 07:56:47 1#107 [debug] POST /control/tls/validate2021/03/17 07:56:52 1#109 [debug] POST /control/tls/validate2021/03/17 07:56:52 1#111 [debug] POST /control/tls/validate2021/03/17 07:56:54 1#113 [debug] POST /control/tls/validateIt does seem to come down to a symlink issue though. Hopefully this will help get it figured out.
The check of the log file was just to make sure my command was working. As you can see,
testreturns false for both of the standard files, I'm guessing because they're symlinks, whilepriv-fullchain-bundle.pemis not and tests true. I figured I'd also through in my docker-compose file in case it was a permission issue or I could update my volume mappings to fix the issue. I could probably point to the../../archivedirectory instead but I believe that the specific paths there are supposed to change over time so at that point I might as well paste the keys in.@ameshkov commented on GitHub (Mar 17, 2021):
Yeah, symlink explains that.
@ainar-g commented on GitHub (Jun 3, 2021):
This will be done together with #2902 and #2554.
@eagle470 commented on GitHub (Mar 26, 2024):
I'm currently running into this issue and it's driving me nuts. Any chance this is going to be resolved anytime soon?
@winnie-sg commented on GitHub (May 3, 2024):
So am I. Have you managed to resolve it?
@ArmedSnail commented on GitHub (Mar 23, 2025):
just ran into this, is there any timeframe/workaround yet?
I could copy the files via cronjob but it feels like an unnecessary complicated solution.