Website inaccessible after 6.9 upgrade

  • Resolved psuttles

    (@psuttles)


    3 months, 1 week ago

    Working with a self-hosted WP multisite installation. When attempting to upgrade the WordPress core files from version 6.8.3 to the latest release (version 6.9), the site immediately becomes unreachable displaying an error message in the browser (e.g., “ERR_SSL_PROTOCOL_ERROR” in browsers or a generic “connection reset”).

    Looking at the Apache error logs, there is the following error every time a connection attempt is made:

    AH01996: SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page

    The output of “curl -v https://www.mysite.com“:
     

    • Host http://www.mysite.com:443 was resolved.
    • IPv6: (none)
    • IPv4: xxx.xxx.xxx.xx
    •   Trying xxx.xxx.xxx.xx:443…
    • Connected to http://www.mysite.com (xxx.xxx.xxx.xx) port 443
    • ALPN: curl offers h2,http/1.1
    • (304) (OUT), TLS handshake, Client hello (1): *  CAfile: /etc/ssl/cert.pem *  CApath: none
    • (304) (IN), TLS handshake, Server hello (2):
    • TLSv1.2 (IN), TLS handshake, Certificate (11):
    • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    • TLSv1.2 (IN), TLS handshake, Server finished (14):
    • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    • TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    • TLSv1.2 (OUT), TLS handshake, Finished (20):
    • TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
    • TLSv1.2 (IN), TLS handshake, Finished (20):
    • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
    • ALPN: server did not agree on a protocol. Uses default.
    • Server certificate: *  subject: C=US; ST=State; O=Org; CN=CertName *  start date: Jul 25 00:00:00 2025 GMT *  expire date: Jul 25 23:59:59 2026 GMT *  subjectAltName: host “www.mysite.com” matched cert’s “www.mysite.com” *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Organization Validation Secure Server CA *  SSL certificate verify ok.
    • using HTTP/1.x

    GET / HTTP/1.1 Host: http://www.mysite.com User-Agent: curl/8.7.1 Accept: */*

    • Request completely sent off
    • Recv failure: Connection reset by peer
    • LibreSSL SSL_read: Connection reset by peer, errno 54
    • Closing connection curl: (56) Recv failure: Connection reset by peer

    From this curl output, it appears that the DNS and TCP connections are good, the TLS handshake completes successfully (TLSv1.2, strong cipher), the certificate is valid/not expired and is verified ( “SSL certificate verify ok“), and the GET HTTP request was sent.

    It looks to me like everything is OK until the HTTP request is sent, and that’s when the connection is killed.

    Again, this only happens after upgrading WordPress core to the latest 6.9 version. If I roll back to the previous version of WordPress (6.8.3 – reverting to prevous backups of my WP core files) and restart the Apache server, the site becomes accessible and everything is back to normal (other than being a version behind).

    Any ideas why this could be happening?



Viewing 4 replies - 1 through 4 (of 4 total)
  • Moderator bcworkz

    (@bcworkz)

    3 months, 1 week ago

    Using plain http:// protocol (instead of https://) on port 443 is invalid. Normal browser requests are typically automatically upgraded to https://. Not so with cURL. Where ever cURL is getting your domain name URL needs to be updated to use https://. I assume this is the site and home URL option settings. On multisite these are not that easy to alter. Try requesting /wp-admin/options.php (type it in, there’s no link in network settings), then searching the long list for the right settings. Don’t forget to scroll to the bottom to click the update button after making changes.

    If even options.php doesn’t work, the settings can be updated via the phpMyAdmin app, usually accessed through your hosting account.

    Thread Starter psuttles

    (@psuttles)

    3 months, 1 week ago

    Thanks for the reply and the suggestion.

    I’m assuming the options presented in the wp-admin/options.php page are the same as the wp_options table in the database? Either way, I checked both for any instance of the site or home URL using HTTP and everything I found was correctly using HTTPS.

    Also, this error message is being presented in browsers…even if I manually enter https://ww.mysite.com (“ERR_SSL_PROTOCOL_ERROR” in browsers or a generic “connection reset” when I attempt to access the site after upgrading to 6.9).

    It seems to me like the SSL layer is 100 % correct — the certificate is good, the handshake finishes perfectly. Right after the handshake finishes and (in the cURL example) cURL starts sending the actual HTTP request, Apache (or something directly in front of it) actively kills the TCP connection with a RST packet.

    Thread Starter psuttles

    (@psuttles)

    3 months, 1 week ago

    Additionally, here’s the cURL output from the working WP version 6.8.3 when I request the same URL:

    • Host www/mysite.com:443 was resolved.
    • IPv6: (none)
    • IPv4: xxx.xxx.xxx.xx
    • Trying xxx.xxx.xxx.xx:443…
    • schannel: disabled automatic use of client certificate
    • ALPN: curl offers http/1.1
    • ALPN: server did not agree on a protocol. Uses default.
    • Established connection to http://www.mysite.com (xxx.xxx.xxx.xx port 443) from xxx.xxx.xxx.xx port 55294
    • using HTTP/1.x

    GET / HTTP/1.1
    Host: http://www.mysite.com
    User-Agent: curl/8.16.0
    Accept: /

    • Request completely sent off
      < HTTP/1.1 200 OK
      < Date: Mon, 05 Jan 2026 19:32:33 GMT

    So, in both instances (6.8.3 and 6.9), the SSL connection is established…but the GET / HTTP/1.1 Host request is being denied in WP 6.9 when attempting to connect to the site via browser, whereas is returns a HTTP/1.1 200 OK response when using 6.8.3.

    Note: In the output above, none of the URLs are listed as using HTTP; they’re just listed as “www.mysite.com”. I think the support page here is treating them as URLs and adding the HTTP.

    Thread Starter psuttles

    (@psuttles)

    3 months, 1 week ago

    This issue has been resolved.

    The culprit was an F5 load balancer health check. I don’t have any details of what exactly was going on with the load balancer (we’re at a university and I was working on this issue with our campus NetOps), but whenever the update to WordPress was made from 6.8.3 to 6.9, the F5 load balancer health check failed and prevented access to the site. When I updated WordPress to 6.9 and let NetOps run a new health check, access to the site was restored via browser.

    So, moral of the story:

    For WordPress installations behind a load balancer…updating to 6.9 may cause failed health checks. Something to check out if you’re having this issue.

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.