Feedback on Caddyfile

I am not having any issues and caddy is running very smooth. Therefore not filling up the help template. I just need feedback on my caddyfile and if there is something need be done to improve it.

    storage file_system /var/www/caddy
    admin off
    acme_dns cloudflare redacted
    on_demand_tls {
        interval 2m
        burst    5

https:// {
    tls {

    root * /var/www/{host}/htdocs/
    php_fastcgi unix//run/php/php-fpm.sock

    file_server {
		precompressed br

    encode gzip

    header {
        Cache-Control "max-age=14400"
        Referrer-Policy "strict-origin-when-cross-origin"
        Permissions-Policy "interest-cohort=()"
        Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
        X-Content-Type-Options "nosniff"
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    @cache {
	not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
	not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
	not method POST
	not expression {query} != ''

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}

    @disallowed {
        path /xmlrpc.php
        path *.sql
        path *.zip
        path *.tar
        path *.bak
        path /wp-content/uploads/*.php

    rewrite @disallowed '/index.php'

I am not using any endpoint to verify ondemand tls urls as we generate tls cert over cloudflare dns and port 80 is blocked. Traffic must come to the site through cloudflare proxy as only cloudflare ips are whitelisted in the firewall. Admin api is off as we don’t see us making any change to the config for a long time to come and graceful reload is not required.

  1. Is there a way to encrypt and store the cloudflare access key in the caddyfile?

Thank you!

No feedback?

That’s not a good reason not to fill the template. It’s necessary for us to understand the context of how you’re running Caddy (Caddy version, how you installed it, your OS/arch, etc) so that we can most accurately comment on it.

That’s strange. Why not use the default storage location?

There’s no way to encrypt it, but you can use environment variables to feed it to your config, using a placeholder like {env.CLOUDFLARE_API_TOKEN} to pull it from env vars.

There’s no benefit to removing the Server header. It doesn’t reveal any secret information. If it could be used in some way do some exploit, we wouldn’t include the header in the first place. But there is no risk, so there’s no reason to remove it.

Do you mean that all domains you use are ones you control in your CloudFlare account?

I still strongly recommend using an ask endpoint. If someone does manage to connect directly to your server directly by IP address (which is definitely possible if your server is publicly accessible, without somekind of tunnel), they can exploit On-Demand TLS to cause your server to issue an infinite amount of certificates, filling up your storage.

It seems like you’re setting up static sites in /var/www/{host} for each domain you want to support, so you could make a simple site with a file matcher that the ask endpoint could hit to check for permission to issue a cert:

	on_demand_tls {
		ask http://localhost:8000

:8000 {
	root * /var/www
	@domain-exists file /{query.domain}
	respond @domain-exists 200
	respond 400

The file matcher (paired with root) will check if a directory exists at /var/www/{query.domain}, which should if you set up a site for it. So simply having the directory would allow the cert to be issued.

1 Like

Okay. I am sorry. I am running on latest Caddy 2.6.2. I use a script to download the latest caddy binary with cloudflare plugin included from your website, create caddy user, systemd service, checks and restart. I am using Debian sid x86-64 and aarch64.

Yes. I have switched back to the default location. I am syncing the whole www folder across clusters. I thought I’ll put it there so certs will get synced but keeping these files where PHP can modify them is risky. So I have switched back to default caddy location and syncthing from there.


You are right. Server header showing now.


You are a genius. Never thought could use something like this to verify. I am implementing it now.

Thank you very much! You were very helpful. Never thought I’ll receive such well thought answer. Keep up the great job!

1 Like

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