Caddy says my phplist app's subdomain doesn't qualify for certificate

1. Caddy version (caddy version):

Caddy 2.4.6

2. How I run Caddy:

I typically use ..

caddy start

but am having a devil of a time getting starting and enabling caddy as a service using restart and/or reload commands.

Suspect at this point I'm missing some serious basics in my Caddyfile.

a. System environment:

Debian 11.2/systemd

b. Command:

caddy fmt --overwrite    (This presumably formats my Caddyfile to readable spec)

caddy start

c. Service/unit/compose file:

# caddy.service
#
# For using Caddy with a config file.
#
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
#
# See https://caddyserver.com/docs/install for instructions.
#
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

# Set up global options
{
	debug
}

list.14servers.net {
	# Set this path to your site's directory.
	root * /var/www/phplist-3.6.6/public_html

	# Set up logging
	log {
		output file /var/log/caddy/list.14servers.net.access.log {
			roll_size 3MiB
			roll_keep 5
			roll_keep_for 48h
		}
		format console
	}

	# Set up compression
	encode gzip zstd

	# Set up PHP FastCGI
	php_fastcgi unix//run/php/php8.1-fpm.sock

	# Set up TLS Protocols
	tls {
		protocols tls1.2 tls1.3
	}

	# Enable static file server
	file_server

	# Set up reverse proxy
	#   reverse_proxy localhost:8080
}

3. The problem I’m having:

I have a domain - 14servers.net - at which I'd like to have 14 applications/servers at their own subdomain like:
app1.14servers.net
app2.14servers.net
 
I've currently pointed the DNS for the subdomain  list.14servers.net to point to the VPS hosting caddy and the phpLIST application.

I'd like to be able to have Caddy support 14 different servers at the same domain but identified by their sub-domain extension and enable HTTPS certificates for each.

Rather than using a site with multiple FQDNs (i.e. appN.14servers.net) perhaps caddy requires a wildcard for certificates?

4. Error messages and/or full log output:

caddy start
2021/12/29 23:10:30.964	INFO	using adjacent Caddyfile
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use
start: caddy process exited with error: exit status 1

root@ssdnodes-65240:/etc/caddy# ps -aux | grep 'caddy'
caddy      99948  0.0  0.0 228292 12200 ?        S    05:12   0:00 php-fpm: pool www
caddy      99949  0.0  0.0 228296 12200 ?        S    05:12   0:00 php-fpm: pool www
root      107579  0.0  0.2 738700 43148 pts/0    Sl   22:11   0:00 caddy run --pingback 127.0.0.1:41297
root      108047  0.0  0.0   6204   708 pts/0    S+   23:10   0:00 grep caddy

root@ssdnodes-65240:/etc/caddy# systemctl status caddy
â—Ź caddy.service - Caddy
     Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2021-12-29 05:45:55 UTC; 17h ago
       Docs: https://caddyserver.com/docs/
    Process: 100318 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile (code=exited, status=1/FAILURE)
   Main PID: 100318 (code=exited, status=1/FAILURE)
        CPU: 51ms

Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: HOME=/var/lib/caddy
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: LOGNAME=caddy
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: USER=caddy
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: INVOCATION_ID=e80019053ba04187ae4ee3ac6972f70b
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: JOURNAL_STREAM=8:636842
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: {"level":"info","ts":1640756755.2592242,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","con>
Dec 29 05:45:55 ssdnodes-65240 caddy[100318]: run: adapting config using caddyfile: subject does not qualify for certificate: '}'
Dec 29 05:45:55 ssdnodes-65240 systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Dec 29 05:45:55 ssdnodes-65240 systemd[1]: caddy.service: Failed with result 'exit-code'.
Dec 29 05:45:55 ssdnodes-65240 systemd[1]: Failed to start Caddy.

5. What I already tried:

Have gone through introductory tutorial and decided that for time being I'll use a Caddyfile rather than API for management.
That said, I've not been able to consistently get caddy to start, make changes to the Caddyfile, then restart caddy as a systemd service.

6. Links to relevant resources:

The easiest thing is to start from the apt installation, which automates all the steps needed to run Caddy as a service:

Yeah, basically it just cleans up the formatting for your Caddyfile, fixing whitespace issues etc.

This happened because there’s already an instance of Caddy, bound to port 2019. You can’t start two instances of Caddy (while using the default admin endpoint).

Make sure all Caddy processes other than the one started by systemd are stopped.

This tells me your Caddyfile must have a syntax error somewhere.

I’m not spotting the syntax issue with the Caddyfile you posted. Are you sure that’s the Caddyfile located at /etc/caddy/Caddyfile?

Also, please use the command outlined on this page in the docs to see your full logs, untruncated (notice the lines end with > because systemctl status doesn’t wrap the logs if they’re long):

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.