1. The problem I’m having:
I want to use the same Caddyfile for several physical servers and the servers hostname should be part of one of the Site blocks. Since every physical server has a different hostname, I thought I want to use {system.hostname}.example.com {
but I get the below error.
The page Conventions — Caddy Documentation says “The following placeholders are always available:” and also lists {system.hostname}
.
2. Error messages and/or full log output:
$ ./caddy run
2023/07/25 15:13:25.557 INFO using adjacent Caddyfile
Error: adapting config using caddyfile: subject does not qualify for certificate: '{system.hostname}.arm.stbu.net'
3. Caddy version:
v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=
4. How I installed and ran Caddy:
Downloaded from Download Caddy with two extra features:
github.com/caddyserver/transform-encoder
github.com/ueffel/caddy-tls-format
a. System environment:
- Oracle Linux 8.8
Linux instance-20221129-1409 5.15.0-102.110.5.1.el8uek.aarch64 #2 SMP Sat Jun 10 18:23:55 PDT 2023 aarch64 aarch64 aarch64 GNU/Linux
b. Command:
./caddy run
2023/07/25 15:13:25.557 INFO using adjacent Caddyfile
Error: adapting config using caddyfile: subject does not qualify for certificate: '{system.hostname}.arm.stbu.net'
c. Service/unit/compose file:
not applicable
d. My complete Caddy config:
{
http_port 18080
https_port 18443
# local_certs
skip_install_trust
debug
}
localhost:18080, localhost:18443, {system.hostname}.arm.stbu.net {
# This would work:
##localhost:18080, localhost:18443, {$HOSTNAME}.arm.stbu.net {
log
respond "Welcome"
}
Since {$HOSTNAME}.example.com
would be working, I think this is a bug and I can file an Issue at Github - unless this is done intentionally. If I enable local_certs
it would be working with {system.hostname}.example.com
as well. For me, it looks like the validation whether a site block name qualifies for public certificates should try to resolve {system.hostname}
first, just like “local_certs”.