Configuring Caddy with Cloudflare DNS - The page isn’t redirecting properly

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

a. System environment:

Ubuntu 20.04 on Google Cloud Platform

b. Command:

sudo systemctl reload caddy

c. Service/unit/compose file:

I have not changed this 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:

# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace ":80" below with your
# domain name.
{
        acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
        acme_dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN}
        debug
}

hxfam.com {
        #tls {
        #       dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN}
        #}

        # Set this path to your site's directory.
        root * /var/www/html

        # 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 localhost:9000

        # Use 404.html
        handle_errors {
                @404 {
                        expression {http.error.status_code} == 404
                }
                rewrite @404 /404.html
                file_server
        }
}

3. The problem I’m having:

I am trying to access the URL “hxfam.com” without errors. Currently, I get the error “The page isn’t redirecting properly.” And if I look at more information, I see a Cloudflare SSL cert.

If I try to visit http://“IP-ADDRESS”, it redirects to https:// and I get a different error,

"SSL_ERROR_INTERNAL_ERROR_ALERT, Value:-12188, “Peer reports it experienced an internal error.”

And if I go to more information, it doesn’t appear to have any SSL certificate.

Steps I took to get here:

  1. Following How to use Caddy with Cloudflare's SSL settings (sammckenzie.be, route of “Using a lets-encrypt certificate” which is supposed to work with the cloudflare proxy)
  2. Setup DNS A records on cloudflare for hxfam.com and www.hxfam.com both pointing to the same IP
  3. Got a Cloudflare API token for Edit/Zone/DNS, and added it to root’s .bashrc
  4. Downloaded custom binary with cloudflare module included (had problems getting the correct download URL, and ended up downloading it locally, and using scp to get the correct binary on the server)
  5. sudo systemctl reload caddy

4. Error messages and/or full log output:

(assuming you would prefer word-wrap…)

● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-02-14 15:42:47 EST; 48min ago
Docs: Welcome — Caddy Documentation
Process: 498110 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile (code=exited, status=0/SUCCESS)
Main PID: 448450 (caddy)
Tasks: 8 (limit: 1117)
Memory: 11.0M
CGroup: /system.slice/caddy.service
└─448450 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.1256025,“logger”:“tls.obtain”,“msg”:“trying issuer 1/1”,“issuer”:“acme-staging-v02.api.letsencrypt.org-directory”}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.3538315,“logger”:“tls.issuance.acme.acme_client”,“msg”:“http request”,“method”:“HEAD”,“url”:“https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",“headers”:{“User-Agent”:["Caddy/2.4.6 CertMagic acmez (linux; amd64)”]},“response_headers”:{“Cache-Control”:[“public, max-age=0, no-cache”],“Date”:[“Mon, 14 Feb 2022 21:31:01 GMT”],“Link”:[“https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"”],“Replay-Nonce”:[“0001mBKttbVd7tdpn7driunQhNrNxShLF-BrVz_gl77-gpA”],“Server”:[“nginx”],“Strict-Transport-Security”:[“max-age=604800”],“X-Frame-Options”:[“DENY”]},“status_code”:200}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.439148,“logger”:“tls.issuance.acme.acme_client”,“msg”:“http request”,“method”:“POST”,“url”:“https://acme-staging-v02.api.letsencrypt.org/acme/new-order",“headers”:{“Content-Type”:[“application/jose+json”],“User-Agent”:["Caddy/2.4.6 CertMagic acmez (linux; amd64)”]},“response_headers”:{“Boulder-Requester”:[“44128408”],“Cache-Control”:[“public, max-age=0, no-cache”],“Content-Length”:[“345”],“Content-Type”:[“application/json”],“Date”:[“Mon, 14 Feb 2022 21:31:01 GMT”],“Link”:[“https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"”],“Location”:[“https://acme-staging-v02.api.letsencrypt.org/acme/order/44128408/1789824318"],“Replay-Nonce”:[“0002pY3Ev7smhWPv7nKUk87uGxR7TRFlgNfA8Af2q0wkBAo”],“Server”:[“nginx”],“Strict-Transport-Security”:[“max-age=604800”],“X-Frame-Options”:[“DENY”]},"status_code”:201}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.5023549,“logger”:“tls.issuance.acme.acme_client”,“msg”:“http request”,“method”:“POST”,“url”:“https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/1681697838",“headers”:{“Content-Type”:[“application/jose+json”],“User-Agent”:["Caddy/2.4.6 CertMagic acmez (linux; amd64)”]},“response_headers”:{“Boulder-Requester”:[“44128408”],“Cache-Control”:[“public, max-age=0, no-cache”],“Content-Length”:[“811”],“Content-Type”:[“application/json”],“Date”:[“Mon, 14 Feb 2022 21:31:01 GMT”],“Link”:[“https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"”],“Replay-Nonce”:[“0001c3EgJyLP6TKFPgmcoKIbfjx1W3gzxX8XKoA9keiDjUs”],“Server”:[“nginx”],“Strict-Transport-Security”:[“max-age=604800”],“X-Frame-Options”:[“DENY”]},“status_code”:200}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.5030363,“logger”:“tls.issuance.acme.acme_client”,“msg”:“no solver configured”,“challenge_type”:“tls-alpn-01”}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“info”,“ts”:1644874261.503075,“logger”:“tls.issuance.acme.acme_client”,“msg”:“trying to solve challenge”,“identifier”:“hxfam.com”,“challenge_type”:“dns-01”,“ca”:“https://acme-staging-v02.api.letsencrypt.org/directory”}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“error”,“ts”:1644874261.7373815,“logger”:“tls.issuance.acme.acme_client”,“msg”:“cleaning up solver”,“identifier”:“hxfam.com”,“challenge_type”:“dns-01”,“error”:“no memory of presenting a DNS record for hxfam.com (probably OK if presenting failed)”}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“debug”,“ts”:1644874261.80395,“logger”:“tls.issuance.acme.acme_client”,“msg”:“http request”,“method”:“POST”,“url”:“https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/1681697838",“headers”:{“Content-Type”:[“application/jose+json”],“User-Agent”:["Caddy/2.4.6 CertMagic acmez (linux; amd64)”]},“response_headers”:{“Boulder-Requester”:[“44128408”],“Cache-Control”:[“public, max-age=0, no-cache”],“Content-Length”:[“815”],“Content-Type”:[“application/json”],“Date”:[“Mon, 14 Feb 2022 21:31:01 GMT”],“Link”:[“https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"”],“Replay-Nonce”:[“0001J15__0dnnwYHRwA3UUF3iHpDtoSq5Kgflm6pZuD0icw”],“Server”:[“nginx”],“Strict-Transport-Security”:[“max-age=604800”],“X-Frame-Options”:[“DENY”]},“status_code”:200}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“error”,“ts”:1644874261.8043633,“logger”:“tls.obtain”,“msg”:“could not get certificate from issuer”,“identifier”:“hxfam.com”,“issuer”:“acme-staging-v02.api.letsencrypt.org-directory”,“error”:“[hxfam.com] solving challenges: presenting for challenge: adding temporary record for zone hxfam.com.: got error status: HTTP 400: [{Code:6003 Message:Invalid request headers}] (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/44128408/1789824318) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)”}
Feb 14 16:31:01 test-server caddy[448450]: {“level”:“error”,“ts”:1644874261.804441,“logger”:“tls.obtain”,“msg”:“will retry”,“error”:“[hxfam.com] Obtain: [hxfam.com] solving challenges: presenting for challenge: adding temporary record for zone hxfam.com.: got error status: HTTP 400: [{Code:6003 Message:Invalid request headers}] (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/44128408/1789824318) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)”,“attempt”:4,“retrying_in”:300,“elapsed”:302.93142396,“max_duration”:2592000}

5. What I already tried:

  1. Enabled staging ca to avoid rate limiting
  2. dig hxfam.com does not show the server’s IP address, but that is probably because of Cloudflare’s proxy
  3. Tried a new cloudflare API Token, this time without limiting the source IP address to just the IP of the server (allowing all IPs instead)

6. Links to relevant resources:

  1. Download Caddy
  2. How to use DNS provider modules in Caddy 2
  3. Global options (Caddyfile) — Caddy Documentation
  4. Modules - Caddy Documentation

Thank you in advance for your time in looking at this :slight_smile:

I think this is related: https://github.com/caddy-dns/cloudflare/issues/27
I hardcoded the API key in Caddy file (in lieu of the env variable) and I am getting different errors now:

● caddy.service - Caddy
     Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-02-14 16:59:10 EST; 3h 14min ago
       Docs: https://caddyserver.com/docs/
    Process: 64639 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile (code=exited, status=0/SUCCESS)
   Main PID: 631 (caddy)
      Tasks: 9 (limit: 1117)
     Memory: 38.4M
     CGroup: /system.slice/caddy.service
             └─631 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Feb 14 20:09:58 test-server caddy[631]: {"level":"info","ts":1644887398.0374749,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Feb 14 20:09:58 test-server caddy[631]: {"level":"info","ts":1644887398.0377753,"logger":"admin.api","msg":"load complete"}
Feb 14 20:09:58 test-server caddy[631]: {"level":"info","ts":1644887398.0385425,"logger":"admin","msg":"stopped previous server","address":"tcp/localhost:2019"}
Feb 14 20:09:58 test-server systemd[1]: Reloaded Caddy.
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.3213089,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"10.142.0.2"}
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.3213658,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","server_name":"","remote":"96.255.2.79:44230","identifier":"10.142.0.2","cipher_suites":[4865,4867,4866,49195,49199,52393,52392,49196,49200,49162,49161,49171,49172,156,157,47,53],"cert_cache_fill":0.0001,"load_if_necessary":true,"obtain_if_necessary":true,"on_demand":false}
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.3214371,"logger":"http.stdlib","msg":"http: TLS handshake error from 96.255.2.79:44230: no certificate available for '10.142.0.2'"}
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.439849,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"10.142.0.2"}
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.439904,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","server_name":"","remote":"96.255.2.79:44232","identifier":"10.142.0.2","cipher_suites":[4865,4867,4866,49195,49199,52393,52392,49196,49200,49162,49161,49171,49172,156,157,47,53],"cert_cache_fill":0.0001,"load_if_necessary":true,"obtain_if_necessary":true,"on_demand":false}
Feb 14 20:10:59 test-server caddy[631]: {"level":"debug","ts":1644887459.439971,"logger":"http.stdlib","msg":"http: TLS handshake error from 96.255.2.79:44232: no certificate available for '10.142.0.2'"}
1 Like

Those are not errors, actually, just debug level messages. Most of those “TLS handshake error” messages are usually from bots randomly hitting your server’s IP address trying to connect, but Caddy rejects them because they didn’t have your domain name in the TLS handshake’s SNI field.

Are actual requests working now?

1 Like

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