2020-08-04 03:44:38 +08:00
|
|
|
{
|
|
|
|
debug
|
|
|
|
http_port 8080
|
|
|
|
https_port 8443
|
|
|
|
default_sni localhost
|
|
|
|
order root first
|
|
|
|
storage file_system {
|
|
|
|
root /data
|
|
|
|
}
|
|
|
|
acme_ca https://example.com
|
|
|
|
acme_ca_root /path/to/ca.crt
|
|
|
|
|
|
|
|
email test@example.com
|
|
|
|
admin {
|
|
|
|
origins localhost:2019 [::1]:2019 127.0.0.1:2019 192.168.10.128
|
|
|
|
}
|
|
|
|
on_demand_tls {
|
|
|
|
ask https://example.com
|
|
|
|
interval 30s
|
|
|
|
burst 20
|
|
|
|
}
|
|
|
|
local_certs
|
|
|
|
key_type ed25519
|
|
|
|
}
|
|
|
|
|
|
|
|
:80
|
|
|
|
----------
|
|
|
|
{
|
|
|
|
"admin": {
|
|
|
|
"listen": "localhost:2019",
|
|
|
|
"origins": [
|
|
|
|
"localhost:2019",
|
|
|
|
"[::1]:2019",
|
|
|
|
"127.0.0.1:2019",
|
|
|
|
"192.168.10.128"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
"logging": {
|
|
|
|
"logs": {
|
|
|
|
"default": {
|
|
|
|
"level": "DEBUG"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"storage": {
|
|
|
|
"module": "file_system",
|
|
|
|
"root": "/data"
|
|
|
|
},
|
|
|
|
"apps": {
|
|
|
|
"http": {
|
|
|
|
"http_port": 8080,
|
|
|
|
"https_port": 8443,
|
|
|
|
"servers": {
|
|
|
|
"srv0": {
|
|
|
|
"listen": [
|
|
|
|
":80"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"tls": {
|
|
|
|
"automation": {
|
|
|
|
"policies": [
|
|
|
|
{
|
2020-11-17 02:05:55 +08:00
|
|
|
"issuers": [
|
|
|
|
{
|
|
|
|
"module": "internal"
|
|
|
|
}
|
|
|
|
],
|
caddytls: Add support for ZeroSSL; add Caddyfile support for issuers (#3633)
* caddytls: Add support for ZeroSSL; add Caddyfile support for issuers
Configuring issuers explicitly in a Caddyfile is not easily compatible
with existing ACME-specific parameters such as email or acme_ca which
infer the kind of issuer it creates (this is complicated now because
the ZeroSSL issuer wraps the ACME issuer)... oh well, we can revisit
that later if we need to.
New Caddyfile global option:
{
cert_issuer <name> ...
}
Or, alternatively, as a tls subdirective:
tls {
issuer <name> ...
}
For example, to use ZeroSSL with an API key:
{
cert_issuser zerossl API_KEY
}
For now, that still uses ZeroSSL's ACME endpoint; it fetches EAB
credentials for you. You can also provide the EAB credentials directly
just like any other ACME endpoint:
{
cert_issuer acme {
eab KEY_ID MAC_KEY
}
}
All these examples use the new global option (or tls subdirective). You
can still use traditional/existing options with ZeroSSL, since it's
just another ACME endpoint:
{
acme_ca https://acme.zerossl.com/v2/DV90
acme_eab KEY_ID MAC_KEY
}
That's all there is to it. You just can't mix-and-match acme_* options
with cert_issuer, because it becomes confusing/ambiguous/complicated to
merge the settings.
* Fix broken test
This test was asserting buggy behavior, oops - glad this branch both
discovers and fixes the bug at the same time!
* Fix broken test (post-merge)
* Update modules/caddytls/acmeissuer.go
Fix godoc comment
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Add support for ZeroSSL's EAB-by-email endpoint
Also transform the ACMEIssuer into ZeroSSLIssuer implicitly if set to
the ZeroSSL endpoint without EAB (the ZeroSSLIssuer is needed to
generate EAB if not already provided); this is now possible with either
an API key or an email address.
* go.mod: Use latest certmagic, acmez, and x/net
* Wrap underlying logic rather than repeating it
Oops, duh
* Form-encode email info into request body for EAB endpoint
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
2020-08-11 22:58:06 +08:00
|
|
|
"key_type": "ed25519"
|
2020-08-04 03:44:38 +08:00
|
|
|
}
|
|
|
|
],
|
|
|
|
"on_demand": {
|
2023-08-10 01:25:59 +08:00
|
|
|
"ask": "https://example.com",
|
2020-08-04 03:44:38 +08:00
|
|
|
"rate_limit": {
|
|
|
|
"interval": 30000000000,
|
|
|
|
"burst": 20
|
2023-08-10 01:25:59 +08:00
|
|
|
}
|
2020-08-04 03:44:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|