This is my Caddyfile (with some changes to the domains):
http://*.mydomain.me:80 {
redir 301 {
/ https://{host}{uri}
}
}
https://*.mydomain.me:443 {
tls /etc/caddy_ssl_efs/ssl_custom/mydomain.pem /etc/caddy_ssl_efs/ssl_custom/mydomain.key
#proxy / https://mydomain-testing-elasticbeanstalk.mydomain.com {
# transparent
# header_downstream server "mydomain"
#}
proxy / localhost:6081 {
#header_upstream Host "localhost" # Won't work with another value
transparent
header_downstream server "mydomain"
}
}
http://* {
proxy / http://mydomain-testing-elasticbeanstalk.mydomain.com {
transparent
header_downstream server "mydomain"
}
}
https://* {
tls {
max_certs 500000
}
tls noam@mydomain.com
proxy / localhost:6081 {
#header_upstream Host "localhost" # Won't work with another value
transparent
header_downstream server "mydomain"
}
}
Now the problem is like that:
When user enter to this domain: xxxx.mydomain.me he will get the SSL from the server.
When user enter to other domain that set under the server www.example.com he sometimes will not get âletsencryptâ domain and he will get xxxx.mydomain.me SSL that of course is not related to him.
If Iâm using every part separate and run the server they are getting the right SSL without any problems. The problem is that I want to use this domains on the same server.
Might be that the user in this case is requesting a unique address before the internal cooldown period is met for On-Demand TLS. When that happens, Caddy has to use a âdefaultâ certificate to negotiate TLS; the first in the list is the one you provided for *.mydomain.me.
You could set up a server to act as an ask endpoint, instead of using max_certs - this bypasses the ten minute rate limit - and see if the issue persists?
The documentation outlines the use and role of an ask endpoint, which you will need to implement in a manner such that it returns 200 OK only for domains that Caddy should request a certificate for.
Then, by replacing max_certs [number] with ask [endpoint], Caddy will ask the endpoint if a client-requested domain is suitable, rather than wait for its one-per-ten-minutes rate limit.
These limitations prevent Caddy instances from being used by malicious actors to reflect huge numbers of bogus ACME challenges against LetsEncryptâs servers; either the set of potential domains must be bounded (by an ask endpoint) or rate-limited (as it is for max_certs configurations).
So itâs not solve my issue.
Any why I can tell Caddy to insert the first part of the âmydomain.comâ only if the host is âmydomain.comâ?
I donât understand why he enter to this part if the user request other domain name?
Iâm making an assumption here that this issue only occurs when the client is requesting a new domain name. If thatâs the case, Iâd wager that the reason is Caddy decided itâs ineligible for a certificate request, and therefore must fall back on an existing certificate. Since all other certificates are equally invalid, it simply picks the first one available.
If my assumption isnât correct, it sounds like a bug.
I donât think thatâs the case, because this behaviour is intended. An incoming HTTPS request must have TLS negotiated first before the full request and response can be processed. If all certificates are equally invalid, and one must be provided, the first certificate will suffice. The alternative is to reject the connection, which does not allow for Caddy to serve otherwise valid content, or advise the client that the requested domain is not served.
Most of the traffic this days canât run without right certificate so there is no different.
I think itâs better to tell the user that something is broke and he need to fix it and not give him wrong behaviour that he will not understand what happen.
Caddy donât need to decide for the user anything. Take a look on my code, Iâm telling Caddy what certificate he need to set for every situation. Itâs very clear.
We agree that itâs better to tell the user whatâs wrong, I think.
Ultimately, serving the âwrongâ certificate makes it easier to identify problems such as, for example, when a domain isnât served at the address; rejecting a connection outright gives troubleshooters far less information, which is why the decision was made.
In your Caddyfile, there is no certificate specified in advance for https://*, so for a request for https://www.example.com - which falls under this site label, because there are no more specific site labels in the Caddyfile for it to match - Caddy must request one from LetsEncrypt. When it canât do this, we end up with the issue youâre running into.
So after a lot of checks the problem is not only with new domain, but also with existing domains that already have an SSL on the server.
So this is defiantly a bug. Caddy some time enter to the wrong SSL when there is my own SSL and LetsEncrypt SSL on the same Caddyfile.
Definitely a bug if thatâs the case. Go ahead and open up an issue at https://github.com/mholt/caddy/issues, fill out the template, and refer to this thread.
If you have time to narrow it down to the simplest possible reproducible Caddyfile, too, that will help speed up the process. Thanks!
Thatâs because there is no site in your Caddyfile that matches either of those domains. Wildcards only apply to a single label, so your https://* site, for example, will only match one label like localhost but not foo.local. So, remove the wildcard character.
