Wildcard certificates, building from scratch and what Caddy is all about

[foogle]

Just some feedback:

For me the absolute core appeal of Caddy is the instant, zero config certificates.

I just realised after many hours of trying to get wildcards going that Caddy is the opposite of this when implementing Wildcards with dns verification.

For some reason Wildcard certificates require not only lots of arcane config and digging through spare documentation and trying to piece a solution together.

I suddenly realised “Hey, when it comes to wildcards, Caddy requires me to compile from scratch, that’s hard and less automatic and not zero config and worse than nginx!”

I wondered why wildcards aren’t built in for common providers.

Then I realised the core value, the core selling point, of Caddy is gone, if you are doing wildcards - it’s back to pain city, like nginx.

[matt (Matt Holt)]

Thanks for the feedback.

A couple quick answers:

@foogle

I wondered why wildcards aren’t built in for common providers.

Because we’re trying to avoid converging the Internet onto a centralized ecosystem.

@foogle

Hey, when it comes to wildcards, Caddy requires me to compile from scratch

That’s definitely not the case.

I’m sorry you had a frustrating experience. But… are you sure you read our docs though? And even looked at our website? Because I think your frustrations would have been quickly appeased.

I’ll show you how to use wildcard certificates with Caddy easily, up and running in 5 minutes (modulo any delays outside of Caddy such as setting up a system service or getting credentials from your DNS provider). Here’s all you have to do:

1. Go to Caddy’s download page.
2. Choose your OS, arch, and the plugin corresponding to your DNS provider. (You can type its name to filter quickly.)
3. Click Download. You now have a Caddy binary that supports the DNS challenge without you “compiling from scratch.” Booyah.
4. Then make a Caddyfile that resembles something as simple as this:

{
    acme_dns cloudflare abcdef1234topsecret
}

*.example.com {
    respond "This is actually easy!"
}

5. Run Caddy, et voilà! You have a wildcard certificate.

You can find these instructions in our #1 most popular wiki article:

How to use DNS provider modules in Caddy 2

Caddy 2 uses a new and improved DNS provider interface for solving the ACME DNS challenge. All you have to do is plug the service provider(s) you need into your build, then add the DNS challenge to your configuration! Getting a DNS provider plugin How you choose to get a custom Caddy build is up to you; we’ll describe two common methods here. Method 1: Go to the Caddy download page. Find your DNS provider in the list of modules (dns.providers.*) and select it. Download your custom Caddy …

Our documentation also explains the DNS challenge.

@foogle

that’s hard and less automatic and not zero config

PS. Caddy never claims to be “zero config” except for the most basic quick-n-dirty deployments; if you need anything custom – especially anything dealing with sensitive credentials – of course you will have config for any program/system. It can’t read your mind, after all.

[francislavoie]

@matt

Because we’re trying to avoid converging the Internet onto a centralized ecosystem.

To add onto this – bundling DNS plugins would significantly increase the size of the resulting binary, and significantly increase the amount of third-party code being shipped, increasing the amount of risk for vulnerabilities, etc. We don’t have the resources to vet all DNS plugins as a whole such that we can bundle them.

Caddy was designed to be very pluggable, and like Matt said, it’s really easy to fetch a binary or use our xcaddy tool to compile it on your own machine (literally just download Go, put it in your PATH, download xcaddy, run it, done). Embrace pluggability, it’s a huge advantage.

[foogle]

Well I stand corrected - thanks for the comprehensive answer.

I will say it’s not clear at all that a page that lists modules Download Caddy is in fact a page of fully working Caddy product binaries. I looked at that page but I’m really not up for compiling/building software to make something work, so I ignored it after that. It says at the top “Only choose plugins you need and trust”, which says to me I am looking at a page of plugins, not a page of working complete binaries.

If it said at the top of that page “This page contains fully working, ready to run, Caddy binaries, each with an additional plugin fully built and working to make it easy for you”. Then it would (I hope) have been clear to me what I was looking at.

are you sure you read our docs though? And even looked at our website?

extensively, over and over and also third party documents. Everything talks about “plugins” and “building” when it comes to wildcard certs. Based on this it seems reasonable to assume that I’m going to have to somehow work out Caddy’s plugin system and get it custom built.

You can find these instructions in our #1 most popular wiki article:

Method one says:
“Download your custom Caddy build.”
And I’m sorry, but that wording says to me I’m in the territory of custom builds and plugins, not batteries included binaries, and I just switched off thinking that it might in fact be exactly what I am looking for. “Download your custom Caddy build.” says to me that more work is coming. “Custom” means not complete, some assembly required, I’m going to have to figure this thing out.

Method two says:

1. Build caddy with your DNS provider plugged in . This is a single xcaddy command:
   xcaddy build --with github.com/caddy-dns/REPOSITORY

But again I really don’t want to build stuff - I am experienced developer and I know the moment we start with custom builds then theres a long todo list to install this and that and things don’t work and it takes hours for an uncertain outcome unless you are a core developer of the project you are trying to build.

Honestly your 1/2/3/4 instructions above in this comment thread are far more clear than anything I’ve read on the topic. Those instructions literally saved me 3 hours work or more.

to address the comments of FrancisLavoie:

(literally just download Go, put it in your PATH, download xcaddy , run it, done)
Francis - it sounds easy to you but all over the web are “simple” “just do a custom build it’s super easy” instructions for all sorts of projects, and they very, very rarely result in anything but hours of trying to work out why it’s not working. That’s invisible to you as an experienced Go developer. Also, custom builds mean it’s hard to reproduce when putting things into production. It’s much easier if there is simply a binary that works.

bundling DNS plugins would significantly increase the size of the resulting binary, and significantly increase the amount of third-party code being shipped, increasing the amount of risk for vulnerabilities, etc. We don’t have the resources to vet all DNS plugins as a whole such that we can bundle them.

I appreciate what you are saying, but people like me just want things to work, without hours of stuffing around problem solving. Maybe you could provide a recommended binary with the core product and a “less recommended” binary that compiles all the extras in - then it’s up to me to take the risk and use the disk space - which I would gladly do to avoid custom builds and plugins. Ubuntu does this with it’s “nginx-extras” package.

Caddy never claims to be “zero config” except for the most basic quick-n-dirty deployments

Maybe, but automatic HTTPS is a key selling point whenever Caddy is discussed - it’s in the first line of your website: " Caddy 2 is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go". And much of the commentary on the Internet is about how the automatic certificates fix a massive pain point.

Look guys I don’t want to criticise - it’s great work - a great product and you’re doing it for free so thankyou.

All I’m saying is that people like me love stuff that instantly works with zero config - plugins make for complexity and config.

My final comment is to ask the question … why are plugins needed for the 5 most common ways of doing something? For example why would the five most common ways of doing wildcards (Cloudflare/Google/AWS/Godaddt or whatever) - why would they not be built in - why is a plugin needed for the most popular use cases?

I appreciate the replies thanks.

BTW this should be your documentation on Wildcard certs:

[foogle]

Also, I started out trying to implement Wildcards with Google DNS.

Does Google DNS work? I was reading how it’s not supported because there is no API but I think that’s wrong - there’s is Google Domains (which has no API) and Google DNS (which has a powerful API). They are (confusingly) separate Google services.

I gave up in the end and switched to Cloudflare.

[foogle]

Here’s an example of why I have made such assumptions, in a blog post from 2021 (recent):

“Because the DNS plugins aren’t built into the main Caddy executable, you need to compile it with the plugins you want installed.”

Building Caddy v2 with CloudFlare DNS Support

[foogle]

And to be clear - thanks greatly to the team for creating such an excellent product - I have been evangelising Caddy to anyone who will listen.