eKristensen
commented
7 months ago I have the same problem on Fedora 39.
Closed eKristensen closed 7 months ago
eKristensen
commented
7 months ago I have the same problem on Fedora 39.
valeriansaliou
commented
7 months ago Did you install the ca-certificates package on your distribution? (I don't have the specific name for your distribution, although the name might be similar). Vigil uses openssl-probe to find the local trusted CAs, which it might not find here.
eKristensen
commented
7 months ago [root@pop-rocky-4gb-fsn1-1 ~]# dnf install ca-certificates
Last metadata expiration check: 0:03:42 ago on Sun 04 Feb 2024 12:45:31 AM UTC.
Package ca-certificates-2023.2.60_v7.0.306-90.1.el9_2.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!There are no package called openssl-probe that I can install
Did you see my bug report? The OS has CA certificates. It can check that the Google certificate is OK.
EDIT: Removed last part which was confusing/misleading - sry about that.
eKristensen
commented
7 months ago Maybe this is related: https://github.com/alexcrichton/openssl-probe/issues/24 ... ?
How to set CA path if openssl-probe does not work?
valeriansaliou
commented
7 months ago It is not possible to configure it. Could you try on a Debian system and see how it behaves? Or maybe just symlink the bundle path to another one it’d accept.
eKristensen
commented
7 months ago There are no issues when using Debian, however Debian is not always an option which is the case here.
Which path should i symlink? Where does it look for for the CA trust chain?
valeriansaliou
commented
7 months ago I have no knowledge of your distribution, but in Debian it's all stored in /etc/ssl/certs
eKristensen
commented
7 months ago I think you misunderstood me.
I do know where the CA certificates are in Rocky Linux/Fedora/Red Hat are, I am not asking for your help to find them in "my distro". What I do NOT know is where vigil is looking for them.
I have the certificates and I have vigil, what can I do to make vigil know where to look for those certificates?
You suggested a symbolic link. As I understood it I could make a symbolic link from wherever vigil is looking to the path in "my distro".
Do I have to use strace or something to find out where it looks for the files? vigil is doing a lot so I imagine a trace would be very noisy
valeriansaliou
commented
7 months ago I don't know either. This is done by openssl-probe, w/ no extra configuration on my end. You should look what it does here: https://github.com/alexcrichton/openssl-probe
It does look at: https://github.com/alexcrichton/openssl-probe/blob/master/src/lib.rs#L24
eKristensen
commented
7 months ago I don't know either. This is done by
openssl-probe, w/ no extra configuration on my end. You should look what it does here: https://github.com/alexcrichton/openssl-probeIt does look at: https://github.com/alexcrichton/openssl-probe/blob/master/src/lib.rs#L24
Hmm. The correct path with the certificate is included in that list. Why does it not work then? I guess I'll have to investigate here...
eKristensen
commented
7 months ago Minor update: I am fairly certain that openssl-probe does what it is supposed to do, but the environment variables set by openssl-probe are apparently not used.
openssl-probe sets two environment variables SSL_CERT_FILE and SSL_CERT_DIR. I have confirmed that they are set correctly. Next is to figure out why.
eKristensen
commented
7 months ago Update: I found https://docs.rs/reqwest/0.11.24/reqwest/#optional-features
If I change from native-tls-vendored to rustls-tls-webpki-roots in Cargo.toml settings for reqwest it works just fine.
Still investigating...
eKristensen
commented
7 months ago The issue is the vendored part of the native-tls-vendored. Without vendored there is no need for openssl-probe [1]
If I remove vendored from Cargo.toml like this:
-native-tls = { version = "0.2", features = ["vendored"] }
+native-tls = { version = "0.2" }
-openssl-probe = "0.1"
-reqwest = { version = "0.11", features = ["native-tls-vendored", "gzip", "blocking", "json"], default-features = false }
+reqwest = { version = "0.11", features = ["native-tls", "gzip", "blocking", "json"], default-features = false }@valeriansaliou Why do you use vendored? As far as I can tell using vendored also locks the OpenSSL version so it does not get any patches the OS might get.
valeriansaliou
commented
7 months ago I'm using vendored as I need vigil to build with MUSL instead of glibc, so that it can run on all Linux platforms out of the box, reason eg.: https://github.com/sfackler/rust-openssl/issues/603#issuecomment-822619837
Also, I cannot depend on the system-installed OpenSSL for the same reason.
I'd therefore recommend that in your case, you produce a build of Vigil that's not using the vendored flag for your own use.
Thanks for investigating this!
eKristensen
commented
7 months ago I think I'll go with a slightly customized build for my needs then.
I hope I can get vendored to work, but I need something new to break the ice in my investigation. I got stuck on the vendored track... All I can find is that they say to use openssl-probe and then it is supposed to just work.
I found an issue where they had issues when they did not use cargo to run their program because cargo apparently uses openssl-probe internally - you could say it worked "too well" here, but I have yet to see someone else have the same issue as I have here...
Compiling with MUSL was something I had not considered, but also not relevant for the way I want to use vigil (at least not right now).
I think this is resolved enough to close this issue. If I figure out I need some way to pass options along to the vendored OpenSSL in vigil I'll post a comment in here.
eKristensen
commented
7 months ago @valeriansaliou I noticed that vigil-local uses http_req instead of reqwest https://github.com/valeriansaliou/vigil-local/blob/d4a6715f7b86b611f9d402bc689fe2a4ebe7c45c/Cargo.toml#L30 and there is no vendered TLS, instead you use rust-tls. I wonder why? Maybe you want to update/change vigil-local at some point?
valeriansaliou
commented
7 months ago http_req has a much smaller footprint, which is desirable as I wanted vigil-local bytesize to be as small as possible. vigil uses reqwest for a lot more things, eg. notifiers to hit HTTP APIs, so it's more appropriate to use this one here.
eKristensen
commented
7 months ago Ok, fair point.
The reason vigil uses native-tls-vendored instead of rust-tls/rustls-tls-webpki-roots is?
I'm just wondering why your vendored argument does not apply to vigil-local... Why use different ways to check certificates?
Hi,
This issue is in part related to #104
Vigil is not able to validate certificate for valid websites. The issue must be that it is not looking for the CA trust chain in the right place. I have not found a way to configure where Vigil is looking for the CA store, and that should not really be needed anyway.
OS is Rocky Linux 9 on a Hetzner VM
Vigil is installed with cargo and running via systemd.
My samle config is:
This is my debug log:
The error message
unable to get local issuer certificateproperly originate from openssl, but when I run google.com manually the OS is accepting the certificate.I get the same certificate error on more than one Rocky Linux installation. I've never had any issues with certificate validation when running vigil on Debian.
Thanks in advance!
Best regards, Emil Kristensen