CURL: Error 28: I cannot fix, because each "solution" does NOT tell you HOW to troubleshoot/fix

baker7 · 11-07-2023, 11:26 AM

Good Morning:

I am not sure how to proceed: Running:
========================================
brian@cardinal:/var/www$ uname -a
Linux cardinal 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux
brian@cardinal:/var/www$ uname -r
5.10.0-26-amd64
brian@cardinal:/var/www$

Whatever I do, with wordpress, which used to be FAST, and would load my sites like lightning, now, I cant get these sites to load fast. I look at the "Site Health" page, and it says:

The REST API is one way WordPress, and other applications, communicate with the server. One example is the block editor screen, which relies on this to display, and save, your posts and pages.

The REST API request failed due to an error.
Error: cURL error 28: Resolving timed out after 10000 milliseconds (http_request_failed)

and:

Your site is unable to reach WordPress.org at 198.143.164.251, and returned the error: cURL error 28: Resolving timed out after 10000 milliseconds

and:

Loopback requests are used to run scheduled events, and are also used by the built-in editors for themes and plugins to verify code stability.

The loopback request to your site failed, this means features relying on them are not currently working as expected.
Error: cURL error 28: Resolving timed out after 10000 milliseconds (http_request_failed)

and
Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using.

Passed No version control systems were detected.
Passed Your installation of WordPress does not require FTP credentials to perform updates.
Warning Couldn't retrieve a list of the checksums for WordPress 6.0.3. This could mean that connections are failing to WordPress.org.

I am assuming that I am running what I should be, but curl is a PAIN: it was working before, and it apparently still does, but I cant troubleshoot the error because it tells me here:

https://www.hostinger.com/tutorials/curl-error-28

to Disable Firewalls in Wordpress (There are NONE on)
to Disable All wordpress plugins (They have been disabled)
to Reconfigure/reinstall SSL certificates (running a check on them gives me an "A")
to check Curl Version (curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09)

To increase PHP Limits and timeouts: (They have been increased. BUT the problem still exists, even on a site that has a Newer version of wordpress than the site I am talking about (Buddy-baker.com) I have 4 domains, and all of them act slow) Im beginning to wonder if this thing is screwed, cause there is no "FIX" here on that site, and I dont know WHAT files need to be changed, and I have wp-config.php for EACH site. and there are php.ini's that have been adjusted.

I would appreciate a response that tells me something like:

"This is an error that is caused by <Insert explanation>"
"You need to: Check/edit/change <Insert files and locations">

This would be more helpful than to tell me that the error is a Curl 28, and shooting solutions that dont tell me what and how to change the files that may be the problem. I am also wondering if my mysql data file is really BIG, so that the site is slow because of too many queries being called, and it cant get to wordpress website, and i cant download any updates from the dashnoard either!

Is there a WAY to fix this error from hell? My website used to be faster, and now its slow, and I am not sure why, and the resources to fix this are not solutions. They look like ads or blog posts with theroy, and no step-by-step instructions: I AM the site admin, hosting my OWN site, I am NOT being hosted by anyone, so there's NO "Contacting the host provider" as a solution.

I hope that I was able to give you the information you may need. Please feel free to ask for anything else you may require. I am sorry if this may be the wrong place for this, but I am at a loss

Thanks,

Brian

lvm_ · 11-07-2023, 12:20 PM

No idea except the obvious try 'curl -vvv api.wordpress.org', and it is a weird error message - it says resolving failed and then mentions the resolved IP address BUT curl 7.74.0 has a critical vulnerability rated a whopping 9.8 https://nvd.nist.gov/vuln/detail/CVE-2023-38545 No one should have this on their machine. Upgrade at once.

baker7 · 11-07-2023, 01:02 PM

Quote:

Originally Posted by lvm_

No idea except the obvious try 'curl -vvv api.wordpress.org', and it is a weird error message - it says resolving failed and then mentions the resolved IP address BUT curl 7.74.0 has a critical vulnerability rated a whopping 9.8 https://nvd.nist.gov/vuln/detail/CVE-2023-38545 No one should have this on their machine. Upgrade at once.

Sounds Like I need to install the latest version of curl - Should I then do 8.4.0, and how to I make sure that the libraries (libcurl and others needed come with it when installing. I need to command curl 8.4.0, because 7.74 is still current.

EDIT: Ive downloaded Curl 8.4.0, and unzipped, configured, and make'd install but I still see:

curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets

How do I now force use of the new version of curl, instead of 7.74.0, and how do fix php if necessary? I'm kinda new to having to compile

Brian

boughtonp · 11-07-2023, 02:46 PM

Your profile is incorrect when it says "Debian 11 (Buster)" because Buster is Debian 10; Debian 11 is Bullseye. Since you're on Curl 7.74 you're probably on the latter.

You do NOT need to update to Curl 8, you simply need to ensure you have the appropriate security repo enabled in your Apt sources and update/upgrade as normal.

The relevant Debian information for the above CVE is at: https://security-tracker.debian.org/...CVE-2023-38545

Note how 7.74.0-1.3+deb11u9 is vulnerable and 7.74.0-1.3+deb11u10 is fixed - and the only difference between those is the number after "deb11u". The full version is shown by "apt info curl" but not by "curl --version".

baker7 · 11-07-2023, 03:37 PM

Quote:

Originally Posted by boughtonp

Your profile is incorrect when it says "Debian 11 (Buster)" because Buster is Debian 10; Debian 11 is Bullseye. Since you're on Curl 7.74 you're probably on the latter.

You do NOT need to update to Curl 8, you simply need to ensure you have the appropriate security repo enabled in your Apt sources and update/upgrade as normal.

The relevant Debian information for the above CVE is at: https://security-tracker.debian.org/...CVE-2023-38545

Note how 7.74.0-1.3+deb11u9 is vulnerable and 7.74.0-1.3+deb11u10 is fixed - and the only difference between those is the number after "deb11u". The full version is shown by "apt info curl" but not by "curl --version".

Problem is, I dont have a source of the curl so that it can be apt-get updated and apt-get installed - Doing apt-get update curl does nothing, because it days its at the newest version.

Brian

boughtonp · 11-07-2023, 04:40 PM

(It is not necessary to quote whole messages, especially when yours is the immediate next reply. Doing so adds unnecessary noise to a thread.)

To identify the currently installed version, run "dpkg-query -W curl" (or "apt info curl | grep '^Version:'")

If the result of that does not match the fixed version (i.e. ending in deb11u10), post the output of "egrep -v '^#|^$' /etc/apt/sources.list" and we'll go from there.

Stop trying to install Curl 8 from source - that is absolutely the wrong thing to do here, and will only cause problems in future.

-

Also, none of this will fix the issue you highlighted, it is simply ensuring you don't have a security vulnerability.

A step towards diagnosing your main issue might be to provide the output of "curl -IL api.wordpress.org", and (depending on what that says) the output of "curl -vIL api.wordpress.org" will provide the verbose version - being sure to put it inside "[code]..[/code]" tags.

baker7 · 11-07-2023, 05:01 PM

OK: did some checking, and as I always should do is keep digging:

First: I had to do a apt-get update && apt-get update: that gave me a bunch of new updates, and that included the curl 7.74.0 with the U11 on the end, and I think it also updated php, mysql,client and server, and other things. It also allowed me NOT to remove things right away. Ive learned from experience that if you start using a sledgehammer rather than a fine tool to fix things, it can backfire. So, I let all of that run, and I should be ok here, unless there is something that I did not count on. I'm sometimes hesitant to run the apt-get update && apt-get upgrade command, because the result is a BUNCH of programs that it says it needs, and I cant see all of that on the screen, because it moves too FAST, and doing that can cause problems if you CANNOT see the output on the screen.

after doing the upgrade to curl 8.4.0, I still had curl 7.740 in there and It said when there was a 'libcurl mismatch' between version 7.74.0 and 8.4.0.

All I did was to restart the system and we have:

brian@cardinal:~$ curl --version

curl 8.4.0 (x86_64-pc-linux-gnu) libcurl/8.4.0 OpenSSL/1.1.1w
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile NTLM SSL threadsafe TLS-SRP UnixSockets
brian@cardinal:~$ php -v

PHP 8.2.12 (cli) (built: Oct 27 2023 13:01:32) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.12, Copyright (c) Zend Technologies
with Zend OPcache v8.2.12, Copyright (c), by Zend Technologies
brian@cardinal:~$mysql --version

mysql Ver 8.0.35 for Linux on x86_64 (MySQL Community Server - GPL)
brian@cardinal:~$

Now, I have to see if the websites move faster, and I think CURL being updated to get rid of the vulnerability will help. Lets hope for the best

I will keep you advised, and I THANK you for helping me as well, telling me about the problem with outdated curl

Oh, and I also updated my version of Debian in profile to Bullseye

Musta read something wrong when I changed it from 8.0 (Jessie) to Bullseye

Thanks,

Brian

baker7 · 11-07-2023, 05:32 PM

Noted: I wont quote something if it makes the thread seem "noisier"

I will also post the output [To identify the currently installed version, run "dpkg-query -W curl" (or "apt info curl | grep '^Version:'")

If the result of that does not match the fixed version (i.e. ending in deb11u10), post the output of "egrep -v '^#|^$' /etc/apt/sources.list" and we'll go from there.] you requested in the next reply

Here is that curl output you asked for:

Code:

brian@cardinal:~$ curl -IL api.wordpress.org
HTTP/1.1 302 Found
Server: nginx
Date: Tue, 07 Nov 2023 23:14:20 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Location: https://developer.wordpress.org/rest-api/
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3=":443"; ma=86400
X-nc:  ord 4

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Nov 2023 23:14:20 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Olaf: ⛄
Link: <https://developer.wordpress.org/wp-json/>; rel="https://api.w.org/"
Link: <https://developer.wordpress.org/wp-json/wp/v2/rest-api-handbook/22832>; rel="alternate"; type="application/json"
Link: <https://developer.wordpress.org/?p=22832>; rel=shortlink
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3=":443"; ma=86400
X-nc: HIT ord 1

Code:

brian@cardinal:~$ curl -vIL api.wordpress.org
*   Trying 198.143.164.251:80...
* Connected to api.wordpress.org (198.143.164.251) port 80
> HEAD / HTTP/1.1
> Host: api.wordpress.org
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
< Server: nginx
Server: nginx
< Date: Tue, 07 Nov 2023 23:18:58 GMT
Date: Tue, 07 Nov 2023 23:18:58 GMT
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Connection: keep-alive
Connection: keep-alive
< Location: https://developer.wordpress.org/rest-api/
Location: https://developer.wordpress.org/rest-api/
< X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
< Alt-Svc: h3=":443"; ma=86400
Alt-Svc: h3=":443"; ma=86400
< X-nc:  ord 5
X-nc:  ord 5

<
* Connection #0 to host api.wordpress.org left intact
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://developer.wordpress.org/rest-api/'
*   Trying 198.143.164.252:443...
* Connected to developer.wordpress.org (198.143.164.252) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* 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 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.wordpress.org
*  start date: Dec  6 00:00:00 2022 GMT
*  expire date: Jan  6 23:59:59 2024 GMT
*  subjectAltName: host "developer.wordpress.org" matched cert's "*.wordpress.org"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo ECC Domain Validation Secure Server CA
*  SSL certificate verify ok.
* using HTTP/1.1
> HEAD /rest-api/ HTTP/1.1
> Host: developer.wordpress.org
> User-Agent: curl/8.4.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx
Server: nginx
< Date: Tue, 07 Nov 2023 23:18:59 GMT
Date: Tue, 07 Nov 2023 23:18:59 GMT
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< Connection: keep-alive
Connection: keep-alive
< Vary: Accept-Encoding
Vary: Accept-Encoding
< X-Olaf: ⛄
X-Olaf: ⛄
< Link: <https://developer.wordpress.org/wp-json/>; rel="https://api.w.org/"
Link: <https://developer.wordpress.org/wp-json/>; rel="https://api.w.org/"
< Link: <https://developer.wordpress.org/wp-json/wp/v2/rest-api-handbook/22832>; rel="alternate"; type="application/json"
Link: <https://developer.wordpress.org/wp-json/wp/v2/rest-api-handbook/22832>; rel="alternate"; type="application/json"
< Link: <https://developer.wordpress.org/?p=22832>; rel=shortlink
Link: <https://developer.wordpress.org/?p=22832>; rel=shortlink
< X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
< Alt-Svc: h3=":443"; ma=86400
Alt-Svc: h3=":443"; ma=86400
< X-nc: EXPIRED ord 2
X-nc: EXPIRED ord 2

<
* Connection #1 to host developer.wordpress.org left intact
brian@cardinal:~$

Looking at this, I see something that hits me like a ton of bricks:

Code:

* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://developer.wordpress.org/rest-api/'
*   Trying 198.143.164.252:443...
* Connected to developer.wordpress.org (198.143.164.252) port 443

What I think is that something on buddy-baker.com, is trying to communicate with host api.wordpress.org, and somewhere, I have an http request that could possibly TIME OUT because it goes http FIRST, when I think if I could make that an HTTPS request, it would work correctly, because it would NOT hang, and throw the REST API error, and if I changed the http to https, that would also get rid of the update problem?

Does this make sense? If I'm correct, how do I tell wordpress to go https exclusively??

Thanks for all the help........I hope that we can figure this out

I think we're close

Thanks,

Brian

boughtonp · 11-08-2023, 07:18 AM

Quoting is fine when done appropriately - i.e. prune it down to make it clear what is being responded to, without being over-verbose - as is about to be demonstrated.

Quote:

Originally Posted by baker7

I'm sometimes hesitant to run the apt-get update && apt-get upgrade command, because the result is a BUNCH of programs that it says it needs, and I cant see all of that on the screen, because it moves too FAST, and doing that can cause problems if you CANNOT see the output on the screen.

Apt logs this information, see /var/log/apt directory. Also, the less command can be used to paginate output, useful if your terminal doesn't have scrollbars or scrollback functionality.

Debian is a stable OS - if you stay on the same major version the developers make an effort to have things not break/change.

That means, if using correct repos, an apt update and apt upgrade should always be safe.

Obviously it can't be guaranteed that things wont break, but with Debian you've got a very good chance of it being fine, so long as you stick to official software from official repos.

(This is not the case for other OSes, or even for some Debian derivatives, and doesn't apply when switching between major versions.)

However...

Quote:

after doing the upgrade to curl 8.4.0, I still had curl 7.740 in there and It said when there was a 'libcurl mismatch' between version 7.74.0 and 8.4.0.

...manually installing a different Curl has now put your system in an unknown state.

In addition to the libcurl version mismatch, your Curl 8.4.0 will not receive security updates - unless you manually update the source and re-compile. Also, depending on where you got that source, it will not have Debian-specific patches and thus could have obscure bugs/incompatibilities with the rest of the Debian system.

You should follow the instructions that came with the source to fully uninstall that version of Curl, and stick to supported software provided by Debian through Apt and the bullseye and bullseye-security repos.

Quote:

Originally Posted by baker7

Looking at this, I see something that hits me like a ton of bricks:
...
What I think is that something on buddy-baker.com, is trying to communicate with host api.wordpress.org, and somewhere, I have an http request that could possibly TIME OUT because it goes http FIRST, when I think if I could make that an HTTPS request, it would work correctly...

That is occurring simply because of entering 'api.wordpress.org' instead of 'https://api.wordpress.org' in the Curl command.

It's probably not occurring within Wordpress, but (if it was) ensuring relevant URL(s) are using HTTPS would avoid the redirect and make a minor difference, but not a 10 second difference, so it is unlikely to be responsible for the issue.

What Curl shows is the machine is getting a success response (200 OK) from api.wordpress.org - not a timeout - so whatever the issue in your original post is not a general one. (Or maybe it was a temporary network issue which has since been resolved).

It may be that there's a specific URL within the API which triggers it. If you've disabled all plugins then you need to check WordPress's own logs.

The relevant documentation on doing that would seem to be at https://developer.wordpress.org/advanced-administration/debug/debug-wordpress