feat: upgrade lego to v5.1.0 and add Dynadot DNS provider by rowanchen-com · Pull Request #12829 · 1Panel-dev/1Panel

rowanchen-com · 2026-05-23T14:25:32Z

What this PR does / why we need it?

Adding Dynadot requires lego v5.1.0 (the provider is not in v4), so this
PR does both at once: upgrade lego from v4.35.2 to v5.1.0, and wire up
the new Dynadot DNS provider.

Summary of your change

Commit 1 -- lego v5 upgrade

Adapt to v5 API breaks: Obtain/ObtainForCSR/Revoke take a context.Context;
AcmeUser.Key is crypto.Signer instead of crypto.PrivateKey; account
registration is *acme.ExtendedAccount instead of *registration.Resource;
certificate.Resource.Domain was renamed to Domains ([]string).
dns01.AddRecursiveNameservers and dns01.AddDNSTimeout were removed;
use dns01.SetDefaultClient(dns01.NewClient(&Options{...})) instead. The
custom recursive nameserver fields in the website SSL form keep working.
ObtainRequest disables the Common Name by default in v5. EnableCommonName
is set to true to keep the v4 behaviour, otherwise older clients (Java
keystores, embedded routers) that still rely on the CN field would fail
the TLS handshake.
lego.CertificateConfig.KeyType field was removed; the matching code path
is dropped.
lego log.Logger is now *slog.Logger; bridge it to the existing per-domain
*log.Logger via slog.NewTextHandler so SSL apply logs still land in
SSLLogDir.

Backward compatibility for users upgrading from v4

certcrypto.KeyType string values were renamed: P256 -> EC256,
P384 -> EC384, 2048 -> RSA2048, 3072 -> RSA3072, 4096 -> RSA4096,
8192 -> RSA8192. A gormigrate migration rewrites the key_type column in
website_acme_accounts, website_ssls and website_cas on first start, so
old certificates renew automatically. A normalizeKeyType helper also
handles the mapping at runtime as a safety net.
v5 serializes private keys as PKCS#8 while v4 used SEC1 (EC) and PKCS#1
(RSA). A new parsePrivateKeyPEM helper tries PKCS#8 first and falls back
to the legacy formats, so existing account keys persisted under v4 keep
loading without manual conversion.
Frontend KeyTypes select options and the four form-initial keyType
defaults are updated to the v5 form.

Commit 2 -- Dynadot / DnsPod

Add Dynadot DNS provider, surfaced in the DNS account dialog next to
the other API-key/secret based providers.
Remove DnsPod from the provider list (lego v5 has no DnsPod
implementation). The startup migration counts existing DnsPod rows in
website_dns_accounts and logs a warning so the operator can switch them
to TencentCloud, which now manages DNSPod-hosted zones via the same
underlying API. Existing rows are not deleted.

Tested locally against AliYun, Spaceship, CloudFlare and Dynadot.
Certificates issued under v4 renew under the v5 binary in seconds (LE
authorization is reused), and brand-new domains go through the full
DNS-01 flow correctly.

Please indicate you've done the following:

Made sure tests are passing and test coverage is added if needed.
Made sure commit message follow the rule of Conventional Commits specification.
Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

f2c-ci-robot · 2026-05-23T14:25:37Z

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

f2c-ci-robot · 2026-05-23T14:26:05Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign ssongliu for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

lego v5 introduces several breaking API changes that touch every entry point we use. This commit migrates 1Panel's SSL stack to v5 and adds a data migration so existing certificates keep auto-renewing without operator action. Code changes: - AcmeUser.Key is now a crypto.Signer (was crypto.PrivateKey); same for the key returned by GetPrivateKeyByType. Account registration is now an *acme.ExtendedAccount (was *registration.Resource). - A new parsePrivateKeyPEM helper accepts both v4 (SEC1 EC, PKCS#1 RSA) and v5 (PKCS#8) key formats, so account/certificate keys persisted under v4 keep loading after the upgrade. - Obtain/ObtainForCSR/Revoke now require a context.Context. - dns01.AddRecursiveNameservers and dns01.AddDNSTimeout were removed. Recursive nameservers and timeout are now passed via dns01.SetDefaultClient(dns01.NewClient(&dns01.Options{...})). - ObtainRequest disables the CN by default in v5; we set EnableCommonName: true to preserve the v4 behaviour for legacy clients (Java keystores, embedded routers, etc.) that still rely on the CommonName field. - lego.CertificateConfig.KeyType was removed (the key type is taken from the user's account); the matching code path is dropped. - certificate.Resource.Domain was renamed to Domains (now []string). - log.Logger is now an *slog.Logger; switch website_ssl.go over to slog with a TextHandler that writes to the existing file logger. KeyType migration: - certcrypto.KeyType string values were renamed in v5: P256->EC256, P384->EC384, 2048->RSA2048, 3072->RSA3072, 4096->RSA4096, 8192->RSA8192. A gormigrate migration rewrites the key_type column in website_acme_accounts, website_ssls and website_cas on first start, so old certificates renew under their new names automatically. - A normalizeKeyType helper falls back to the same mapping at runtime, in case the database migration has not yet run. - Frontend KeyTypes select options and four form-initial keyType defaults are updated to the v5 form so newly created accounts also use the new strings. Build and vet pass on linux/amd64 (GOOS=linux GOARCH=amd64 go build/vet ./...).

Dynadot was added to upstream lego in v5.1.0 (go-acme/lego#3125). Wire it into the same DNS provider switch the other 25 providers use, and surface it in the frontend so users can pick it in the DNS account dialog. DnsPod is removed from the DNS provider list. lego v5 has no DnsPod implementation; the previous frontend already showed a deprecation hint pointing at TencentCloud, which is now the recommended way to manage DNSPod-hosted zones (the underlying API is the same).

…ace) Three issues raised on the PR: 1. Backend KeyType validators in WebsiteAcmeAccountCreate, WebsiteCACreate and WebsiteCAObtain still required the v4 strings (P256/P384/2048/...), so after the frontend started sending v5 strings (EC256/RSA2048/...) the create/obtain endpoints would 422. Validators now accept both v4 and v5 forms; service-layer normalizeKeyType continues to handle either case. 2. getDNSProviderConfig had no default branch in its switch. A DNS account with type `DnsPod` (kept on disk after the v5 upgrade) silently fell through and returned (nil, nil), making the DNS-01 step fail far away from the real cause. Add an explicit DnsPod branch that returns a clear `removed in lego v5; switch to TencentCloud` error, plus a generic default for any other unknown type. Surface the same warning in the UI: the DNS account list shows a `removed` tag on DnsPod rows, and the SSL list shows the same tag on certificates that are still bound to a DnsPod account, so users see the broken state before auto-renewal silently fails. 3. lego v5 keeps the recursive-resolver Client and the LEGO_DISABLE_CNAME_SUPPORT environment switch as process-wide globals, and reads dns01.DefaultClient() inside its own propagation precheck loop. Two concurrent SSL applications with different nameserver / DisableCNAME settings could clobber each other and use the wrong resolver. Wrap the whole DNS-01 flow (UseDns through Obtain*) in a package-level mutex so one apply finishes before the next one configures the globals. i18n strings for the DnsPod removal hints are added to all 10 locales to match the existing translation coverage of nearby keys.

zhengkunwang223 · 2026-05-25T05:48:41Z

lego v5 升级是大改
涉及证书签发、续签、撤销、DNS-01、私钥格式和迁移
你是否有做过所有的测试？

zhengkunwang223 · 2026-05-25T06:00:31Z

 	Email      string `json:"email" validate:"required"`
 	Type       string `json:"type" validate:"required,oneof=letsencrypt zerossl buypass google custom"`
-	KeyType    string `json:"keyType" validate:"required,oneof=P256 P384 2048 3072 4096 8192"`
+	KeyType    string `json:"keyType" validate:"required,oneof=P256 P384 2048 3072 4096 8192 EC256 EC384 RSA2048 RSA3072 RSA4096 RSA8192"`


P256 P384 2048 3072 4096 8192
这些是不是可以删掉

不删的话后端要有兜底

zhengkunwang223 · 2026-05-25T06:08:47Z

我看到 lego v5 使用了新的密钥常量

EC256
EC384
RSA2048
RSA3072
RSA4096
RSA8192

存量证书升级之后会导致续签失败
你参考 lego v5 中的
github.com/go-acme/lego/v5/certcrypto/compat

func (k *KeyTypeCompat) UnmarshalText(text []byte) error {
    switch string(text) {
    case `P256`:
        *k = EC256
    case `P384`:
        *k = EC384
    case `2048`:
        *k = RSA2048
    case `3072`:
        *k = RSA3072
    case `4096`:
        *k = RSA4096
    case `8192`:
        *k = RSA8192
    default:
        kt, err := certcrypto.ToKeyType(string(text))
        if err != nil {
            return err
        }
        *k = KeyTypeCompat(kt)
    }
    return nil
}

这个方法做一下兼容

zhengkunwang223 · 2026-05-25T07:10:03Z

-        label: 'DNSPod (' + i18n.global.t('ssl.deprecated') + ')',
-        value: 'DnsPod',
+        label: 'Dynadot',
+        value: 'Dynadot',


DNSPOD 不要直接删除
要考虑用户存量数据如何显示

…ecated Two follow-ups from review: - normalizeKeyType now delegates to lego v5's official compat.KeyTypeCompat.UnmarshalText, so we no longer maintain our own P256/2048->EC256/RSA2048 switch and stay aligned with upstream when more legacy values are added later. - mimetype.ts keeps DnsPod in DNSTypes with a deprecated:true flag instead of removing it. The DNS account dialog renders the option as 'DNSPod (deprecated)' and disables it on create, so users with existing DnsPod accounts can still see the type label and edit/remove the row, but new accounts cannot pick it. Backend default branch in getDNSProviderConfig already returns a clear 'switch to TencentCloud' error if anything still hits DnsPod at runtime.

Per maintainer feedback, the v4 keytype literals (P256/P384/2048/3072/4096/8192) are now removed from request validators and code-level defaults. The runtime normalizer (lego v5 compat.KeyTypeCompat) and the MigrateLegoV5 DB rewrite still keep upgrade paths working transparently for existing v4 installs. Changes: - agent/app/dto/request/website_ssl.go: trim 'oneof' on WebsiteAcmeAccountCreate / WebsiteCACreate / WebsiteCAObtain to v5 only (EC256 EC384 RSA2048 RSA3072 RSA4096 RSA8192). - agent/app/model/{website_acme_account,website_ca}.go and core/app/model/agent.go: GORM 'default:2048' -> 'default:RSA2048' so a freshly created row never carries a v4 string. - agent/init/migration/migrations/init.go: InitDefaultCA now creates the built-in '1Panel' CA with KeyType 'EC256' (was 'P256'). - agent/init/business/business.go: initAcmeAccount now creates the default Let's Encrypt account with KeyType 'RSA2048' (was '2048'). - agent/app/service/app_utils.go: OpenResty default localhost cert obtained with KeyType 'RSA4096' (was '4096'). - core/app/service/setting.go: panel HTTPS self-sign POSTs keyType 'EC256' to /api/v2/websites/ca/obtain (was 'P256'). - core/cmd/server/docs/{docs.go,swagger.json}: regenerated swagger enums for the three KeyType endpoints to match the new validators. Tested on a fresh Debian 13 install: v4-era SSL/account/CA rows are migrated to v5 by MigrateLegoV5 on startup; renewal of a v4-era cert (lab.qmye.com) succeeds against Let's Encrypt; new DNS-01 issuance (hhe.qmye.com) succeeds end-to-end; sqlite scan shows zero v4 residual across website_acme_accounts / website_ssls / website_cas.

f2c-ci-robot Bot added the do-not-merge/release-note-label-needed label May 23, 2026

f2c-ci-robot Bot requested review from ssongliu and wanghe-fit2cloud May 23, 2026 14:26

rowanchen-com added 3 commits May 25, 2026 12:58

rowanchen-com force-pushed the feat/lego-v5-and-dynadot branch from 35bf2db to 0e4a940 Compare May 25, 2026 04:59

zhengkunwang223 reviewed May 25, 2026

View reviewed changes

rowanchen-com force-pushed the feat/lego-v5-and-dynadot branch from e02f0af to 56527aa Compare May 25, 2026 10:01

rowanchen-com force-pushed the feat/lego-v5-and-dynadot branch from 56527aa to b81b051 Compare May 25, 2026 10:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: upgrade lego to v5.1.0 and add Dynadot DNS provider#12829

feat: upgrade lego to v5.1.0 and add Dynadot DNS provider#12829
rowanchen-com wants to merge 5 commits into
1Panel-dev:dev-v2from
rowanchen-com:feat/lego-v5-and-dynadot

rowanchen-com commented May 23, 2026

Uh oh!

f2c-ci-robot Bot commented May 23, 2026

Uh oh!

f2c-ci-robot Bot commented May 23, 2026

Uh oh!

zhengkunwang223 commented May 25, 2026

Uh oh!

zhengkunwang223 May 25, 2026

Uh oh!

zhengkunwang223 May 25, 2026

Uh oh!

zhengkunwang223 commented May 25, 2026

Uh oh!

zhengkunwang223 May 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

rowanchen-com commented May 23, 2026

What this PR does / why we need it?

Summary of your change

Please indicate you've done the following:

Uh oh!

f2c-ci-robot Bot commented May 23, 2026

Uh oh!

f2c-ci-robot Bot commented May 23, 2026

Uh oh!

zhengkunwang223 commented May 25, 2026

Uh oh!

zhengkunwang223 May 25, 2026

Choose a reason for hiding this comment

Uh oh!

zhengkunwang223 May 25, 2026

Choose a reason for hiding this comment

Uh oh!

zhengkunwang223 commented May 25, 2026

Uh oh!

zhengkunwang223 May 25, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants