Letsencrypt and wildcard certs


(Fastidious) #1

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


(Matt Holt) #2

In progress!

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


(Matt Holt) #3

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


(Fastidious) #4

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?


(Matthew Fay) #5

If you are interested in trying it out, you will need to compile it. It’s not too complicated, but you need Go installed: https://golang.org/doc/install

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.


(Matt Holt) #6

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.


(Fastidious) #7

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.


(Matthew Fay) #8

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.


(Fastidious) #9

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)?


(Matt Holt) #10

See https://community.letsencrypt.org/t/wildcard-certificates-via-http-01/51223


(Fastidious) #11

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


(Matt Holt) #12

There actually is: https://tools.ietf.org/html/rfc2136

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.


(Peter Passchier) #13

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

(Matt Holt) #14

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…)


(Matthew Fay) #15

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


(system) #16

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