Letsencrypt and wildcard certs

Hi there. So, Letsencrypt has announced the availability of wildcard certificates. How to, on Caddy? Is it possible?

1 Like

In progress!

If you’re grateful for lego, you can donate to Sebastian, its developer: https://beerpay.io/xenolf/lego

5 Likes

Pull request is now available, so try it out! https://github.com/mholt/caddy/pull/2072

3 Likes

How can I do that? I don’t compile my own caddy. :slight_smile:

On the PR, you say the usage is:

*.example.com
tls {
    dns <provider>
}

My DNS provider is Google Domains, which isn’t listed. What are my options?

If you are interested in trying it out, you will need to compile it. It’s not too complicated, but you need Go installed: Download and install - The Go Programming Language

Then:

  1. go get github.com/mholt/caddy github.com/caddyserver/builds
  2. cd $(go env GOPATH)/src/github.com/mholt/caddy/caddy
  3. git checkout acmev2
  4. go run build.go

A Caddy binary should then be dropped in your current directory, built from the branch used for the above PR.

Your only option is to use a supported provider, I’m afraid. Cloudflare is free and their DNS service is excellent; their scanning process can help automate moving DNS records across. You could also get yourself a short-term dot.tk address and point it at Cloudflare as a new domain just for testing this.

2 Likes

Google Domains doesn’t have an API, so the DNS challenge can’t be automated with them. Put in a feature request with Google and wait, or switch DNS providers.

When you try the branch, be sure to plug in your DNS provider in run.go.

2 Likes

I see. I can manage a compile, no problem. My problem will then be the DNS portion. I am not willing to let go Google, they are simply too good. :frowning: Oh well, no wildcards for me.

Whoops, forgot to mention this part - super important! :sweat_smile:

That’s sad to hear about Google not having an API. Hope that changes in future.

Ahh, my bad - anyway, maybe the instructions will be useful for anyone else interested.

Is there a reason why wildcard certificates must use a DNS challenge? Can it be done a different way (similar to the way it is currently implemented for single certificates)?

See Wildcard certificates via http-01 - Issuance Policy - Let's Encrypt Community Support

1 Like

I see. Sad, especially because of this (emphasis mine):

It’s definitely not simpler, because not every DNS provider has an API for making changes and there is no standard for such API

1 Like

There actually is: RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE)

Dynamic Updates in the Domain Name System (DNS UPDATE)

And Caddy even supports it! It’s just that DNS is terrible almost all around and almost no one supports it. But some of the best DNS I’ve seen is through Cloudflare and DNSimple.

1 Like

If I try:

go get github.com/mholt/caddy github.com/caddyserver/builds
cd $(go env GOPATH)/src/github.com/mholt/caddy/caddy
git checkout acmev2
go run build.go

I get:

error: pathspec 'acmev2' did not match any file(s) known to git.
caddymain/run.go:38:2: code in directory /home/pp/go/src/github.com/wmark/caddy.upload expects import "blitznote.com/src/caddy.upload"
2018/03/18 11:39:39 exit status 1
exit status 1

It looks like the git checkout failed, but you continued to run go build:thinking: make sure you checkout the remote acmev2 branch. (Might have to do a git fetch first? Or I think -b is needed in checkout…)

go get -u github.com/mholt/caddy github.com/caddyserver/builds should fetch everything new, I think.

1 Like

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