526 errors

I am currently running two WordPress sites, both are located on the same cloud server, but have separate accounts, IPs, etc. I mention the server because there is a shared, common server firewall.

Until very recently, both sites were working perfectly. I have SSL certificates on the origin server issued by Sectigo. Both sites were using FULL(strict) SSL/TLS settings without any problems. My hosting provided moved my sites to a new server at a new data center location, but no other changes were made. Shortly after the move, I started to get 526 errors on one of the two sites. The two sites are:

PROBLEM: https://www.complianceinsight.ca
OK: https://complianceinsight.ca
OK: https://machinerysafety101.com
OK: https://www.machinerysafety101.com

I have complianceinsight.ca currently running in the FULL [not Full (strict)] mode so that the error won’t occur for the moment. I have noticed that if you go to complianceinsight.ca when SSL/TLS is set to FULL(strict) the site resolves properly, but if you go to www.complianceinsight.ca you get the 526 error. There are no redirect rules running on Cloudflare or on my hosting origin server.

I’ve gone through all of the the 526 error troubleshooting articles in the knowledgebase without fixing the problem. I’ve added the Cloudflare IPs to my server’s csf_allow file, and made sure that the firewall allow/ignore is ON.

I’ve used a variety of DNS testing tools to verify that the DNS is working properly - it is.

I’ve used a variety of SSL testing tools to verify that both the origin and Cloudflare SSL certificates are good - they are. Sectigo, my origin SSL certificate provider, used to be COMODO so there should not be an issue with CA recognition.

I’ve added CAA entries to my DNS that include both Sectigo and Cloudflare.

After all of this, I’m at a loss. If you have any additional approaches I could use to try to determine why the SSL certificate validation is failing on one of the two sites that are otherwise identically configured, please let me know.

Use the following command to diagnose server certificate problems. Be sure to use the actual server IP address:
curl -svo /dev/null https://complianceinsight.ca --connect-to ::123.123.123.123 2>&1 | egrep -v "^{.*$|^}.*$|^* http.*$"

1 Like

That would usually indicate an expired certificate. Are you sure your server certificate did not expire?

However, assuming your server IP address ends in 79, it would appear as if you had a valid certificate which only expires in September and that should not fire a 526.

And in fact, I do not get a 526

$ curl -I https://www.complianceinsight.ca/
HTTP/2 301

It also loads fine everywhere at sitemeer.com/#https://www.complianceinsight.ca

And yes, you need “Full Strict” for a secure connection → Why you should choose Full Strict, and only Full Strict

1 Like

Probably because they dropped back to Full (not strict) due to whatever certificate problem there is.

I only went by

1 Like

hey @sdayman,

I tried running the curl in the shell on the account for complianceinsight.ca, but received this error: curl: option --connect-to: is unknown.

I’m not enough of a coder to know how to reconfigure this command line to correct for the problem. My servier is running /bin/bash shell.

Hi @sandro,

You are correct, there are about 90 days left on the certificate validity. I want to move back to Full (strict) as soon as I can get this issue handled.

You’re not currently seeing 526s because I fell back to FULL, however, I am happy to go back to Full (strict) if you would like to try to diagnose the issue.

@sdayman, also, I tried running the same command under zsh in my terminal and got this error: egrep: repetition-operator operand invalid. So, still stuck.

I’ve left the complianceinsight.ca site configured with Full (strict) SSL/TLS so that anyone who wants to test the site to see if they can help me diagnose this issue has a chance to check things out.

The problem remains unresolved at the moment.

The status remains unchanged. I continue to leave the SSL/TLS settings as full/strict so that you can test the state of the setup.

ok: complianceinsight.ca
526: www.complianceinsight.ca

I continue to hope that someone in this community can lend a hand or can tell me how to get in touch with Cloudflare support.

Hi @DougN,

This is an odd situation. As already said, the certificate on your server is valid for both your root domain and a wildcard, which should cover www. When I bypass Cloudflare and connect directly to your server, it works as expected.

As all your www is doing is recirecting to the root domain on the server, a workaround would be to handle this with Page Rules at Cloudflare instead so you never get the 526.

That is only a workaround though, and I can’t see why the current setup shouldn’t work as it is.

I’ll escalate this topic to Cloudflare Support, if you are on a paid plan, you could open a ticket through your dashboard, if you’re on free you will need to wait for help here. If you do open a ticket, please share the ticket ID here.

For reference, connections direct to origin and through Cloudflare:

Direct to Origin
$ curl -svo /dev/null https://www.complianceinsight.ca --connect-to ::X.X.X.X
* Connecting to hostname: X.X.X.X
*   Trying X.X.X.X:443...
* TCP_NODELAY set
* Connected to X.X.X.X (X.X.X.X) 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
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [25 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4610 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.complianceinsight.ca
*  start date: Jun 19 00:00:00 2020 GMT
*  expire date: Sep 17 23:59:59 2021 GMT
*  subjectAltName: host "www.complianceinsight.ca" matched cert's "*.complianceinsight.ca"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.complianceinsight.ca
> User-Agent: curl/7.68.0
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [297 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [297 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 26 Jul 2021 15:45:48 GMT
< Server: Apache
< cf-edge-cache: cache, platform=WordPress
< Expires: Mon, 26 Jul 2021 16:45:50 GMT
< Cache-Control: max-age=3600
< X-Redirect-By: WordPress
< Location: https://complianceinsight.ca/
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
{ [5 bytes data]
* Connection #0 to host X.X.X.X left intact
Through Cloudflare
$ curl -svo /dev/null https://www.complianceinsight.ca
*   Trying 104.21.93.190:443...
* TCP_NODELAY set
* Connected to www.complianceinsight.ca (104.21.93.190) 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
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2301 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.complianceinsight.ca
*  start date: Jul 18 18:26:16 2021 GMT
*  expire date: Oct 16 18:26:14 2021 GMT
*  subjectAltName: host "www.complianceinsight.ca" matched cert's "*.complianceinsight.ca"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  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
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x7fffc2fc8b00)
} [5 bytes data]
> GET / HTTP/2
> Host: www.complianceinsight.ca
> user-agent: curl/7.68.0
> accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
} [5 bytes data]
< HTTP/2 526
< date: Mon, 26 Jul 2021 15:53:39 GMT
< content-type: text/html
< cache-control: no-store, no-cache
< cf-cache-status: MISS
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=cA68dXFnzVUN8bsixAxkceCjjrL5J%2FZx5d3SQ1msN%2BO40TG%2BPseRzEvysDQmbGr8Bmuu3kCBN5Fd2TphHcAWLZzjhycXlC0NVt1IExXNzVUgzB%2FvhsN8XVDTCbRqHlk%2BWuNeZxTZ2OSLEKs%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"report_to":"cf-nel","max_age":604800}
< strict-transport-security: max-age=2592000
< x-content-type-options: nosniff
< server: cloudflare
< cf-ray: 674ecd53783740dd-LHR
< alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400
<
{ [594 bytes data]
* Connection #0 to host www.complianceinsight.ca left intact

Hi Doug,

I am a part of the Cloudflare support team and have opened an internal ticket for us to help investigate this issue. You should have an email from us with the ticket ID 2215353 in the subject line.

1 Like

Thanks, domjh!

Regards,

Doug NIX, C.E.T.
Compliance inSight Consulting Inc.

Mobile: +1 (519) 729-5704

email: [email protected]

Book an appointment

Get our Newsletter

1 Like

Thanks so much, cf_evan!

Regards,

Doug NIX, C.E.T.
Compliance inSight Consulting Inc.

Mobile: +1 (519) 729-5704

email: [email protected]

Book an appointment

Get our Newsletter

Hi Doug,

I am going to close this thread, as we were able to take care of your issue via the ticket, as the issue is unique for your setup. If you have any questions, please let us know via your ticket.

2 Likes