lego v5.2.1 (released 2026-06-01) is a small follow-up patch on top of v5.2.0; the only fixed item is a CLI/migration ergonomics tweak (printing the suggested configuration when the file cannot be created) that does not affect 1Panel, but moving to the latest tag keeps us on a published release rather than the previous one.
Changes are confined to agent/go.mod and agent/go.sum; the source files under agent/utils/ssl/ already use the import path github.com/go-acme/lego/v5/... and require no code changes. Compared with the previous v5.2.0 step, this revision is a 6-line dependency bump (1 line in go.mod plus 4 lines of refreshed go.sum hashes), since lego itself did not move any of its own dependency pins between v5.2.0 and v5.2.1.
Indirect dependency bumps (carried over from the v5.2.0 -> v5.2.1 rebase, produced by 'go mod tidy' on a fresh checkout):
- alibabacloud-go/darabonba-openapi v2.1.16 -> v2.2.1, alibabacloud-go/tea v1.4.0 -> v1.5.0 (alidns provider chain)
- aws-sdk-go-v2 family v1.41.7 -> v1.41.8 plus matching service modules (route53 provider chain)
- baidubce/bce-sdk-go v0.9.266 -> v0.9.267, huaweicloud/huaweicloud-sdk-go-v3 v0.1.197 -> v0.1.198, tencentcloud-sdk-go v1.3.102 -> v1.3.106, volcengine/volc-sdk-golang v1.0.248 -> v1.0.249
- go-acme/alidns-20150109 major bump v4 -> v5, go-acme/esa-20240910 major bump v2 -> v3 (required by lego v5.2.x directly)
- fsnotify/fsnotify v1.9.0 -> v1.10.1 (also targeted by dependabot PRs #12864 / #12865)
Built and verified on linux/amd64:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -trimpath -ldflags='-s -w' ./...
agent and core binaries link cleanly against the upgraded lego and indirect dependencies; no source-level adaptations needed.
The auto-renew flow in obtainSSL returned early when OpenResty was not
installed or `nginx -s reload` failed, skipping reloadSystemSSL. The new
certificate was persisted to the DB and written into website Nginx
configs, but the panel's own server.crt / server.key on disk and the
in-memory constant.CertStore were left pointing at the old material.
Because the cert was now fresh, subsequent cron ticks did not retry the
renewal, so the panel kept serving the stale cert until a user manually
re-applied it from 面板设置 → SSL.
Two changes:
1. agent/app/service/website_ssl.go
reloadSystemSSL is now called unconditionally after a successful
renewal, regardless of whether OpenResty is present or nginx reload
succeeded. The function already short-circuits for non-panel SSLs,
so this is safe.
2. agent/app/service/website_ssl.go + agent/cron/job/ssl.go
Add SyncSystemSSL, invoked at the start of every renew cron tick.
It compares the panel's on-disk cert/key with the WebsiteSSL row
referenced by the SSLID setting and rewrites the files + notifies
core when they diverge. This recovers existing installs that are
already in the "DB ahead of disk" state and self-heals any future
drift introduced by transient failures.
https://github.com/1Panel-dev/1Panel/issues/12472
