Support ACME of Let's Encrypt

[xxx7xxxx]

Background

As we discussed in the technical board[1], we decide to support automating certificates in let's encrypt.

Proposal

We should support features:

• Importing existed ACME certificates
• Automatically Request, renew ACME certificates
• Distributed storage for all certificates

Config

kind: ACME
name: acme-example

The certBase64 and keyBase64 is for imported ACME certificates.

---

kind: HTTPServer
name: http-server-example
acme: 
  email: [email protected] # required while certBase64 and keyBase64 are empty
  renewTimeout: 60d #optional
  caServer: https://acme-v02.api.letsencrypt.org/directory # opional [2]
  domains: ['megaease.com'] # required
  httpChallenge: {}
  tlsChanllege: {} # conflict with httpChallenge
  certBase64: ... # optional
  keyBase64: ... # optional
  keyType: RSA4096
# ...

Expected Behavior

The priority for certificates of HTTPServer:

1. ACME imported certificates
2. ACME generated certificates
3. Own certificates

Reference

[1] https://docs.google.com/document/d/1gKM6uV3zzjPdPjSdhhQ0eqROaJppgg38CduY-BOjVNU/edit#
[2] https://letsencrypt.org/docs/acme-protocol-updates/#acme-v2-rfc-8555

[localvar]

ACME support 3 types of challenge: HTTP-01, DNS-01 and TLS-ALPN-01, the Pros & Cons of each type can be found at https://letsencrypt.org/docs/challenge-types/.

The HTTP-01 and TLS-ALPN-01 challenges are supported by the acme and acme/autocert package from the crypto sub-repository of Golang, so it is easy for easegress to support them.

DNS-01 challenge is the only one that allows wildcard domain names, but there's an extra issue for Easegress to support it.

This challenge type requires an API from the DNS provider, and the API differs from each DNS providers, so Easegress need to integrate API for each supported DNS provider.

For the DNS-01 challenge type, we have 3 options and I prefer the 3rd one:

1. Don't support it
   • Pros:
     • Avoids introducing dependencies packages
   • Cons:
     • Easegress lacks some functionality
2. Support it based on lego
   • Pros:
     • It support all 3 types of challenges
     • It support nearly 100 DNS providers
   • Cons:
     • Use environment variables for configuration
     • Support so many DNS providers results in introducing a lot of dependencies packages into Easegress
3. Support it based on libdns, and only support the big names.
   • Pros:
     • A tradeoff of the other 2 options
   • Cons:
     • According to @xxx7xxxx 's investigation before, libdns is not actively developed.

[zhao-kun]

There are just almost 300 lines of codes in the libdns{provider} repo. IMHO, If you guys are afraid of introducing many dependencies or no one maintainning, why don't you write it from scratch?

[localvar]

the repo itself only defines the provider interface, the implementation are in other repos: https://github.com/libdns

[zhao-kun]

I'm talking about a provider repo. Eg : https://github.com/libdns/cloudflare it's just 300 line of codes.
DNS protocol is simple. So if you ask me, I will add writing from scratch to options.

[localvar]

write from scratch could be an option, but I think it will cost a lot of effort because we need to do the below tasks for each DNS provider:

• read the API documentation
• write the code
• register an account and a domain name to verify the code works.

And most of the libdns providers are already written from scratch, take the alidns as an example, the lego implementation is based on https://github.com/aliyun/alibaba-cloud-sdk-go, which has more than 10 dependencies; while the libdns implementation only depends on standard Go libraries.