OJS 3.3 error 500 with Guzzle

Hello everyone,
on one of my OJS instances I suddenly found myself unable to access the administrative area and the configuration area of all journals.
From the server I receive a 500 error:

AH01071: Got error 'PHP message: PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: 
cURL error 56: OpenSSL SSL_read: Connection reset by peer, errno 104 
(see https://curl.haxx.se/libcurl/c/libcurl-errors.html) 
in /instance_path/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201

Stack trace:
#0 /instance_path/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(155): 
   GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array)
#1 /instance_path/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(105): 
   GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#2 /instance_path/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): 
   GuzzleHttp\Handler\CurlFactory::...'

The error might be related to AWS-Cloudfront configurations, but I can’t figure out which ones. In the meantime, could you tell me what I need to disable or comment out to avoid the problem?

Thanks,
Alfredo

In the meantime, another hypothesis has emerged, that it’s a remote service that is not responding, but we can’t figure out which one.
Possible candidates:
Crossref/Datacite/Orcid

Hello Alfredo,

We’re experiencing the exact same issue across multiple journals we manage. These journals are hosted on different servers, which strongly suggests that this might be related to a certificate problem, possibly on the PKP servers or the external services they connect to.

Is anyone else currently facing this issue?

Best regards,

Eder Sotto

Additionally, when testing access directly via wget to the PKP URL that’s causing issues with CURL in OJS, we encountered the following error:

wget https://pkp.sfu.ca/ojs/xml/ojs-version.xml
--2025-04-17 11:30:49--  https://pkp.sfu.ca/ojs/xml/ojs-version.xml
Resolving pkp.sfu.ca (pkp.sfu.ca)... 208.70.244.23
Connecting to pkp.sfu.ca (pkp.sfu.ca)|208.70.244.23|:443... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

Is anyone else currently facing this issue?

Best regards,

Hi @Eder_Sotto,

This looks to me like a firewall issue on your end; I’m not aware of anything on ours that would result in that request failing, and we haven’t seen any server outages recently.

Regards,
Alec Smecher
Public Knowledge Project Team

I’m having the same trouble (OJS 3.4). Despite checking my firewall and even turning it off temporarily, I still cannot establish a connection with pkp.sfu.ca. The specific problems I’m seeing are an HTTP Error 500 when I try to check for updates under Administration → System Information → Check for updates, and PHP errors that appear in the log when I’m on the Plugin Gallery page in Website Settings. You can find the verbose log of the curl attempt to pkp.sfu.ca below.

HTTP2:

curl -v 'https://pkp.sfu.ca/ojs/xml/ojs-version.xml'
*   Trying 208.70.244.23:443...
* TCP_NODELAY set
* Connected to pkp.sfu.ca (208.70.244.23) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* 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 (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 to use h2
* Server certificate:
*  subject: CN=pkp.sfu.ca
*  start date: Mar 14 23:08:28 2025 GMT
*  expire date: Jun 12 23:08:27 2025 GMT
*  subjectAltName: host "pkp.sfu.ca" matched cert's "pkp.sfu.ca"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5651971810d0)
> GET /ojs/xml/ojs-version.xml HTTP/2
> Host: pkp.sfu.ca
> user-agent: curl/7.68.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
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
* stopped the pause stream!
* Connection #0 to host pkp.sfu.ca left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

HTTP 1.1:

curl -v --http1.1 'https://pkp.sfu.ca/ojs/xml/ojs-version.xml'
*   Trying 208.70.244.23:443...
* TCP_NODELAY set
* Connected to pkp.sfu.ca (208.70.244.23) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* 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 (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 to use http/1.1
* Server certificate:
*  subject: CN=pkp.sfu.ca
*  start date: Mar 14 23:08:28 2025 GMT
*  expire date: Jun 12 23:08:27 2025 GMT
*  subjectAltName: host "pkp.sfu.ca" matched cert's "pkp.sfu.ca"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
> GET /ojs/xml/ojs-version.xml HTTP/1.1
> Host: pkp.sfu.ca
> User-Agent: curl/7.68.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
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

PHP LOG:

[CHECK FOR UPDATES]
PHP Fatal error:  Uncaught GuzzleHttp\Exception\RequestException: cURL error 56: OpenSSL SSL_read: Connection reset by peer, errno 104 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://pkp.sfu.ca/ojs/xml/ojs-version.xml?id=... in /.../public_html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:276

Failed to retrieve the latest version info: cURL error 56: OpenSSL SSL_read: Connection reset by peer, errno 104 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://pkp.sfu.ca/ojs/xml/ojs-version.xml?id=...

[PLUGIN GALLERY]
cURL error 56: OpenSSL SSL_read: Connection reset by peer, errno 104 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://pkp.sfu.ca/ojs/xml/plugins.xml?application=ojs2&version=3.4.0.8
1 Like

Hi all,

I’m waiting for confirmation on whether something has changed in PKP’s network configuration.

Regards,
Alec Smecher
Public Knowledge Project Team

2 Likes

Just FYI, I tried connecting to HTTP (not HTTPS), and it seems to connect fine. However, when I follow the redirect to HTTPS, the same error I mentioned in my previous post reappears. It looks like the issue is specifically at the HTTPS connection level (checked both with the firewall enabled and disabled).

curl -v 'pkp.sfu.ca'
*   Trying 208.70.244.23:80...
* TCP_NODELAY set
* Connected to pkp.sfu.ca (208.70.244.23) port 80 (#0)
> GET / HTTP/1.1
> Host: pkp.sfu.ca
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Thu, 17 Apr 2025 23:38:27 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://pkp.sfu.ca/
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host pkp.sfu.ca left intact
1 Like

Same issue here since yesterday in a server behind a nginx load balancer with a let’s encrypt certificate.

Connection broken from server side, so it’s clear to me that it happens because something changed in the pkp.sfu.ca server.

Didn’t test yet but a temporary solution would be patching ojs to communicate via HTTP 1.1 instead of 2.

Cheers,
m.

Didn’t test yet but a temporary solution would be patching ojs to communicate via HTTP 1.1 instead of 2.

For me, HTTP 1.1 connections also have their own problem…

curl -v --http1.1 'https://pkp.sfu.ca/ojs/xml/ojs-version.xml'
*   Trying 208.70.244.23:443...
* TCP_NODELAY set
* Connected to pkp.sfu.ca (208.70.244.23) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* 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 (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 to use http/1.1
* Server certificate:
*  subject: CN=pkp.sfu.ca
*  start date: Mar 14 23:08:28 2025 GMT
*  expire date: Jun 12 23:08:27 2025 GMT
*  subjectAltName: host "pkp.sfu.ca" matched cert's "pkp.sfu.ca"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
> GET /ojs/xml/ojs-version.xml HTTP/1.1
> Host: pkp.sfu.ca
> User-Agent: curl/7.68.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
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

I’m also encountering the same issue. I initially thought it might be due to plugin incompatibility, so I posted a question asking whether OJS 3.3.0-10 can be upgraded directly to version 3.4. Could the issue be caused by plugin incompatibility or firewall configuration problems?

me too :worried:

Server sent fatal alert: handshake_failure

Fatal error : Uncaught GuzzleHttp\Exception\RequestException: cURL error 56: OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201 Stack trace: #0 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(155): GuzzleHttp\Handler\CurlFactory::createRejection() #1 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(105): GuzzleHttp\Handler\CurlFactory::finishError() #2 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish() #3 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(28): GuzzleHttp\Handler\CurlHandler->__invoke() #4 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(51): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler{closure}() #5 /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(37): GuzzleH in /var/www/html/lib/pkp/lib/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 201

Hi, same problem in several OJS 3.3 installations.

Thanks @kswro for the test. Indeed, it was a long shoot. :slight_smile:

Problem disappear in my side around two hours ago.
Now I can curl pkp.sfu.ca without any trouble and OJS is working fine again.

Please, clean all your caches and if you have any trouble, report back.

I think PKP fellows from IT are still working on it, so once finished, they will probably comment here their findings.

Hi all,

Passing a message along from the systems team:

Hi folks,

Recently, we had to block a lot of CIDRs due to abuses (AI scraping bots, essentially) and it’s possible that your network may have been inadvertently affected.
The blocks were all removed for now. If you’re still facing any issues, please ping me.

Thank you for your generous understanding. :slight_smile:

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like

Hello @asmecher and everyone,

I just wanted to express my sincere thanks for your assistance and support regarding the issue we experienced. All our OJS installations are now functioning properly again.

Your prompt responses and guidance were invaluable in helping us resolve this matter quickly.

Thanks again for the great community support!

Best regards,

Eder

2 Likes

Hi @asmecher

Just wanted to follow up – the problem doesn’t seem to be solved on my end yet. I’m still facing the exact same issues I described in previous posts: here and here.

To summarize, I can connect to pkp.sfu.ca over HTTP (even though it redirects to HTTPS), but direct HTTPS connections are failing.

While I suspect this isn’t a general IP blocking issue from my server’s end (given that HTTP connections succeed), it’s also possible that my IP address is specifically blocked on port 443. If you’d like to investigate further and need my server’s public IP, please let me know.

Please, let me know your IPv4. You may DM me if you prefer.

Just sent you a DM, thanks!

I believe everything is sorted out now.

If someone still faces any issues, please DM me with the server IPv4 and I’ll take a look.

1 Like