1
Fork 0
mirror of https://github.com/caddyserver/caddy.git synced 2024-12-16 21:56:40 -05:00
caddy/modules/caddytls/zerosslissuer.go

243 lines
7.8 KiB
Go
Raw Normal View History

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 09:58:06 -05:00
// Copyright 2015 Matthew Holt and The Caddy Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package caddytls
import (
"context"
"crypto/x509"
"encoding/json"
"fmt"
"io"
"net/http"
"net/url"
"strings"
"sync"
"github.com/caddyserver/caddy/v2"
"github.com/caddyserver/caddy/v2/caddyconfig/caddyfile"
"github.com/caddyserver/certmagic"
"github.com/mholt/acmez/acme"
"go.uber.org/zap"
)
func init() {
caddy.RegisterModule(new(ZeroSSLIssuer))
}
2022-08-08 13:48:28 -05:00
// ZeroSSLIssuer makes an ACME issuer for getting certificates
// from ZeroSSL by automatically generating EAB credentials.
// Please be sure to set a valid email address in your config
// so you can access/manage your domains in your ZeroSSL account.
//
// This issuer is only needed for automatic generation of EAB
// credentials. If manually configuring/reusing EAB credentials,
// the standard ACMEIssuer may be used if desired.
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 09:58:06 -05:00
type ZeroSSLIssuer struct {
*ACMEIssuer
// The API key (or "access key") for using the ZeroSSL API.
2022-08-08 13:48:28 -05:00
// This is optional, but can be used if you have an API key
// already and don't want to supply your email address.
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 09:58:06 -05:00
APIKey string `json:"api_key,omitempty"`
mu sync.Mutex
logger *zap.Logger
}
// CaddyModule returns the Caddy module information.
func (*ZeroSSLIssuer) CaddyModule() caddy.ModuleInfo {
return caddy.ModuleInfo{
ID: "tls.issuance.zerossl",
New: func() caddy.Module { return new(ZeroSSLIssuer) },
}
}
// Provision sets up iss.
func (iss *ZeroSSLIssuer) Provision(ctx caddy.Context) error {
iss.logger = ctx.Logger(iss)
if iss.ACMEIssuer == nil {
iss.ACMEIssuer = new(ACMEIssuer)
}
if iss.ACMEIssuer.CA == "" {
iss.ACMEIssuer.CA = certmagic.ZeroSSLProductionCA
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 09:58:06 -05:00
}
return iss.ACMEIssuer.Provision(ctx)
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 09:58:06 -05:00
}
// newAccountCallback generates EAB if not already provided. It also sets a valid default contact on the account if not set.
func (iss *ZeroSSLIssuer) newAccountCallback(ctx context.Context, acmeIss *certmagic.ACMEIssuer, acct acme.Account) (acme.Account, error) {
if acmeIss.ExternalAccount != nil {
return acct, nil
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 09:58:06 -05:00
}
var err error
acmeIss.ExternalAccount, acct, err = iss.generateEABCredentials(ctx, acct)
return acct, err
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 09:58:06 -05:00
}
// generateEABCredentials generates EAB credentials using the API key if provided,
// otherwise using the primary contact email on the issuer. If an email is not set
// on the issuer, a default generic email is used.
func (iss *ZeroSSLIssuer) generateEABCredentials(ctx context.Context, acct acme.Account) (*acme.EAB, acme.Account, error) {
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 09:58:06 -05:00
var endpoint string
var body io.Reader
// there are two ways to generate EAB credentials: authenticated with
// their API key, or unauthenticated with their email address
if iss.APIKey != "" {
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 09:58:06 -05:00
apiKey := caddy.NewReplacer().ReplaceAll(iss.APIKey, "")
if apiKey == "" {
return nil, acct, fmt.Errorf("missing API key: '%v'", iss.APIKey)
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 09:58:06 -05:00
}
qs := url.Values{"access_key": []string{apiKey}}
endpoint = fmt.Sprintf("%s/eab-credentials?%s", zerosslAPIBase, qs.Encode())
} else {
email := iss.Email
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 09:58:06 -05:00
if email == "" {
iss.logger.Warn("missing email address for ZeroSSL; it is strongly recommended to set one for next time")
email = "caddy@zerossl.com" // special email address that preserves backwards-compat, but which black-holes dashboard features, oh well
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 09:58:06 -05:00
}
if len(acct.Contact) == 0 {
// we borrow the email from config or the default email, so ensure it's saved with the account
acct.Contact = []string{"mailto:" + email}
}
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 09:58:06 -05:00
endpoint = zerosslAPIBase + "/eab-credentials-email"
form := url.Values{"email": []string{email}}
body = strings.NewReader(form.Encode())
}
req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, body)
if err != nil {
return nil, acct, fmt.Errorf("forming request: %v", err)
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 09:58:06 -05:00
}
if body != nil {
req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
}
req.Header.Set("User-Agent", certmagic.UserAgent)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, acct, fmt.Errorf("performing EAB credentials request: %v", err)
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 09:58:06 -05:00
}
defer resp.Body.Close()
var result struct {
Success bool `json:"success"`
Error struct {
Code int `json:"code"`
Type string `json:"type"`
} `json:"error"`
EABKID string `json:"eab_kid"`
EABHMACKey string `json:"eab_hmac_key"`
}
err = json.NewDecoder(resp.Body).Decode(&result)
if err != nil {
return nil, acct, fmt.Errorf("decoding API response: %v", err)
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 09:58:06 -05:00
}
if result.Error.Code != 0 {
return nil, acct, fmt.Errorf("failed getting EAB credentials: HTTP %d: %s (code %d)",
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 09:58:06 -05:00
resp.StatusCode, result.Error.Type, result.Error.Code)
}
if resp.StatusCode != http.StatusOK {
return nil, acct, fmt.Errorf("failed getting EAB credentials: HTTP %d", resp.StatusCode)
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 09:58:06 -05:00
}
iss.logger.Info("generated EAB credentials", zap.String("key_id", result.EABKID))
return &acme.EAB{
KeyID: result.EABKID,
MACKey: result.EABHMACKey,
}, acct, nil
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 09:58:06 -05:00
}
// initialize modifies the template for the underlying ACMEIssuer
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 09:58:06 -05:00
// values by setting the CA endpoint to the ZeroSSL directory and
// setting the NewAccountFunc callback to one which allows us to
// generate EAB credentials only if a new account is being made.
// Since it modifies the stored template, its effect should only
// be needed once, but it is fine to call it repeatedly.
func (iss *ZeroSSLIssuer) initialize() {
iss.mu.Lock()
defer iss.mu.Unlock()
if iss.ACMEIssuer.issuer.NewAccountFunc == nil {
iss.ACMEIssuer.issuer.NewAccountFunc = iss.newAccountCallback
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 09:58:06 -05:00
}
}
// PreCheck implements the certmagic.PreChecker interface.
func (iss *ZeroSSLIssuer) PreCheck(ctx context.Context, names []string, interactive bool) error {
iss.initialize()
return iss.ACMEIssuer.PreCheck(ctx, names, interactive)
}
// Issue obtains a certificate for the given csr.
func (iss *ZeroSSLIssuer) Issue(ctx context.Context, csr *x509.CertificateRequest) (*certmagic.IssuedCertificate, error) {
iss.initialize()
return iss.ACMEIssuer.Issue(ctx, csr)
}
// IssuerKey returns the unique issuer key for the configured CA endpoint.
func (iss *ZeroSSLIssuer) IssuerKey() string {
iss.initialize()
return iss.ACMEIssuer.IssuerKey()
}
// Revoke revokes the given certificate.
func (iss *ZeroSSLIssuer) Revoke(ctx context.Context, cert certmagic.CertificateResource, reason int) error {
iss.initialize()
return iss.ACMEIssuer.Revoke(ctx, cert, reason)
}
// UnmarshalCaddyfile deserializes Caddyfile tokens into iss.
//
2022-08-08 13:48:28 -05:00
// ... zerossl [<api_key>] {
// ...
// }
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 09:58:06 -05:00
//
// Any of the subdirectives for the ACME issuer can be used in the block.
func (iss *ZeroSSLIssuer) UnmarshalCaddyfile(d *caddyfile.Dispenser) error {
for d.Next() {
if d.NextArg() {
iss.APIKey = d.Val()
if d.NextArg() {
return d.ArgErr()
}
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 09:58:06 -05:00
}
if iss.ACMEIssuer == nil {
iss.ACMEIssuer = new(ACMEIssuer)
}
err := iss.ACMEIssuer.UnmarshalCaddyfile(d.NewFromNextSegment())
if err != nil {
return err
}
}
return nil
}
const zerosslAPIBase = "https://api.zerossl.com/acme"
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 09:58:06 -05:00
// Interface guards
var (
_ certmagic.PreChecker = (*ZeroSSLIssuer)(nil)
_ certmagic.Issuer = (*ZeroSSLIssuer)(nil)
_ certmagic.Revoker = (*ZeroSSLIssuer)(nil)
_ caddy.Provisioner = (*ZeroSSLIssuer)(nil)
_ ConfigSetter = (*ZeroSSLIssuer)(nil)
// a type which properly embeds an ACMEIssuer should implement
// this interface so it can be treated as an ACMEIssuer
_ interface{ GetACMEIssuer() *ACMEIssuer } = (*ZeroSSLIssuer)(nil)
)