Filtering direct IP accesses ("

1. Caddy version (caddy version):

2.1.1, 2.2.0

2. How I run Caddy:

systemd / manual /etc.

a. System environment:


b. Command:

systemctl restart caddy
./caddy run --config /etc/Caddyfile

d. My complete Caddyfile or JSON config:

seen it on all client servers “internet” facing

3. The problem I’m having:

Logs getting filled/clobbered with references to the IP that had been directly accessed without SNI information

I’d like to know the best method to “catch” the non-matched, ie. “direct to IP” https connections, to either route them to a script/static file or response to have it logged in access.log rather than error.log

4. Error messages and/or full log output:

the same as in Sudden "no certificate available" / ERR_SSL_PROTOCOL_ERROR

5. What I already tried:

Read the manual and forum posts

6. Links to relevant resources:

What’s your Caddyfile config?

If you’re asking about HTTPS connections, there’s no way to handle those, because the TLS handshake needs to happen first - if the handshake fails due to missing SNI, i.e. no valid cert could be used, then Caddy can’t continue.

For HTTP connections, you can make a site block with :80 as the address to handle all connections on that port - but this means that HTTP->HTTPS redirects will be overridden, so you’ll need to re-implement them yourself in your :80 site block.

Is there a mechanism to assign a snake-oil/self-signed certificate to that default failure case?
I’ve yet to see those type of errors on a nginx setup where the default https will use a default certificate (even if the Host/SNI doesn’t match)

You can set the default_sni global option:

Browsers may still not accept it though.

AH!!! Thank you @francislavoie That is what I missed :slight_smile:

I actually do not care a single iota about the browsers in this case, as that should never be from a browser hitting it like, but rather these I do expect to be from scanners and badly configured API requests to give them the snake oil

1 Like