Just started with caddy… I setup basic file like so:
site1.example.com { root path1}
site2.example.com { root path2}
*.example.com {
root path3
tls { max_certs 10 }
}
TLS works great for the first two sites… but for some reason, any other site such as siteX.example.com, gets the same cert as site1!
Anything I forgot to do, in other for on-demand TLS to work?
version is: 0.10.3
Thank you!
This is probably only tangentially related to your problem, but Let’s Encrypt doesn’t support wildcard certificates.
That’s strange. What’s in the process log? (the one from the -log flag)
This is true, which is why, when using * in a site name, on-demand TLS is needed.
(edit: as the docs say, be sure to use Let’s Encrypt’s staging endpoint while you’re testing this)
It does not seem like there is any debug/warning/errors being logged… but let me ask first…
*.example.com {
root path3
tls { max_certs 10 }
}
That config does not mean: automatically create and sign certs for any requested domain, under example.com… it means: Create and sign a cert for the wildcard name of *.example.com???
That configuration means that Caddy will serve sites of any subdomain to example.com and will obtain certificates for up to 10 of the first hostnames that are requested.
What is the full log output?
Thanks!
I added some more sites to my config, but the issue is still that the wildcard sites never seem to get their own cert, and instead they work, but use the cert of the first listed site in the config.
Config:
…
https://catholic.edu {
import defaults
redir http://www.catholic.edu
}
*.cua.edu {
import defaults
tls { max_certs 10 }
root /var/www/wildcard
}
defaults:
log / /var/log/caddy/access.log “{hostonly} {remote} - {user} [{when}] "{method} {uri} {proto}" {status} {size}” {
rotate_size 100
rotate_age 90
rotate_keep 50
}
My start command is: ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp/caddy
The journal output is:
Jun 24 19:39:50 ip-10-0-0-62 systemd[1]: Stopping Caddy HTTP/2 web server…
Jun 24 19:39:50 ip-10-0-0-62 systemd[1]: Started Caddy HTTP/2 web server.
Jun 24 19:39:50 ip-10-0-0-62 systemd[1]: Starting Caddy HTTP/2 web server…
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: Activating privacy features… done.
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: https://popeindc.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 https://popeindc.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: https://honoringmary.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 https://honoringmary.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: https://cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 https://cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: https://law.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 https://law.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: https://.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 https://.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://law.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://law.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://catholic.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://catholic.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://popeindc.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://popeindc.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://honoringmary.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://honoringmary.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: http://.cua.edu
Jun 24 19:39:50 ip-10-0-0-62 caddy[21612]: 2017/06/24 19:39:50 http://.cua.edu
Test for example:
MacBook-Pro :: ~ » curl --resolve test3.cua.edu:443:34.205.150.248 --resolve test3.cua.edu:80:34.205.150.248 http://test3.cua.edu -kiv -L
This works, but the cert presented is:
I was able to reproduce your problem using curl only, but not the browser. It turns out the reason is that curl is not sending the Server Name Indicator (SNI) field in the TLS handshake, and with a blank server name, Caddy just serves the “default” (or first) certificate, like other web servers do in this situation (although there is a related open issue about it). On macOS at least, curl does not set SNI when using -k or --insecure.
Using a browser like Chrome, which properly sends the server name in SNI, the right certificate was served.
So, everything works. 
I think this would be the first time I’ve seen “cURL does something weird, use a browser instead”. Usually it’s the other way around!
Thank you!!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.