Certificate issues
evakq8r opened this issue · comments
Hello,
I'm currently trying to setup cloudflared following IBRACORP's setup guide, however I'm encountering errors in the cloudflared log file in Unraid.
The tunnels setup correctly and the sessions are visible, however the first error that appears is:
2021-06-06T08:58:13Z ERR error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: x509: certificate is not valid for any names, but wanted to match <my.domain>" cfRay=65b07008895bfe7c-SYD originService=https://192.168.1.100:1443
The IP and port points to my Nginx Proxy Manager SSL port hosted in Unraid, with the docker container sitting in the same network as the rest of my reverse proxy setup.
I did a bit of research and added the 'noTLSVerify' parameter to the config file, which changed the error slightly:
2021-06-06T10:02:46Z ERR error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared: x509: cannot validate certificate for 192.168.1.100 because it doesn't contain any IP SANs" cfRay=65b0ce97caaffd22-SYD originService=https://192.168.1.100:1443
I know the SAN is the Subject Alternative Name, but Lets Encrypt doesn't accept IP addresses in wildcard or normal SSL certs (unless self-signed), so I'm not sure where to go from here. I've also ensured the UUID was setup as a CNAME in the Cloudflare panel and recreated the tunnel several times, ensuring the UUID changes with it, and have had new SSL certs generated by Lets Encrypt via NPM with no change to the outcome.
I've checked my Cloudflare setup and have a valid origin cert configured (have also replaced it), and my NPM SSL certs for each host I have an SSL covered for is also pointing to the origin cert (by way of adding the .pem and .key files into NPM manually).
Config with first error:
tunnel: <my_UUID>
credentials-file: /home/nonroot/.cloudflared/<my_UUID>.json
ingress:
- service: https://192.168.1.100:1443
originRequest:
originServerName: <my.domain>
Config with second error:
tunnel: <my_UUID>
credentials-file: /home/nonroot/.cloudflared/<my_UUID>.json
ingress:
- service: https://192.168.1.100:1443
originRequest:
noTLSVerify:
originServerName: <my.domain>
Note, I can't add the boolean of true or false to noTLSVerify as the docker container for cloudflared bootloops and says there's a YAML config error. It only works/doesn't throw an error with the setup as above.
I'm hoping it's something simple I'm missing, but any ideas on how to resolve this would be great. Thanks :)
If you want to run noTLSVerify, an example of what the config would look like is below
tunnel: <my_UUID>
credentials-file: /home/nonroot/.cloudflared/<my_UUID>.json
ingress:
- service: https://192.168.1.100:1443
originRequest:
noTLSVerify: true
in terms of getting it to work, without noTLSVerify, try replacing my.domain with host.my.domain, where host is a subdomain you have valid DNS records for.
You should be able to get noTLSVerify working, however if you want SSL verification this seems to be a common issue, see https://github.com/aeleos/cloudflared#troubleshooting
Thanks for the feedback @aeleos . I was able to get it working by adding sub.my.domain as the originServerName.
I am however still getting some 400 and 502 Bad Gateway errors, even though all my hosts are reachable with the UUID setup as a CNAME in Cloudflare:
2021-06-07T01:35:51Z ERR error="unexpected origin response: 400 Bad Request" cfRay=65b6256aedbe16cd-SYD originService=https://192.168.1.100:1443
2021-06-07T01:42:52Z ERR error="unexpected origin response: 502 Bad Gateway" cfRay=65b62fb0cee162b9-SYD originService=https://192.168.1.100:1443
Is there any way I can drill down as to what is throwing this error? The same origin SSL cert is associated with each host I have reverse proxied, but I'd like to work out what's throwing these errors.
As far as I understand, those errors aren’t being generated by cloudflared but are being sent by your reverse proxy. So when cloudflared sends a request to your reverse proxy and gets a 400 or a 502 it generates that type of error in the logs. You could try checking your reverse proxy logs and see if you can match the requests, but if everything is working my understanding is that those errors are OK.