New to Let’s Encrypt and Caddy, Must be missing a step

Help
1

My domain is: kevinfries.com

I ran this command: curl -v www.kevinfries.com

It produced this output:

➜ wiki curl -v https://www.kevinfries.com

  • Host www.kevinfries.com:443 was resolved.
  • IPv6: (none)
  • IPv4: 74.50.144.219
  • Trying 74.50.144.219:443...
  • Connected to www.kevinfries.com (74.50.144.219) port 443
  • ALPN: curl offers h2,http/1.1
  • (304) (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/cert.pem
  • CApath: none
  • LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error
  • Closing connection
    curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error

My web server is (include version): Caddy

The operating system my web server runs on is (include version): macOS - Sonoma

My hosting provider, if applicable, is: None, its on my Mac Mini M1

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Trying to get it to update via Caddy

——-

OK, I think I am missing a step here and could use some help figuring out where that missed step is.

I have Caddy configured and working just fine, without SSL. Leaving everything on HTTP, and using port 80, I can:

Perfect. Next I change my config to instead of listening on 80, it has my domain name. This is what most of the documentation at Caddy says.

When I do a caddy validate, it says everything is valid. Though the 4th line seems like it is trying to tell me something, but googling is not helping. It then tells me that it started then stopped certificate maintenance. Here is the output:

2024/06/05 23:01:16.051 INFO using adjacent Caddyfile
2024/06/05 23:01:16.051 INFO using config from file {"file": "Caddyfile"}
2024/06/05 23:01:16.052 INFO adapted config to JSON {"adapter": "caddyfile"}
2024/06/05 23:01:16.053 INFO http.auto_https server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2024/06/05 23:01:16.053 INFO http.auto_https enabling automatic HTTP->HTTPS redirects {"server_name": "srv0"}
2024/06/05 23:01:16.053 INFO tls.cache.maintenance started background certificate maintenance {"cache": "0x14000693580"}
2024/06/05 23:01:16.054 INFO tls.cache.maintenance stopped background certificate maintenance {"cache": "0x14000693580"}
Valid configuration

So I do a “brew services restart caddy” and I see the following:

Stopping caddy... (might take a while)
==> Successfully stopped caddy (label: homebrew.mxcl.caddy)
==> Successfully started caddy (label: homebrew.mxcl.caddy)

If I do an NMAP on my domain, I see only 22, 80, and 443 open… PERFECT

I tried to hit the site with a web browser to no success. So, I fell back to a good old fashion curl:

➜ wiki curl -v http://www.kevinfries.com

GET / HTTP/1.1
Host: www.kevinfries.com
User-Agent: curl/8.6.0
Accept: /

< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://www.kevinfries.com/
< Server: Caddy
< Date: Wed, 05 Jun 2024 23:22:12 GMT
< Content-Length: 0
<

  • Closing connection
    ➜ wiki curl -v https://www.kevinfries.com
  • Host www.kevinfries.com:443 was resolved.
  • IPv6: (none)
  • IPv4: 74.50.144.219
  • Trying 74.50.144.219:443...
  • Connected to www.kevinfries.com (74.50.144.219) port 443
  • ALPN: curl offers h2,http/1.1
  • (304) (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/cert.pem
  • CApath: none
  • LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error
  • Closing connection
    curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal error

Access on http properly does a HTTP-308 redirection to https, then https is not validly handling the handshake. It also looks like it is trying to use my system wide certificates, instead of anything from Let’s Encrypt.

Next I went to Let’s Debug, Tried to see if it could shed some light on things:

HTTP-01 complained that this did not work, and I suspect that this is correct, as it got a 308 redirect.

DNS-01 and TLS-ALPN-01 both said everything was good.

So, I think I am close, very close, but I have missed a step with all this bouncing between the Let’s Encrypt and Caddy websites. I was expecting that I needed to do more on this site, then reference it in my Caddyfile, but can not find simple, straightforward instructions on what that may be.

Anyone else see something like I am seeing, and can shed light on what I missed?

2

Check out what letsdebug has to say about your domain: Let's Debug

It appears that you're serving 308 redirects from HTTP to HTTPS, but then failing to actually service those HTTPS requests. Perhaps because you don't have a certificate on disk yet, and caddy (appropriately) isn't able to do a TLS handshake with no cert available yet?

2 Likes
3

Yea, I am seeing a Catch-22 situation going on here. I figure there is something I am missing. If I use the DNS-01, it is not Caddy is not redirecting, but sending a HTTP-308 assuming the browser will follow. The TLS-ALPN-01 requires a ssl connection to get the config to make the SSL connection. So until this works, it looks like this won’t work. The DNS-01 requires a custom build, which is not available on macOS. Homebrew does not work well for this model, it assumes programs use installable plugins, not custom builds with plugins to provide optional functionality in code. It is starting to look like I am going to have to maybe ditch Caddy, and go with NGinx or Apache. Which is too bad, because Caddy has a ton of really fantastic features in a low footprint, perfect for a small development setup like mine. But this could be a deal breaker. Hoping somebody is seeing something I missed, and can help me figure out what I did wrong.

4

We don't see Caddy that much on this forum. I certainly don't have any direct experience with it. Still, someone else here may know and be willing to help.

Have you tried asking on the Caddy forum? They would be more familiar with the proper configuration on that platform. https://caddy.community/

I thought Caddy supported TLS-ALPN although as noted I don't know how to configure it for that.

I also think Caddy should be intercepting an HTTP Challenge on port 80 and there shouldn't be any redirect. Maybe when poking it with test challenges but not for actual cert acquisition.

Wish I could be more help but I think the Caddy community probably better place for help at this stage.

5 Likes
5

That's probably correct, but @kfries63, sharing your Caddyfile (along with the version of Caddy you're running--caddy version will tell you) might help point to what's going wrong.

5 Likes
6

What are your full, unredacted Caddy logs? What is your Caddy config? What Caddy version are you using? A lot of basic information is missing making our guess only as good as yours. Debugging a server only from the client side is futile. We need insights into the server, not clients.

Here's a help template from our forum to guide you:

## 1. The problem I'm having:
<!-- What are you trying to do? What isn't working?
Please describe the issue thoroughly enough so that
anyone can reproduce the exact behavior you're
seeing. Be as specific as possible. Use `curl -vL`
to show example requests. DO NOT USE WEB
BROWSERS HERE. Browsers have subtle caching
behaviours which can make testing difficult. -->




## 2. Error messages and/or full log output:
<!--
Please DO NOT REDACT any information except credentials. Leave domain names intact!
Please DO NOT POST TRUNCATED LOG LINES as systemd is notorious for this.
Please USE THIS COMMAND TO VIEW LOGS with systemd:
    $ journalctl -u caddy --no-pager | less +G`
Please DO NOT USE WEB BROWSERS. Use `curl -vL` instead.
Please ENABLE DEBUG MODE FIRST by adding "debug" to the global options of your Caddyfile. See https://caddyserver.com/docs/caddyfile/options#debug for an example.
-->


## 3. Caddy version:
<!--
If you installed Caddy as a Linux package, run `caddy version`.
If you're running Caddy with Docker Compose, run `docker-compose exec caddy caddy version`.
DO NOT say "latest" or "v2", as this is not a specific version.
Please check that you're already running the latest version listed at https://github.com/caddyserver/caddy/releases, since your issue might have already been fixed in a previous release.
-->




## 4. How I installed and ran Caddy:
<!--
Please provide all of the relevant information and
**DO NOT REDACT** anything except credentials.
This is a rule. We cannot help you otherwise! Your
exact domain names (etc.) are significant. Thank you!
We recommend using one of the official installation
methods found at https://caddyserver.com/docs/install.
-->

### a. System environment:
<!-- OS, architecture, relevant versions, systemd? Docker? etc. -->




### b. Command:
<!--
Commands are what you type into a terminal, i.e. the
command you use to run Caddy.
Please read https://caddyserver.com/docs/running to
understand the recommended commands to run Caddy,
depending on your installation method.
-->



### c. Service/unit/compose file:
<!--
If using Docker/systemd/Kubernetes/make etc.
Delete the code block below if not relevant.
-->



### d. My complete Caddy config:
<!--
DO NOT REDACT anything except credentials.
LEAVE DOMAIN NAMES INTACT.
If using the Caddyfile:
  - Please use `caddy fmt` to make your config more legible.
  - Review https://caddyserver.com/docs/caddyfile/concepts#structure
-->



### 5. Links to relevant resources:
<!-- Optional, but can help get us on the same page quickly. -->
5 Likes
7

@kfries63

Just want to mention that @mholt is the author of Caddy, so you're in good hands.

4 Likes
8 
➜  caddy version
v2.8.1 h1:UVWB6J5f/GwHPyvdTrm0uM7YhfaWb4Ztdrp/z6ROHsM=
➜ cat Caddyfile
*.kevinfries.com {
	@git header Host git.*
	@www header Host www.*
	@wiki header Host wiki.*

	handle @git {
		reverse_proxy 127.0.0.1:3000
	}

	handle @www {
		root * /var/www/homepage
		file_server
	}

	handle @wiki {
		encode gzip zstd
		root * /var/www/wiki

		try_files {path} {path}/index.html

		route {
			handle_path /_media/* {
				rewrite * /lib/exe/fetch.php?media={path}&{query}
			}
			handle_path /_detail/* {
				rewrite * /lib/exe/detail.php?media={path}&{query}
			}
			handle /_export/* {
				@export path_regexp export ^/_export/([^/]+)/(.*)
				rewrite @export /doku.php?do=export_{re.export.1}&{query}&id={re.export.2}
			}
			handle / {
				rewrite * /doku.php?{query}
			}
			try_files {path} /doku.php?id={path}&{query}
		}

		file_server
		php_fastcgi 127.0.0.1:9000
	}

	handle {
		redir http://www.{host}{uri}
	}
}
➜

But if I change the first line of the config to:

:80 {

Everything works without TLS. Before adding real content, I wanted to get the TLS working first

1 Like
9

In case you did not pick up from previous posts, this is on a Mac Mini M1, with the package installed from HomeBrew. The Caddyfile is located at: /opt/homebrew/etc and the brew package does not include xcaddy to recompile the executable. I have not switched this back to the working version so that all errors can be seen. But the URLs served by this server are:

Thank you for the help

1 Like
10

Ah. That's your problem right there... not a valid domain. Simply replace with kevinfries.com assuming that's your domain name. (Remove the leading dot.)

Haven't looked at the rest of the config thoroughly but that immediately stood out.

Also, be sure to upgrade to Caddy v2.8.4.

Edit: If you have multiple hostnames, you can either enumerate them:

kevinfries.com, www.kevinfries.com, ... {

But this will reach LE rate limits after about 10 subdomains I think. Or you can use a single wildcard:

*.kevinfries.com {

But this requires the DNS challenge.

4 Likes
11

OK, I don’t think it showed well in the copy paste, but I did have it as a wildcard as you suggested, not simply a period. Removing the wildcard and just leaving the base domain did not work, but when I listed all the domains on that first line… Perfection! Thank you. Caddy really is an awesome product for a small one man shop looking to do a little side hustle work with a single server. Fantastic work @mholt

3 Likes
12

Great! Glad it's working now. Thanks for your comments.

I recommend using the DNS challenge with a wildcard cert if your threat model allows for it and if you expect to have more subdomains in the future.

May Caddy serve you well :lock:

5 Likes
13

It's 100, but still, the wildcard will work.

You can combine multiple hostnames into a single certificate, up to a limit of 100 Names per Certificate. For performance and reliability reasons, it’s better to use fewer names per certificate whenever you can.

4 Likes
14

Ah right, thanks. Numbers are hard for me.

4 Likes
15

No worries. ChatGPT can't count the number of r's in "strawberry" after repeated efforts and attempts at training, so don't feel bad. :grin:

4 Likes
16

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