Hiya! I wanted to setup Cerbos for the first time. But I stuck with the problem with TLS. I running Cerbos behind proxy (Caddy 2), Caddy, by default automagically setup and manage TLS Certificates. So I should have access to Cerbos admin dashboard on domain: https://cerbos.example.com (what lead to :3592 port behind the scenes) When I do not enable tls in Cerbos, then I can login to admin, but if I will try to send any request then I will get an error:

Mixed Content: The page at '<https://cerbos.example.com/#get-/admin/auditlog/list/-kind->' was loaded over HTTPS, but requested an insecure resource '<http://cerbos.example.com/admin/auditlog/list/>'. This request has been blocked; the content must be served over HTTPS.
onTryClick @ api-request.js:1143
handleEvent @ rapidoc-min.js:2

But, when I will add:

tls:
     cert: generated_by_caddy.crt
     key: generated_by_caddy.key

To config of Cerbos, then I will can't see Admin dashboard at all, instead I will get an error:

400 (Bad Request)

with the body:

Client sent an HTTP request to an HTTPS server.

What is strange for me. I can't understand what is a Client and what is the Server in this case. In my browser I have https - and the cert is valid. Caddy always using TLS. Cerbos is set to use TLS, the same cert, what Caddy is using. I have problem to troubleshot this by myself. I was googled, but is not too much, and most of them is about wrong configured traefic (not enabled TLS), but Caddy have TLS enabled by default, and I do not turn it off - and I can see in the browser, that is works correctly. This all is in Docker, and I think there can be the source of the problem, but can't find any helpful info. Would someone be able to help me?

You don’t need to configure TLS for Cerbos if Caddy provides SSL termination. I understand you tried it, and the dashboard makes HTTP calls instead of HTTPS, which is odd. The dashboard is an off-the-shelf swagger component. I’ll look into this.

Thanks @Dennis (Cerbos) Now I have more questions 😅 Please confirm If I understand your answer correctly: My first approach was correct, TLS set up on the Caddy side, and no TLS config on the Cerbos side should lead to properly secure Cerbos with TLS yes? If yes, then with this approach I have the same problem with

cerbosctl

, (btw. server flag require to provide a port, which in case like this, the port no need to be defined as domain listen only on one port) As I understand that the dashboard is not for the production (btw CLI as well isn't?), I think is much more convenient to use than CLI, as CLI needs a flags with every request what is not a convenient way in my opinion, I'm not sure but there is also no completions available for terminal. Let me know if I'm wrong, as I can't yet wrap my head around it. After reading website/docs I was thinking that Cerbos will be easy and straight forward for me. But when I get a hands dirty a bit, I have problems on every each step. At least I got it to work without TLS at all, so at least I can play a bit more with it.

> Please confirm If I understand your answer correctly: > My first approach was correct, > TLS set up on the Caddy side, and no TLS config on the Cerbos side should lead to properly secure Cerbos with TLS yes? It depends on your infrastructure configuration and your threat model. A better way to say what I mean is that SSL termination on Caddy should have worked for you. > As I understand that the dashboard is not for the production (btw CLI as well isn’t?) The CLI is being used in production. The dashboard is an API explorer meant to be used during development, but its use in production again depends on your security model. > I think is much more convenient to use than CLI as CLI needs flags with every request what is not a convenient way in my opinion. Fair enough. GUI has its benefits, although you may find the API explorer limited for the purpose of Cerbos administration. > I’m not sure but there is also no completions available for terminal. Let me know if I’m wrong, as I can’t yet wrap my head around it. Good question. I’ll raise an issue.

The Cerbos API explorer is meant for quick experimentation during development. It detects the protocol it's accessed on and uses that for the API calls. Because you didn't configure TLS between the proxy and the backend (Caddy -> Cerbos) the API explorer thinks it's being accessed over http and serves plaintext content. When you use the CLI, it uses gRPC to talk to Cerbos. If you have a proxy like Caddy in front of it, then you need to configure it to proxy gRPC calls to Cerbos. Again, TLS between Caddy and Cerbos would be helpful. If not, you'd still need to configure h2c for port 3593. Please refer to https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#tls for configuration details. If you're experimenting with Cerbos, I'd recommend starting out simple without proxies and other complications. If you're not comfortable with CLIs, you can use tools like Postman to access the API. Instructions on how to obtain the schema for Postman is documented at the top of https://docs.cerbos.dev/cerbos/latest/api/.

Thank you @Dennis (Cerbos) & @Charith (Cerbos) I think I understand whats wrong on my side a little bit better. I also think that, with a new knowledge, should be easy to deal with it in production. I starting to integrating my app with Cerbos. Thanks again.