curl
curl copied to clipboard
jeroen
curl 6.2.0 can't find SSL certificate
Version 6.0.1 works:
library(curl)
#> Using libcurl 8.7.1 with LibreSSL/3.3.6
url <- "https://api.github.path.enterprise.com"
h <- new_handle()
res <- curl_fetch_memory(url, handle = h)
cat(rawToChar(res$content))
#> {"message":"API rate limit exceeded for ip. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/[email protected]/rest/overview/resources-in-the-rest-api#rate-limiting"}
Created on 2025-02-20 with reprex v2.1.1
But v6.2.0 returns an SSL certificate error:
library(curl)
#> Using libcurl 8.11.1 with OpenSSL/3.3.2
url <- "https://api.github.path.enterprise.com"
h <- new_handle()
res <- curl_fetch_memory(url, handle = h)
#> Error in curl_fetch_memory(url, handle = h): SSL peer certificate or SSH remote key was not OK [api.github.path.enterprise.com]: SSL certificate problem: unable to get local issuer certificate
Created on 2025-02-20 with reprex v2.1.1
It's difficult to reproduce this of course as I don't have access to your enterprise server. Does your server require a custom client certificate? Where is it stored on your client machine?
Sorry, I should have provided more information. Maybe the issue is related to OpenSSL’s different method of locating and validating CA certificates on macOS.
Exporting the custom certificate from keychain and then using the path to this file in CURL_CA_BUNDLE resolves the issue for me.
Feel free to close. I just thought it was worth reporting since I suspect many folks that rely on custom certificates are now getting these SSL errors in 6.2.0 when using downstream packages that rely on curl.
Well I would like things to keep working the way they did as well. Could you test the following to see if this works even without setting CURL_CA_BUNDLE ?
library(curl)
h <- new_handle(ssl_options = 16L)
res <- curl_fetch_memory("https://api.github.path.enterprise.com", handle = h)
If that works I just need to make this the default.
@gacolitti I'm still curious to understand why it worked before.
Could you test if you add the following line to your ~/.Renviron file, if this avoids the problem as well (without setting CURL_CA_BUNDLE)
CURL_SSL_BACKEND=Secure-Transport
See also this vignette (the vignette is about Windows but it works similar on macos).
Here is a minimal reproducable example on MacOS
library(remotes)
remotes::install_github("kkholst/targeted")
which fails with
Error: Failed to install 'targeted' from GitHub:
SSL peer certificate or SSH remote key was not OK [api.github.com]: SSL certificate problem: unable to get local issuer certificate
> sessionInfo()
R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin24.3.0
Running under: macOS Sequoia 15.3.1
Matrix products: default
BLAS: /Users/bkts/.asdf/installs/R/4.4.2/lib/R/lib/libRblas.dylib
LAPACK: /Users/bkts/.asdf/installs/R/4.4.2/lib/R/lib/libRlapack.dylib; LAPACK version 3.12.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
time zone: Europe/Copenhagen
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] remotes_2.5.0
loaded via a namespace (and not attached):
[1] compiler_4.4.2 tools_4.4.2 curl_6.2.1
I can confirm that setting
CURL_SSL_BACKEND=Secure-Transport
resolved the above error.
OK thanks so that means the key is in your keychain, but openssl is not finding it. Could you check if the verbose log gives us any hint that precedes the error? If you run the following on the latest version (the one that errors) I wonder if the log shows anything on if it tries to look at the keychain at all, and if it is considering your custom key at all:
library(curl)
h <- new_handle(ssl_options = 16L, verbose = TRUE)
res <- curl_fetch_memory("https://api.github.path.enterprise.com", handle = h)
Here you go:
library(curl)
#> Using libcurl 8.11.1 with OpenSSL/3.3.2
h <- new_handle(ssl_options = 16L, verbose = TRUE)
res <- curl_fetch_memory("https://api.github.path.enterprise.com", handle = h)
#> Error in curl_fetch_memory("https://api.github.path.enterprise.com", handle = h): SSL peer certificate or SSH remote key was not OK [api.github.path.enterprise.com]: SSL certificate problem: unable to get local issuer certificate
Created on 2025-02-24 with reprex v2.1.1
The verbose = TRUE should print a bunch of more output... Maybe that is not captured by reprex.
Yes, sorry. Here is the full output:
> library(curl)
Using libcurl 8.11.1 with OpenSSL/3.3.2
> h <- new_handle(ssl_options = 16L, verbose = TRUE)
> res <- curl_fetch_memory("https://api.github.path.enterprise.com", handle = h)
* Host api.github.path.enterprise.com:443 was resolved.
* IPv6: (none)
* IPv4: ip
* Trying ip:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* closing connection #0
Error in curl_fetch_memory("https://api.github.path.enterprise.com", handle = h) :
SSL peer certificate or SSH remote key was not OK [api.github.path.enterprise.com]: SSL certificate problem: unable to get local issuer certificate
I really don't know anything about how curl works under the hood, but I also have potentially the same issue where an API request that previously worked now fails with the same error:
httr2::request('https://health-products.canada.ca/api/drug/activeingredient/?lang=en&type=json') |>
httr2::req_perform()
Error in `httr2::req_perform()`:
! Failed to perform HTTP request.
Caused by error in `curl::curl_fetch_memory()`:
! SSL peer certificate or SSH remote key was not OK [health-products.canada.ca]: SSL certificate problem: unable to get local issuer certificate
Run `rlang::last_trace()` to see where the error occurred.
And I can make it work (force it to work?) like this...but I'm under the impression this is bad practice (though I don't know why):
httr2::request('https://health-products.canada.ca/api/drug/activeingredient/?lang=en&type=json') |>
httr2::req_options(ssl_verifypeer = 0) |>
httr2::req_perform()
<httr2_response>
GET
https://health-products.canada.ca/api/drug/activeingredient/?lang=en&type=json
Status: 200 OK
Content-Type: application/json
Body: In memory (15838989 bytes)
Any idea why the original code now fails with this error? Is it a bad idea to use ssl_verifypeer = 0 in a package that wraps an API?
Any idea why the original code now fails with this error?
OpenSSL cannot verify the server certificate for any number of reasons: the root certificate is missing from your specified location, that location is wrong, the server is malfunctioning, an attacker is impersonating the server, etc. Enable verbose as mentioned in an earlier post and check the CAfile / CApath.
Is it a bad idea to use
ssl_verifypeer = 0in a package that wraps an API?
Yes. Verification is needed to make sure you are not communicating with an impersonator. If verification fails there is a bigger problem that needs to be addressed and shouldn't be covered up by disabling verification.
Thanks for the response, @jay.
Here is the error with the verbose option. It doesn't mean much to me, so hopefully it means something to you or others!
* Hostname health-products.canada.ca was found in DNS cache
* Trying 205.193.192.22:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* closing connection #1
Error in `httr2::req_perform()`:
! Failed to perform HTTP request.
Caused by error in `curl::curl_fetch_memory()`:
! SSL peer certificate or SSH remote key was not OK [health-products.canada.ca]: SSL certificate problem: unable to get local issuer certificate
Run `rlang::last_trace()` to see where the error occurred.
@jay I do think there is a problem with libcurl, if the same ssl cert is accepted when CURL_SSL_BACKEND=Secure-Transport but it gets rejected with CURL_SSL_BACKEND=openssl using the official MacOS default ca-bundle, and even when we enable CURLSSLOPT_NATIVE_CA it still does not work.
Can reproduce this on the command line:
CURL_SSL_BACKEND=OpenSSL /opt/homebrew/opt/curl/bin/curl -v "https://health-products.canada.ca" --cacert /etc/ssl/cert.pem
Can reproduce this on the command line:
CURL_SSL_BACKEND=OpenSSL /opt/homebrew/opt/curl/bin/curl -v "https://health-products.canada.ca" --cacert /etc/ssl/cert.pem
Check for "SSL.com TLS RSA Root CA 2022" in your certificate bundle.
SSL.com TLS RSA Root CA 2022
============================
-----BEGIN CERTIFICATE-----
MIIFiTCCA3GgAwIBAgIQb77arXO9CEDii02+1PdbkTANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQG
EwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSUwIwYDVQQDDBxTU0wuY29tIFRMUyBSU0Eg
Um9vdCBDQSAyMDIyMB4XDTIyMDgyNTE2MzQyMloXDTQ2MDgxOTE2MzQyMVowTjELMAkGA1UEBhMC
VVMxGDAWBgNVBAoMD1NTTCBDb3Jwb3JhdGlvbjElMCMGA1UEAwwcU1NMLmNvbSBUTFMgUlNBIFJv
b3QgQ0EgMjAyMjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANCkCXJPQIgSYT41I57u
9nTPL3tYPc48DRAokC+X94xI2KDYJbFMsBFMF3NQ0CJKY7uB0ylu1bUJPiYYf7ISf5OYt6/wNr/y
7hienDtSxUcZXXTzZGbVXcdotL8bHAajvI9AI7YexoS9UcQbOcGV0insS657Lb85/bRi3pZ7Qcac
oOAGcvvwB5cJOYF0r/c0WRFXCsJbwST0MXMwgsadugL3PnxEX4MN8/HdIGkWCVDi1FW24IBydm5M
R7d1VVm0U3TZlMZBrViKMWYPHqIbKUBOL9975hYsLfy/7PO0+r4Y9ptJ1O4Fbtk085zx7AGL0SDG
D6C1vBdOSHtRwvzpXGk3R2azaPgVKPC506QVzFpPulJwoxJF3ca6TvvC0PeoUidtbnm1jPx7jMEW
TO6Af77wdr5BUxIzrlo4QqvXDz5BjXYHMtWrifZOZ9mxQnUjbvPNQrL8VfVThxc7wDNY8VLS+YCk
8OjwO4s4zKTGkH8PnP2L0aPP2oOnaclQNtVcBdIKQXTbYxE3waWglksejBYSd66UNHsef8JmAOSq
g+qKkK3ONkRN0VHpvB/zagX9wHQfJRlAUW7qglFA35u5CCoGAtUjHBPW6dvbxrB6y3snm/vg1UYk
7RBLY0ulBY+6uB0rpvqR4pJSvezrZ5dtmi2fgTIFZzL7SAg/2SW4BCUvAgMBAAGjYzBhMA8GA1Ud
EwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU+y437uOEeicuzRk1sTN8/9REQrkwHQYDVR0OBBYEFPsu
N+7jhHonLs0ZNbEzfP/UREK5MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOCAgEAjYlt
hEUY8U+zoO9opMAdrDC8Z2awms22qyIZZtM7QbUQnRC6cm4pJCAcAZli05bg4vsMQtfhWsSWTVTN
j8pDU/0quOr4ZcoBwq1gaAafORpR2eCNJvkLTqVTJXojpBzOCBvfR4iyrT7gJ4eLSYwfqUdYe5by
iB0YrrPRpgqU+tvT5TgKa3kSM/tKWTcWQA673vWJDPFs0/dRa1419dvAJuoSc06pkZCmF8NsLzjU
o3KUQyxi4U5cMj29TH0ZR6LDSeeWP4+a0zvkEdiLA9z2tmBVGKaBUfPhqBVq6+AL8BQx1rmMRTqo
ENjwuSfr98t67wVylrXEj5ZzxOhWc5y8aVFjvO9nHEMaX3cZHxj4HCUp+UmZKbaSPaKDN7Egkaib
MOlqbLQjk2UEqxHzDh1TJElTHaE/nUiSEeJ9DU/1172iWD54nR4fK/4huxoTtrEoZP2wAgDHbICi
vRZQIA9ygV/MlP+7mea6kMvq+cYMwq7FGc4zoWtcu358NFcXrfA/rs3qr5nsLFR+jM4uElZI7xc7
P0peYNLcdDa8pUNjyw9bowJWCZ4kLOGGgYz+qxcs+sjiMho6/4UIyYOf8kpIEFR3N+2ivEC+5BB0
9+Rbu7nzifmPQdjH5FCQNYA+HLhNkNPU98OwoX6EyneSMSy4kLGCenROmxMmtNVQZlR4rmA=
-----END CERTIFICATE-----
openssl s_client -CAfile ssl_com_root_ca_2022.pem -servername health-products.canada.ca -connect health-products.canada.ca:443
CONNECTED(00000134)
depth=2 C = US, O = SSL Corporation, CN = SSL.com TLS RSA Root CA 2022
verify return:1
depth=1 C = US, O = SSL Corporation, CN = Entrust OV TLS Issuing RSA CA 1
verify return:1
depth=0 C = CA, ST = Quebec, L = Gatineau, O = Shared Services Canada, CN = health-products.canada.ca
verify return:1
---
Certificate chain
0 s:C = CA, ST = Quebec, L = Gatineau, O = Shared Services Canada, CN = health-products.canada.ca
i:C = US, O = SSL Corporation, CN = Entrust OV TLS Issuing RSA CA 1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 16 15:06:37 2025 GMT; NotAfter: Feb 11 09:28:14 2026 GMT
1 s:C = US, O = SSL Corporation, CN = Entrust OV TLS Issuing RSA CA 1
i:C = US, O = SSL Corporation, CN = SSL.com TLS RSA Root CA 2022
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 22 17:53:38 2024 GMT; NotAfter: Aug 22 17:53:37 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHvzCCBaegAwIBAgIQZ8MiFQP7b3nFJeEGKja3aDANBgkqhkiG9w0BAQsFADBR
MQswCQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSgwJgYDVQQD
DB9FbnRydXN0IE9WIFRMUyBJc3N1aW5nIFJTQSBDQSAxMB4XDTI1MDExNjE1MDYz
N1oXDTI2MDIxMTA5MjgxNFowdjELMAkGA1UEBhMCQ0ExDzANBgNVBAgMBlF1ZWJl
YzERMA8GA1UEBwwIR2F0aW5lYXUxHzAdBgNVBAoMFlNoYXJlZCBTZXJ2aWNlcyBD
YW5hZGExIjAgBgNVBAMMGWhlYWx0aC1wcm9kdWN0cy5jYW5hZGEuY2EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI1bPn7LJKqVyI3Z8mSz2giwaRa5T6
fFxBntn7O1oJPY8P0k/LmgpX1OW0+lIyf9XJCZ79dcXAoobEqGRNh+yBCsfDEeoX
nvoMw3jbbJ1T4in8lo1amXHyvFGr1rpGRJU3TubP/wBE6m3buRWCiW1tgA9f7noW
qOvsaf1pyxIcrZ+u4hqsDmdcQkCISqpYs1g9v0PYfJf0f8gdHgUho1L1Kjedvkor
NMnuYsX/0+46tCB9jaHgHo4pJts3LOJ63NWK+s5qdSSX+MBRGMQ12uOo5ExGVvBE
6zv0LNKshbcXZW4dteH0pzdsPS7z2MweRrDfaBbz5xEUlRJLXjy/p7RtAgMBAAGj
ggNsMIIDaDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFGgNRco1wueaG/CzhN3V
2n8LicERMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NlcnQu
c3NsLmNvbS9FbnRydXN0LU9WVExTLUktUjEuY2VyMCAGCCsGAQUFBzABhhRodHRw
Oi8vb2NzcHMuc3NsLmNvbTCBlwYDVR0RBIGPMIGMghloZWFsdGgtcHJvZHVjdHMu
Y2FuYWRhLmNhgh13d3cuaGVhbHRoLXByb2R1Y3RzLmNhbmFkYS5jYYIcYWxpbWVu
dHMtbnV0cml0aW9uLmNhbmFkYS5jYYIYZm9vZC1udXRyaXRpb24uY2FuYWRhLmNh
ghhwcm9kdWl0cy1zYW50ZS5jYW5hZGEuY2EwIwYDVR0gBBwwGjAIBgZngQwBAgIw
DgYMKwYBBAGCqTABAwECMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATA7
BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3Jscy5zc2wuY29tL0VudHJ1c3QtT1ZU
TFMtSS1SMS5jcmwwHQYDVR0OBBYEFDhsLKoNM2LpeH17IENbIKNvmbq6MA4GA1Ud
DwEB/wQEAwIFoDCCAYEGCisGAQQB1nkCBAIEggFxBIIBbQFrAHcAZBHEbKQS7KeJ
HKICLgC8q08oB9QeNSer6v7VA8l9zfAAAAGUb7AVfwAABAMASDBGAiEAn1fvHOzU
u19APmeBj/FP9qVp2N4+CTrpH9D92y91RXECIQC4N2mBTy3cVzKLycnf2ssuNmk4
lq3IRDe1qCKkq/u9JwB3ABmG1Mcoqm/+ugNveCpNAZGqzi1yMQ+uzl1wQS0lTMfU
AAABlG+wFXsAAAQDAEgwRgIhAPySQ6/K839UmMj9v/d2ENIoP8j35NgMOvpDpc72
iNGTAiEA40WlgC8eelx+9v4KjiCFeTDMRiA8MuUf4/8Bu53TxjQAdwAOV5S8866p
PjMbLJkHs/eQ35vCPXEyJd0hqSWsYcVOIQAAAZRvsBV3AAAEAwBIMEYCIQDR90XN
oMv4hbu2F8+9hBsLApMb8UapfYkoSfPZqvT25QIhANhr+h0vkdQlYdwVEsH6cwma
+skTZRhLc7H8AKrp/FAOMA0GCSqGSIb3DQEBCwUAA4ICAQARDiIPW3fo88MmPjJu
EqrAy5aqeTKWx8+RADeSFR0tSX+K5cPuFaoKSNfoQ177N7FA0/k9VXwSi148psmr
S/XtQBAu+JKKuceLNuiPFJkJH4ik5KgtYP3UzCubx5rppIoVqplIxyi60MCYp5a6
CX9gtYByRXL24J0qg93npnodxiKDgQDo+TvNFtG62GnwD2ttyFlafA4ckei0Tkyc
IsD79RniOTeANqQBULjle8+ig4Hi4helUWdv6utFDsi8yoaUVoIlBYurFPkzFb4j
zpGgnEbe7DtOUFjOH8Ucg4r2ROxFIpKXAUWdgPlZ8+UOPxQpEUmLX5htYxdv5/eX
9PCrlga7UtBprL1xz5ETjsPtvrAj6wZ9cIsKfsJfYndxmnhIvRkElLZKX6/e8GRN
oKvCXCCr22EhqsyyRp7j54fomwg23WYBl2PEA6cP3DSHiOD9WaE4ZB17bhF2EOPN
mwrvVbnycbKTPavybaLGTclhOuYVDQMI23thMyl3ozrCnwOQKGEKfPlDl5f6NjIA
2W5HlmqVc/m3nJlwx7iAIRxwzNt/S1kI67N1a5lkzI9IlFkqTEJmOtFH5gS8HPJC
tq/Hz+bi291J8SHP48WrMdYY3E+HUm2PCxocSowXKCt7qGp2waE+Y9j8wekYeqaL
H4nNbodDUulUAh9dX/N77OmWJw==
-----END CERTIFICATE-----
subject=C = CA, ST = Quebec, L = Gatineau, O = Shared Services Canada, CN = health-products.canada.ca
issuer=C = US, O = SSL Corporation, CN = Entrust OV TLS Issuing RSA CA 1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4178 bytes and written 411 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
I'm not sure I'm following everything here, but I can report I'm seeing the same issue - a URL that was working in curl 6.0.0 generates an error in 6.2.0:
Curl 6.0.0:
> curl::curl("https://www.transtats.bts.gov", "r")
A connection with
description "https://www.transtats.bts.gov"
class "curl"
mode "r"
text "text"
opened "opened"
can read "yes"
can write "no"
Curl 6.2.0:
> curl::curl("https://www.transtats.bts.gov", "r")
Error in open.connection(con, open = mode) : cannot open the connection
In addition: Warning message:
Failed to open 'https://www.transtats.bts.gov': SSL certificate problem: self-signed certificate in certificate chain
In my case, this appears to be because the "SSL.com TLS RSA Root CA 2022" is in the certificate chain for https://www.transtats.bts.gov, which I think is what @jay was saying.
Update: this is on MacOS, and appears to be a result of #376.
OK, I've done some additional digging, and it seems that the issue is that the cacert bundle provided by Apple is incomplete/outdated. Homebrew addresses this by using their own cacert.pem: https://github.com/orgs/Homebrew/discussions/2444. Perhaps that's needed here?
Adding the following to my .Renviron fixes the issue:
CURL_CA_BUNDLE=/opt/homebrew/etc/ca-certificates/cert.pem
Also, base::url does work to fetch the URL:
> base::url("https://www.transtats.bts.gov", "r")
A connection with
description "https://www.transtats.bts.gov"
class "url-libcurl"
mode "r"
text "text"
opened "opened"
can read "yes"
can write "no"
This should be fixed in curl 6.3.0 which is now on CRAN.
FFI we now use this hack to build against apple libressl: https://github.com/jeroen/apple-libressl-sdk