Misleading error when cert.pem permissions are incorrect

[wolfgang42]

trafficstars

Describe the bug cloudflared seems to overlook a cert.pem that exists but is not readable when seeking originCertPath.

To Reproduce

1. $ docker run --rm -it -v $(pwd)/.cloudflared:/etc/cloudflared cloudflare/cloudflared tunnel create foo
   2022-06-29T01:55:37Z INF Cannot determine default origin certificate path. No file cert.pem in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared] originCertPath=
   2022-06-29T01:55:37Z ERR You need to specify the origin certificate path with --origincert option, or set TUNNEL_ORIGIN_CERT environment variable. See https://developers.cloudflare.com/argo-tunnel/reference/arguments/ for more information. originCertPath=
   failed to create tunnel: couldn't create client to talk to Cloudflare Tunnel backend: Error locating origin cert: client didn't specify origincert path when running from terminal
   

2. ??? the file is definitely there

   $ ls -l ./.cloudflared/
   total 0
   -rw------- 1 wolf wolf 0 Jun 28 18:55 cert.pem
   

3. ...lots more confusion...
4. Maybe if we give the path directly?

   $ docker run --rm -it -v $(pwd)/.cloudflared:/etc/cloudflared cloudflare/cloudflared --origincert /etc/cloudflared/cert.pem tunnel create foo
   2022-06-29T01:57:05Z ERR Cannot check if origin cert exists at path /etc/cloudflared/cert.pem error="open /etc/cloudflared/cert.pem: permission denied" originCertPath=/etc/cloudflared/cert.pem
   failed to create tunnel: couldn't create client to talk to Cloudflare Tunnel backend: Error locating origin cert: cannot check if origin cert exists at path /etc/cloudflared/cert.pem
   

5. Oh.

   sudo chown 65532:65532 -R .cloudflared/
   

Expected behavior

$ docker run --rm -it -v $(pwd)/.cloudflared:/etc/cloudflared cloudflare/cloudflared tunnel create foo
2022-06-29T01:55:37Z ERR Could not read origin cert at path /etc/cloudflared/cert.pem error="open /etc/cloudflared/cert.pem: permission denied" originCertPath=/etc/cloudflared/cert.pem

(I suppose you could have a situation where there’s an unreadable file earlier in the search path, and the one you actually want comes later. But that seems like a situation where an explicit --origincert is a good idea anyway to avoid confusion.)

Environment and versions

• OS: Linux + Docker
• Architecture: x86_64
• Version: 2022.6.3 (ae790c4df3bc)

Logs and errors See above.

Additional context This happened because I shuffled some files around midway through setting up the tunnel, and accidentally dropped some permissions in the process. But that could have been a 5-second problem instead of a 5-minute one if I hadn't spent a bunch of time thinking the file had somehow disappeared from the container's filesystem.

[sudarshan-reddy]

An explicit --origincert is very much possible. You can use this already.

Also, if you don't want to bother about certs et all check out https://blog.cloudflare.com/ridiculously-easy-to-use-tunnels/ !

[wolfgang42]

Hi Sudarshan, I think you've misunderstood my report. I know about --origincert already, because I had to use it in step 4 to figure out what the actual problem was. The bug is that the error I got in step 1 is very misleading, and therefore I spent a lot of time debugging the problem: cloudflared had put the cert there, so I was very confused about why it suddenly couldn’t find the cert in the same place it had left it!

---

On “Ridiculously easy to use Tunnels” (which are off topic for this error, but since you mentioned them I thought I’d give some feedback): I skimmed that link briefly and I assume it's talking about the same thing as the ​​Set up a tunnel remotely (Dashboard setup) section of the setup guide. I did try that way first, but frankly I found it more confusing than the CLI setup. It seems like the same thing as the CLI setup (at least, I still need to install, and presumably run, cloudflared) but then my configuration is managed from the remote end? Config files and CNAMEs, I know how to use: “run a proxy and point traffic at the public end” I can wrap my head around; I’m guessing that these “ridiculous” tunnels are doing the same thing under the hood but it’s a lot less obvious what’s going on. Also for some reason I have to pick a “Zero Trust plan” in the dasboard, a step which the docs don’t mention, and I didn’t feel like figuring out what I would be signing up for.

[sudarshan-reddy]

You are right. The error is misleading indeed. I’m happy to accept a PR for this.

note: Origincert is still the recommended approach on the cli and the blogpost is an equally recommended approach (and therefore in topic) that’ll have more features and development behind it as a reliable way to control your cloudflared.

[Shawn9347]

How did you fix this issue? I have chmod 777 on the cloudflared folder but I'm still getting the error.

[wolfgang42]

I’m happy to accept a PR for this.

I looked into this briefly, but I'm not really able to understand the structure of the system well enough to recommend a fix.

The error seems to be coming from here: https://github.com/cloudflare/cloudflared/blob/dd540af695448ea1bfef28762060fb98455d455d/cmd/cloudflared/tunnel/configuration.go#L130-L135

That originCertPath argument is, I think, provided from this option: https://github.com/cloudflare/cloudflared/blob/dd540af695448ea1bfef28762060fb98455d455d/cmd/cloudflared/tunnel/cmd.go#L698-L704

Which defaults to getting its value from here: https://github.com/cloudflare/cloudflared/blob/dd540af695448ea1bfef28762060fb98455d455d/cmd/cloudflared/tunnel/configuration.go#L53-L61

and if my prior experiences with Go have any merit, that ok, _ := indicates that this code is simply ignoring any errors it might be getting—including, presumably, my permission error. So the obvious fix would be to take that error and do something with it, instead of ignoring it; but presumably you don’t want to raise errors about things in the path if the user has passed an explicit --origincert so just returning an error here isn’t the right thing to do.

I’d guess that the correct fix for this is probably to drop the default from the flags, and then move the path searching into the findOriginCert function where it can only be called when we know a flag wasn't provided. But as I said that requires more rearranging of things than I’m comfortable performing when all I’ve done is grep around and make guesses at how things fit together.

[wolfgang42]

@Shawn9347 I figured out what the actual error was by passing --origincert <path> with the full path to the cert, and then fixed that. If you're getting permission errors maybe check on the file itself and the containing folders as well?

[Shawn9347]

I fixed my problem by creating a tunnel through the gui. No need for any certificates or json files. Works like a charm.

[sudarshan-reddy]

Exactly! That’s why I linked the blog post above. It’s a minimum hassle approach unless you feel strongly about the cli.

[satonotdead]

I can't remove the tunnels because of that, it's too much annyoning and disastrous from first time user experience.

Sorry but you are minimizing a very strong issue from the user's perspective.

--certonly don't work because the permissions on the file created are wrong and I went CLI because reliability (lol).