Err_ssl_protocol_error

Help
#1

1. Caddy version (caddy version):

Caddy version v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

Caddy runs as a web server on port 80 and 443

a. System environment:

Ubuntu 18

b. Command:

sudo systemctl reload caddy

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

{
	email john@***.com
}
(common){
	encode gzip
    php_fastcgi unix//run/php/php7.4-fpm.sock
    file_server
}
www.sand-box.online{
        redir https://sand-box.online{uri}
}

sand-box.online{
        root * /var/www
        import common
        log {
                output file /var/log/caddy/sandbox.log
                format console
    }
}

maarifa.sand-box.online{

        root * /var/www/maarifa
        import common
        log {
            output file /var/log/caddy/maarifa.log
            format console
        }
}

3. The problem I’m having:

I am new to Caddy so the configurations above I made using the help of https://caddyserver.com/docs/caddyfile/concepts documentation. I am not entirely sure it is correct.

The error I get is:
http: TLS handshake error from 63.143.42.245:48140: no certificate available for ‘sand-box.online’
http: TLS handshake error from 41.80.45.8:52851: no certificate available for ‘sand-box.online’

The ports 445 and 80 are open.

The previous configurations worked well:
sand-box.online{
root * /var/www
encode gzip
php_fastcgi unix//run/php/php7.4-fpm.sock
file_server
log {
output file /var/log/caddy/sandbox.log
format console
}
}

When I added the new configurations and added the subdomain, the certificate issue stopped and got an error

4. Error messages and/or full log output:

The error from journalctl -xe:

http: TLS handshake error from 63.143.42.245:48140: no certificate available for ‘sand-box.online’
http: TLS handshake error from 41.80.45.8:52851: no certificate available for ‘sand-box.online’

5. What I already tried:

6. Links to relevant resources:

#2

Howdy @sheke,

These looks like a problem to me.

The Caddyfile uses spaces primarily to delimit “tokens”, so Caddy would read this as a literal domain www.sand-box.online{ - there needs to be a space here between the domain and the opening brace.

The fact that you state it worked previously with this issue seems odd.

I’m not seeing any other issues with your Caddyfile.

Can you share the journal output from the reload process?

3 Likes
#3

Thank you soo much!!! It worked. I was stuck on it for a while, checking documentation and forums. It was the space between the domain and curly bracket.

3 Likes
#4

It seems like the Caddyfile parser should be handling or rejecting this situation. Will open an issue. :slight_smile:

#5

That’s what caddy fmt is for.

#6

Formats the Caddyfile by adding proper indentation and spaces to improve human readability.

In this case it would change behaviour, which I imagine is not the intention of fmt?

It seems to me that if you miss out this space then Caddy should either understand or consider the Caddyfile invalid. Either way, the user wouldn’t get a confusing error message unrelated to the actual problem.

#7

It’s a formatting problem, so caddy fmt fixes what is likely to become a lexing error (or mistake).

#8

Surely interpreting www.sand-box.online{ as a domain is a bug?

#9

A bug would be if the Caddyfile deviated from the specification.

In this case, the specification requires a space between the site label (i.e. the domain) and the opening brace, so it is not a bug if the Caddyfile follows this convention in practice.

Caddy can serve very arbitrary hostnames, but it’s not intelligent like you and I; it doesn’t look at that example and think, “that’s almost a real public domain, except for the { on the end, maybe it was a mistake?”. Caddy assumes a lot of sane defaults, but I think it would be anti-user to assume outright mistakes like this.

#10

Ah. So, as far as Caddy is concerned it is theoretically possible that the hostname could contain a {?

#11

Theoretically, yes. It will happily allow you to configure a route for the literal host {.

That said, I think it counts as a malformed header…

1 Like