Probleme configuring second website on a caddy web server

Help
1

1. The problem I’m having:

I’m trying to run two sites on the same caddy server : domain01.com and subdomain.domain01.com

I’ve tested my DNS configuration separately and it works properly for both domain and subdomain.

Caddy is run by the caddy user of the caddy group.
The directories of both websites are configured exactly the same, including access, reader, write and execute permissions.

2. Error messages and/or full log output:

The first site, domain01.com, works properly both in HTML and PHP.
The second one, submdomain.domain01.com, return 403 for the index.html file et 404 for info.php

3. Caddy version: v2.7.6

4. How I installed and ran Caddy:

I followed the official Rocky Linux tutorial for caddy installation : Caddy Web Server - Documentation

a. System environment:

Rocky Linux 9.3

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

d. My complete Caddy config:

# The Caddyfile is an easy way to configure your Caddy web server.
#
# https://caddyserver.com/docs/caddyfile


# The configuration below serves a welcome page over HTTP on port 80.  To use
# your own domain name with automatic HTTPS, ensure your A/AAAA DNS record is
# pointing to this machine's public IP, then replace `http://` with your domain
# name.  Refer to the documentation for full instructions on the address
# specification.
#
# https://caddyserver.com/docs/caddyfile/concepts#addresses
# Domaine domain01.com
domain01.com {
	# Set this path to your site's directory.
	root * /srv/www/domain01.com/htdocs

	# Enable the static file server.
	file_server

	# Another common task is to set up a reverse proxy:
	# reverse_proxy localhost:8080

	# Or serve a PHP site through php-fpm:
	php_fastcgi 127.0.0.1:9000

	# Refer to the directive documentation for more options.
	# https://caddyserver.com/docs/caddyfile/directives
}

# Redirection www vers domain01.com nu
www.domain01.com {
	redir https://domain01.com{uri}
}

# domaine subdomain.domain01.com
subdomain.domain01.com {
	root * /srv/www/subdomain.domain01.com/htdocs
	file_server
	php_fastcgi 127.0.0.1:9000
	log { 
		output file /var/log/caddy/subdomain.domain01.log
	}
}

# As an alternative to editing the above site block, you can add your own site
# block files in the Caddyfile.d directory, and they will be included as long
# as they use the .caddyfile extension.
# import Caddyfile.d/*.caddyfile

5. Links to relevant resources:

2

Check the file/directory permissions. Make sure the caddy user can read those files.

Show ls -la for /srv/www/subdomain.domain01.com and /srv/www/subdomain.domain01.com/htdocs.

3

Here are the results :

[rocky@vps ~]$ ls -la /srv/www/subdomain.domain01.com
total 0
drwxr-xr-x. 3 caddy caddy    20 Feb  6 19:51 .
drwxrwxr-x. 4 rocky sftpteam 54 Feb  7 04:16 ..
drwxr-xr-x. 2 caddy caddy    67 Feb 12 22:14 htdocs


[rocky@vps ~]$ ls -la /srv/www/subdomain.domain01.com/htdocs
total 164
drwxr-xr-x. 2 caddy caddy     67 Feb 12 22:14 .
drwxr-xr-x. 3 caddy caddy     20 Feb  6 19:51 ..
-rw-r--r--. 1 caddy caddy     13 Feb 12 22:14 index.html
-rw-r--r--. 1 caddy caddy     20 Feb 12 22:14 info.php
4

Hmm, that does seem fine.

Add this to the top of your Caddyfile:

{
	debug
}

Then make a request with curl -v, show that output, then show your Caddy logs (the command to use to see your logs can be found here Keep Caddy Running — Caddy Documentation)

Does Rocky Linux have SELinux enabled? Maybe there’s some SELinux rule preventing access of those files?

5

Here is the results :

[rocky@vps ~]$ curl -v subdomain.domain01.com
*   Trying 111.22.33.44:80...
* Connected to subdomain.domain01.com (111.22.33.44) port 80 (#0)
> GET / HTTP/1.1
> Host: subdomain.domain01.com
> User-Agent: curl/7.76.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://subdomain.domain01.com/
< Server: Caddy
< Date: Tue, 13 Feb 2024 12:26:39 GMT
< Content-Length: 0
<
* Closing connection 0

The log show :

{"level":"info","ts":1707827199.2037675,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"111.22.333.44","remote_port":"40896","client_ip":"111.22.333.44","proto":"HTTP/1.1","method":"GET","host":"subdomain.domain01.com","uri":"/","headers":{"User-Agent":["curl/7.76.1"],"Accept":["*/*"]}},"bytes_read":0,"user_id":"","duration":0.00003663,"size":0,"status":308,"resp_headers":{"Content-Type":[],"Server":["Caddy"],"Connection":["close"],"Location":["https://subdomain.domain01.com/"]}}

and :

[rocky@vps ~]$ journalctl -u caddy --no-pager | less +G
ort":443,"Zone":""}}}}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.545008,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"mail2.vrnao.info"}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.5450168,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.vrnao.info"}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.5450208,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*.info"}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.5450249,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*.*"}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.5450325,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"162.0.231.109","remote_port":"40986","server_name":"mail2.vrnao.info","remote":"162.0.231.109:40986","identifier":"mail2.vrnao.info","cipher_suites":[52392,52393,49199,49200,49195,49196,49171,49161,49172,49162,156,157,47,53,49170,10],"cert_cache_fill":0.0003,"load_or_obtain_if_necessary":true,"on_demand":false}
Feb 13 12:26:37 vps-abcdefgh.net caddy[341324]: {"level":"debug","ts":1707827197.545111,"logger":"http.stdlib","msg":"http: TLS handshake error from 162.0.231.109:40986: no certificate available for 'mail2.vrnao.info'"}

Yes SELinux is enabled…

6

That’s an HTTP request, so it just serves the HTTP->HTTPS redirect (the Location header is a redirect). Try curl -v https://subdomain.domain01.com instead.

Then it’s quite possible SELinux rules are blocking access to the files.

You could go through these steps to debug SELinux issues:

7

Before I read your answer I tried to disabled SELinux and then my both site works fine.

So probably it comes from SELinux,

Thanks for your help !

1 Like
8

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