Valid certificates not accepted on Rocky Linux 9

[eKristensen]

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

[root@pop-rocky-4gb-fsn1-1 vigil]# uname -a
Linux pop-rocky-4gb-fsn1-1 5.14.0-362.13.1.el9_3.aarch64 #1 SMP PREEMPT_DYNAMIC Wed Dec 13 18:13:24 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
[root@pop-rocky-4gb-fsn1-1 vigil]# vigil --version
vigil-server 1.26.3

Vigil is installed with cargo and running via systemd.

My samle config is:

[[probe.service.node]]
id = "google"
label = "Google"
mode = "poll"
replicas = ["https://www.google.com"]

This is my debug log:

Feb 03 17:33:31 pop-rocky-4gb-fsn1-1 vigil[53226]: (INFO) - starting 4 workers
Feb 03 17:33:31 pop-rocky-4gb-fsn1-1 vigil[53226]: (INFO) - Actix runtime found; starting in Actix runtime
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll will fire for http target: https://www.google.com/?1706981612 with method: Head and body: ''
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - starting new connection: https://www.google.com/
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - resolving host="www.google.com"
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connecting to [2a00:1450:4001:80f::2004]:443
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connected to [2a00:1450:4001:80f::2004]:443
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll result was not received for http target: https://www.google.com/?1706981612 (error: error sending request for url (https://www.google.com/?1706981612): error trying to connect: unexpected EOF (unable to get local issuer certificate))
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - will probe replica: HTTPS("https://www.google.com/") with retry count: 1
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll will fire for http target: https://www.google.com/?1706981612 with method: Head and body: ''
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - starting new connection: https://www.google.com/
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - resolving host="www.google.com"
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connecting to [2a00:1450:4001:80b::2004]:443
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connected to [2a00:1450:4001:80b::2004]:443
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll result was not received for http target: https://www.google.com/?1706981612 (error: error sending request for url (https://www.google.com/?1706981612): error trying to connect: unexpected EOF (unable to get local issuer certificate))
Feb 03 17:33:32 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - will probe replica: HTTPS("https://www.google.com/") with retry count: 2
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll will fire for http target: https://www.google.com/?1706981613 with method: Head and body: ''
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - starting new connection: https://www.google.com/
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - resolving host="www.google.com"
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connecting to [2a00:1450:4001:82b::2004]:443
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - connected to [2a00:1450:4001:82b::2004]:443
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - prober poll result was not received for http target: https://www.google.com/?1706981613 (error: error sending request for url (https://www.google.com/?1706981613): error trying to connect: unexpected EOF (unable to get local issuer certificate))
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (DEBUG) - replica probe result: servers:google:https://www.google.com => Dead
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (INFO) - replicas have been probed with 1/4 threads in 1.571513676s
Feb 03 17:33:33 pop-rocky-4gb-fsn1-1 vigil[53226]: (INFO) - ran poll probe operation

The error message unable to get local issuer certificate properly originate from openssl, but when I run google.com manually the OS is accepting the certificate.

[root@pop-rocky-4gb-fsn1-1 vigil]# openssl s_client -connect www.google.com:443 -servername www.google.com -showcerts < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = www.google.com
verify return:1
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan  9 06:31:40 2024 GMT; NotAfter: Apr  2 06:31:39 2024 GMT
-----BEGIN CERTIFICATE-----
MIIEiDCCA3CgAwIBAgIQE1E7QIU2gygKfzVGqgKHCzANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yNDAxMDkwNjMxNDBaFw0yNDA0MDIw
NjMxMzlaMBkxFzAVBgNVBAMTDnd3dy5nb29nbGUuY29tMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAEyOoC+ryGt4MxNnTASHFQ+hkCBG1YqB1KXN5B6LfbHh9eTMty
GIR3rR/OpgHFtctY273AbUAg50OWRENei9HJoKOCAmgwggJkMA4GA1UdDwEB/wQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBSLKm9oe4PUp47ofjmET1ycImlPGjAfBgNVHSMEGDAWgBSKdH+vhc3ulc09nNDi
RhTzcTUdJzBqBggrBgEFBQcBAQReMFwwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3Nw
LnBraS5nb29nL2d0czFjMzAxBggrBgEFBQcwAoYlaHR0cDovL3BraS5nb29nL3Jl
cG8vY2VydHMvZ3RzMWMzLmRlcjAZBgNVHREEEjAQgg53d3cuZ29vZ2xlLmNvbTAh
BgNVHSAEGjAYMAgGBmeBDAECATAMBgorBgEEAdZ5AgUDMDwGA1UdHwQ1MDMwMaAv
oC2GK2h0dHA6Ly9jcmxzLnBraS5nb29nL2d0czFjMy9RcUZ4Ymk5TTQ4Yy5jcmww
ggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdwDuzdBk1dsazsVct520zROiModGfLzs
3sNRSFlGcR+1mwAAAYztIlrpAAAEAwBIMEYCIQCyxEebhabh/YT84vZQSGJ3RITR
AfiVjd3qOHzYzQXwsQIhAOb/azWkRcP/CB6yYJxSMlmj+aGKLvSIrb3bVNHa9a5N
AHYASLDja9qmRzQP5WoC+p0w6xxSActW3SyB2bu/qznYhHMAAAGM7SJbCwAABAMA
RzBFAiB9cJLqGae/JdII/1MOFPmtay2jAFm4GinbF2Q7dNJt9AIhAPDLESn7OA2O
S20In37iHZZmTWVU8dqFL2bUlYZAK4bSMA0GCSqGSIb3DQEBCwUAA4IBAQAkR7TE
CmRHGsQC/9oFsBz4G0S46QTlkHi/Uzx9wkPhQioXA0O0chbqAv5Audh6skD54FM7
ELbY29B35VvyhapGwop5HSt12fshNCrkw17n4IRW4mk1Oh6M3qrrJdn35flYexuH
AX89FTLRfkejURwHL6c29yVezdiGF0hMe7p38r6PPoxskKFsqVDTeoaCZkir7rin
DVgRxCyH6fWBCU2Wdru6ky++mrjgevSEjFQejTMtYCAjo3EABxM8za2q5mfdC90J
thCVCy1Kkjfl1wlJM/oASG7/FskQ8utJVovgkLd/Z5Zs5QgFisSmCZfhGJs6r1X6
9E7zEmJJuLkqyiZk
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 13 00:00:42 2020 GMT; NotAfter: Sep 30 00:00:42 2027 GMT
-----BEGIN CERTIFICATE-----
MIIFljCCA36gAwIBAgINAgO8U1lrNMcY9QFQZjANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExMQzEU
MBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMjAwODEzMDAwMDQyWhcNMjcwOTMwMDAw
MDQyWjBGMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZp
Y2VzIExMQzETMBEGA1UEAxMKR1RTIENBIDFDMzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAPWI3+dijB43+DdCkH9sh9D7ZYIl/ejLa6T/belaI+KZ9hzp
kgOZE3wJCor6QtZeViSqejOEH9Hpabu5dOxXTGZok3c3VVP+ORBNtzS7XyV3NzsX
lOo85Z3VvMO0Q+sup0fvsEQRY9i0QYXdQTBIkxu/t/bgRQIh4JZCF8/ZK2VWNAcm
BA2o/X3KLu/qSHw3TT8An4Pf73WELnlXXPxXbhqW//yMmqaZviXZf5YsBvcRKgKA
gOtjGDxQSYflispfGStZloEAoPtR28p3CwvJlk/vcEnHXG0g/Zm0tOLKLnf9LdwL
tmsTDIwZKxeWmLnwi/agJ7u2441Rj72ux5uxiZ0CAwEAAaOCAYAwggF8MA4GA1Ud
DwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEgYDVR0T
AQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUinR/r4XN7pXNPZzQ4kYU83E1HScwHwYD
VR0jBBgwFoAU5K8rJnEaK0gnhS9SZizv8IkTcT4waAYIKwYBBQUHAQEEXDBaMCYG
CCsGAQUFBzABhhpodHRwOi8vb2NzcC5wa2kuZ29vZy9ndHNyMTAwBggrBgEFBQcw
AoYkaHR0cDovL3BraS5nb29nL3JlcG8vY2VydHMvZ3RzcjEuZGVyMDQGA1UdHwQt
MCswKaAnoCWGI2h0dHA6Ly9jcmwucGtpLmdvb2cvZ3RzcjEvZ3RzcjEuY3JsMFcG
A1UdIARQME4wOAYKKwYBBAHWeQIFAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3Br
aS5nb29nL3JlcG9zaXRvcnkvMAgGBmeBDAECATAIBgZngQwBAgIwDQYJKoZIhvcN
AQELBQADggIBAIl9rCBcDDy+mqhXlRu0rvqrpXJxtDaV/d9AEQNMwkYUuxQkq/BQ
cSLbrcRuf8/xam/IgxvYzolfh2yHuKkMo5uhYpSTld9brmYZCwKWnvy15xBpPnrL
RklfRuFBsdeYTWU0AIAaP0+fbH9JAIFTQaSSIYKCGvGjRFsqUBITTcFTNvNCCK9U
+o53UxtkOCcXCb1YyRt8OS1b887U7ZfbFAO/CVMkH8IMBHmYJvJh8VNS/UKMG2Yr
PxWhu//2m+OBmgEGcYk1KCTd4b3rGS3hSMs9WYNRtHTGnXzGsYZbr8w0xNPM1IER
lQCh9BIiAfq0g3GvjLeMcySsN1PCAJA/Ef5c7TaUEDu9Ka7ixzpiO2xj2YC/WXGs
Yye5TBeg2vZzFb8q3o/zpWwygTMD0IZRcZk0upONXbVRWPeyk+gB9lm+cZv9TSjO
z23HFtz30dZGm6fKa+l3D/2gthsjgx0QGtkJAITgRNOidSOzNIb2ILCkXhAd4FJG
AJ2xDx8hcFH1mt0G/FX0Kw4zd8NLQsLxdxP8c4CU6x+7Nz/OAipmsHMdMqUybDKw
juDEI/9bfU1lcKwrmz3O2+BtjjKAvpafkmO8l7tdufThcV4q5O8DIrGKZTqPwJNl
1IXNDw9bg1kWRxYtnCQ6yICmJhSFm/Y3m6xv+cXDBlHz4n/FsRC6UfTd
-----END CERTIFICATE-----
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
-----BEGIN CERTIFICATE-----
MIIFYjCCBEqgAwIBAgIQd70NbNs2+RrqIQ/E8FjTDTANBgkqhkiG9w0BAQsFADBX
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UE
CxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTIwMDYx
OTAwMDA0MloXDTI4MDEyODAwMDA0MlowRzELMAkGA1UEBhMCVVMxIjAgBgNVBAoT
GUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBMTEMxFDASBgNVBAMTC0dUUyBSb290IFIx
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAthECix7joXebO9y/lD63
ladAPKH9gvl9MgaCcfb2jH/76Nu8ai6Xl6OMS/kr9rH5zoQdsfnFl97vufKj6bwS
iV6nqlKr+CMny6SxnGPb15l+8Ape62im9MZaRw1NEDPjTrETo8gYbEvs/AmQ351k
KSUjB6G00j0uYODP0gmHu81I8E3CwnqIiru6z1kZ1q+PsAewnjHxgsHA3y6mbWwZ
DrXYfiYaRQM9sHmklCitD38m5agI/pboPGiUU+6DOogrFZYJsuB6jC511pzrp1Zk
j5ZPaK49l8KEj8C8QMALXL32h7M1bKwYUH+E4EzNktMg6TO8UpmvMrUpsyUqtEj5
cuHKZPfmghCN6J3Cioj6OGaK/GP5Afl4/Xtcd/p2h/rs37EOeZVXtL0m79YB0esW
CruOC7XFxYpVq9Os6pFLKcwZpDIlTirxZUTQAs6qzkm06p98g7BAe+dDq6dso499
iYH6TKX/1Y7DzkvgtdizjkXPdsDtQCv9Uw+wp9U7DbGKogPeMa3Md+pvez7W35Ei
Eua++tgy/BBjFFFy3l3WFpO9KWgz7zpm7AeKJt8T11dleCfeXkkUAKIAf5qoIbap
sZWwpbkNFhHax2xIPEDgfg1azVY80ZcFuctL7TlLnMQ/0lUTbiSw1nH69MG6zO0b
9f6BQdgAmD06yK56mDcYBZUCAwEAAaOCATgwggE0MA4GA1UdDwEB/wQEAwIBhjAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTkrysmcRorSCeFL1JmLO/wiRNxPjAf
BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzBgBggrBgEFBQcBAQRUMFIw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjEwKQYIKwYBBQUH
MAKGHWh0dHA6Ly9wa2kuZ29vZy9nc3IxL2dzcjEuY3J0MDIGA1UdHwQrMCkwJ6Al
oCOGIWh0dHA6Ly9jcmwucGtpLmdvb2cvZ3NyMS9nc3IxLmNybDA7BgNVHSAENDAy
MAgGBmeBDAECATAIBgZngQwBAgIwDQYLKwYBBAHWeQIFAwIwDQYLKwYBBAHWeQIF
AwMwDQYJKoZIhvcNAQELBQADggEBADSkHrEoo9C0dhemMXoh6dFSPsjbdBZBiLg9
NR3t5P+T4Vxfq7vqfM/b5A3Ri1fyJm9bvhdGaJQ3b2t6yMAYN/olUazsaL+yyEn9
WprKASOshIArAoyZl+tJaox118fessmXn1hIVw41oeQa1v1vg4Fv74zPl6/AhSrw
9U5pCZEt4Wi4wStz6dTZ/CLANx8LZh1J7QJVj2fhMtfTJr9w4z30Z209fOU0iOMy
+qduBmpvvYuR7hZL6Dupszfnw0Skfths18dG9ZKb59UhvmaSGZRVbNQpsg3BZlvi
d0lIKO2d1xozclOzgjXPYovJJIultzkMu34qQb9Sz/yilrbCgj8=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = www.google.com
issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4294 bytes and written 398 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

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

[eKristensen]

I have the same problem on Fedora 39.

[valeriansaliou]

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]

[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]

Maybe this is related: alexcrichton/openssl-probe#24 ... ?

How to set CA path if openssl-probe does not work?

[valeriansaliou]

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]

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]

I have no knowledge of your distribution, but in Debian it's all stored in /etc/ssl/certs

[eKristensen]

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]

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]

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

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]

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]

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]

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.

[1] https://docs.rs/openssl/0.10.63/openssl/#vendored

[valeriansaliou]

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.: sfackler/rust-openssl#603 (comment)

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]

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]

@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]

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]

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?