Custom error for anyone not authorized by the ask endpoint

1. The problem I’m having:

The most current version makes the ask endpoint required, so if a domain is allowed, the ask endpoint returns a code 200 and the tls is generated, however if the domain is not allowed by the ask endpoint, it does not return a code 200, and the tls is not generated as expected behavior and then I see a message similar to “ERR_SSL_PROTOCOL_ERROR” when reverse proxying.

What I would like to do:

  • For domains not accepted by the ask endpoint, return a message for example “Unauthorized” with code 403.

I think this would be possible with handle_errors, but I’m not able to “put the pieces together” and insert this correctly into my Caddyfile, could you please help me with an example?

2. Error messages and/or full log output:

N/A

3. Caddy version:

2.7.5

4. How I installed and ran Caddy:

a. System environment:

Ubuntu 22.04

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

{
    on_demand_tls {
        interval 5m
        burst 20
        ask https://tlsvalidate.example.com
    }
}

https:// {
    tls {
        on_demand
    }
    reverse_proxy {
        to https://target.example.com
        header_up Host {upstream_hostport}
    }
}
 
*.anything.com {
    tls {
        dns route53 {
            access_key_id "AKIEXAMPLE"
            secret_access_key "RS1EXAMPLE"
            max_retries 10
        }
    }
    reverse_proxy {
        to https://target.example.com
        header_up Host {upstream_hostport}
    }
}

:80 {
        respond /online "I am healthy" 200
}

5. Links to relevant resources:

Do you mean to return that to the Caddy instance doing the asking? Or to the client who wants to establish the connection?

If it’s to the client, that’s not possible because HTTP can only be sent to the client if the connection is established first.

To be clear, the error ERR_SSL_PROTOCOL_ERROR is something the client (browser) decides to display, because the TLS handshake failed. It’s impossible for Caddy to tell the browser to do anything if a secure connection could not be established, because the client can’t trust anything the server sends.

Hi,
Tks for the answers and help! :slight_smile:

I don’t quite understand the details, but I’ll share the behavior I observed:

We imagine that my caddy is under the address portal.example.com

So if someone creates a CNAME record in your DNS, for example:

Name: myportal.myexample.com
Value: portal.example.com

Then it will reach the caddy instance and the ask endpoint will be triggered to validate whether or not it can issue the tls, which is a very good and useful feature.

If my ask endpoint validates that myportal.myexample.com is eligible, it returns a 200 code, (I imagine this is returned to the caddy), the tls is generated and the reverse proxy is done, all working very fast and well.

My question is when the ask endpoint validates that, for example, myportal.myexample.com is not eligible, that is, someone created this CNAME, but it is not in our database, it will now return a 403 code (I also imagine that for the caddy that asked), so what I observed was that tls is not generated as expected behavior (nice), and then I think that the reverse proxy does not work, because when accessing myportal.myexample.com in the browser, the error ERR_SSL_PROTOCOL_ERROR appears.

The reason for my contact, and everything I’m trying to adjust is, instead of displaying this error, when accessing myportal.myexample.com it displays a personalized message like “Not authorized”, that’s all.

But if I understand correctly, even if the caddy receives codes 200 or 403 from the ask endpoint, there is no way to handle and generate this more friendly message, as it is a response to the client (browser) and which is then not possible because as ask does not authorized, a connection was not established and then you don’t trust anything the server does.

I just wanted to share everything I noted above in more detail, to confirm that my understanding is correct and that there is nothing I can do in this case, please, if you could just confirm?

Regards,

Correct, this is because the browser cannot securely establish a connection to your server, because Caddy does not have a certificate that matches that domain. The browser cannot trust anything Caddy sends to it because it cannot verify that the contents would be encrypted by a trusted entity.

TLS certificates are a proof that a certificate authority attested that “this domain is under the control of the server/user/entity that requested the certificate”. If there’s no certificate, that proof doesn’t exist, so browsers cannot trust that server.

TLS is a layer on top of HTTP. In other words, TLS encrypts HTTP traffic, which is known as “HTTPS”. If the TLS handshake fails, then the HTTP part never happens, so Caddy will never get a chance to handle the request and run your reverse_proxy.

2 Likes

Hi,
Understood, tks for the help and explanation! :slight_smile:

Regards,
Fabio

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.