Cloudflared configuration returns 525

Hi folks

I have created a tunnel using Cloudflared on Windows for a subdomain that will only be used internally via a Cloudflare Teams application.

The config.yml looks like this

tunnel: [name]
credentials-file: C:\Windows\System32\config\systemprofile\.cloudflared\[credentials file].json
url: https://[serviceorigin]:443
origincert: C:\Windows\System32\config\systemprofile\.cloudflared\argoorigincert.pem
logfile: C:\Windows\System32\config\systemprofile\.cloudflared\tunnel.log

The [serviceorigin] is the server name including subdomain.domain and it is using a Cloudflare issued certificate and it works from the local machine or other machines in the network.

[argoorigincert.pem] is a Cloudflare-generated certificate for Cloudflared to act on behalf of the origin.

Cloudflared is running as a service and the logfile is normal:

{"level":"info","tunnelID":"8cf52409-","time":"2021-08-29T02:43:30Z","message":"Starting tunnel"}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"Version 2021.8.7"}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"GOOS: windows, GOVersion: devel +a84af465cb Mon Aug 9 10:31:00 2021 -0700, GoArch: amd64"}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"cloudflared will not automatically update on Windows systems."}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"Initial protocol http2"}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"Starting metrics server on 127.0.0.1:57346/metrics"}
{"level":"info","time":"2021-08-29T02:43:30Z","message":"cloudflared does not support loading the system root certificate pool on Windows. Please use --origin-ca-pool <PATH> to specify the path to the certificate pool"}
{"level":"info","connIndex":0,"location":"MEL","time":"2021-08-29T02:43:31Z","message":"Connection 882990b5  registered"}
{"level":"info","connIndex":1,"location":"SYD","time":"2021-08-29T02:43:31Z","message":"Connection da3f860d  registered"}
{"level":"info","connIndex":2,"location":"MEL","time":"2021-08-29T02:43:32Z","message":"Connection 8820782c  registered"}
{"level":"info","connIndex":3,"location":"SYD","time":"2021-08-29T02:43:34Z","message":"Connection 247c7c74  registered"}

The message about the certificate pool is only relevant if using a non-Cloudflare issued certificate. Regardless, I’ve added origin-ca-pool: C:\Windows\System32\config\systemprofile.cloudflared\cloudflare_origin_ca_rsa_root.pem which is the Cloudflare CA certificate, just in case.

Despite this, accessing the application through the tunnel shows me an error 525 - SSL handshake failed (with and without the origin-ca-pool listed).

I only found one other case before but with no resolution. Contacted support but I really want to know if there’s some knowledge in the community.

Any suggestions?

1 Like

You’ve usually got a pretty good handle on Cloudflare configurations, so I may be misunderstanding what you’re trying to do.

When I look at this, it doesn’t look like my config.yml file with Ingress rules. I don’t use url: or origincert:. And my Ingress rules are below that.

tunnel: TUNNEL_ID
logDirectory: /var/log/cloudflared
credentials-file: /root/.cloudflared/TUNNEL_ID.json

ingress:
  - hostname: sub.example.org
    service: https://localhost:443
    originRequest:
      connectTimeout: 30s
      noTLSVerify: true
  - hostname: ssh.example.org
    service: ssh://localhost:22
  - service: http_status:404

Thanks. The config.yml is based on the basic version in this section https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/config#file-location

I have modified it to use ingress rules instead, similar to yours, and made it a very simple one:

tunnel: 8cf52409
credentials-file: C:\Windows\System32\config\systemprofile\.cloudflared\8cf52409.json
logfile: C:\Windows\System32\config\systemprofile\.cloudflared\tunnel.log

ingress:
- hostname: [subdomain].[domain]
  service: http://localhost:80
- service: http_status:404

I intentionally used http://localhost:80 to make sure there was no certificate involved (this service is running on a machine that does not serve public requests so I do have non-SSL available for testing). And yet, I still get the handshake error:

Capture

2 Likes

If I stop the Cloudflared service and visit the subdomain I get

Argo Tunnel error
You've requested a page on a website (safepeak.geekzone.co.nz) that is on the Cloudflare network. The host ([subdomain].[domain]) is configured as an Argo Tunnel, and Cloudflare is currently unable to resolve it.

And when I restart the tunnel:

SSL handshake failed
Cloudflare is unable to establish an SSL connection to the origin server.

So it seems the tunnel itself is working but connection between Cloudflare and the cloudflared client is failing.

So I’ve added

origincert: C:\Windows\System32\config\systemprofile\.cloudflared\argoorigincert.pem

And still getting the 525 error.

The argoorigincert.pem is the one issued by Cloudflare as per the instructions here https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/config#origincert

The log still says “cloudflared does not support loading the system root certificate pool on Windows. Please use --origin-ca-pool to specify the path to the certificate pool” and I assumed this was for comms between the cloudflared client and the service - that’s why I set it to localhost:80.

It should be a pretty simple setup for a single application but I wonder how many people have done this under Windows Server…

1 Like

And I know the rules is ok:

Capture

Just a random guess, could it be that you are missing https://developers.cloudflare.com/ssl/origin-configuration/origin-ca#4-required-for-some-add-cloudflare-origin-ca-root-certificates?

1 Like

Thanks but no, it is installed otherwise I wouldn’t be able to browse to the https version locally.

1 Like

I assume you mean you added the certificate to your browser truststore, right? That shouldn’t be related to the case at hand though.

Again, I am rather guessing here, but it might be worth checking if the chain is correct.

1 Like

Added to Trusted CA Local Machine. The documentation says we would not have to do that if using a CF issued certificate (only need to load and set ca-pool if using non CF certs).

1 Like

Sure, but this only applies to browsers using that (e.g. not Firefox) and as you quoted earlier

Where would it say that? But yeah, if you can rule out that you need the root certificate, then you probably won’t need it.

This applies to any application using a certificate whose chain ends on that CA - if the libraries used to create the application support access to the Windows Certificate Store - which the GO libraries used by Cloudflare don’t.

https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/ingress#capool says “Path to the CA for the certificate of your origin. This option should be used only if your certificate is not signed by Cloudflare.”

I didn’t say it wouldn’t. But Firefox and Cloudflare do not.

Fair enough.

1 Like

I’ve skimmed through the replies I missed, but would adding originRequest section to set noTLSVerify to “true” help?

I’m trying to figure out why there’s a 525 on a Cloudflare tunnel. I didn’t think it it was a typical connection.

I also see you put in a value for Tunnel. The tunnel IDs I’ve been getting are a lot longer, liks 6ff42ae2-765d-4adf-8112-31c55c1551ef

And, uh, you’re using the CNAME that points to something like 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com, right?

Yes, I have truncated the tunnel id in the posts but the actual config contains the whole string as per cname created by Cloudflared.

I can try the notls option later today.

1 Like

Thanks for the suggestion. Tried - still SSL handshake error.

Since this domain is set to SSL Strict I wondered if Cloudflared requires even tunnel source to be using a valid SSL - even when specifying a http: 80 origin.

If that’s the case then the “certificate pool” would be a requirement but the documentation is really poor on where this pool resides. Support tells me it’s a PEM file while the cloudflared messages about certificates under windows say it’s a path.

In any case, I have also tested with https: 443 origin and specifying caPool as per the Ingress documentation “Path to the CA for the certificate of your origin. This option should be used only if your certificate is not signed by Cloudflare.” (even though this origin IS using a Cloudflare certificate, unlike the others).

Still 525 SSL Handshake error.

It’s Monday morning here. I am contacting the datacentre network support to add a firewall rule to allow inbound connections from Cloudflare IPs to this server (it’s a different machine from our main website servers, hence no inbound routes before and the reason to create a tunnel) and will just configure as a normal subdomain behind Cloudflare Access.

Unfortunately, I have spent the whole weekend on this project already and although I have learnt a lot I think I can’t spend more time as I have other projects that need attention during the week.

Thanks, everyone for your suggestions. I will keep the Argo Tunnel in place in case a new suggestion comes in and I will test it later.

Cheers

One more thing I’ve tested:

- hostname: [subdomain].[domain]
  service: hello_world

This should simply return “Hello world” as per documentation. It does not interact with origin, only with the Cloudflared Argo Tunnel service.

It again came with 525 SSL Handshake error, despite origincert being specified in the config file (with a Argo cert download from Cloudflare as per https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/config#origincert). I think it proves the problem is the tunnel.

That certainly seems reasonable, but not encouraging.

You didn’t mention if you had the CNAME set up correctly.

Yes, that’s what I mean when I mention “as per cname created by Cloudflared.” - used instructions per https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/routing-to-tunnel/dns#route-traffic-from-the-command-line and checked the CNAME afterwards and it correctly points to the full argo domain.

I know this is working because if I stop the Argo service I get " Argo Tunnel error 1033" instead of the handshake error.

1 Like

This is just a mystery to me. Without a certificate and minus the TLSVerify line, I get a 502 Bad Gateway.

Added the noTLSVerify (true) line, and the server returns a 404.

Changed the host line to http and Port 80, minus the noTLSVerify line, and it works fine with HTTPS on the browser.

And I think that exhausts all I can suggest. Good luck!