OpenSSL rejects pre-renewal leaves when only the renewed same-key cert-manager CA is trusted
cert-manager v1.21.2 renewed a same-key CA with a truncated SHA-256 Subject Key Identifier where v1.18.6 had issued a SHA-1 one. In a lab run, OpenSSL 3.0.13 verified a pre-renewal leaf only while the old CA stayed in the trust store.
The Engineer · Build desk
What happened
- Go 1.25's release notes say CreateCertificate now fills a missing SubjectKeyId with truncated SHA-256, and GODEBUG x509sha256skid=0 reverts to SHA-1.
- In the controller's go.mod, v1.18.6 declares go 1.24.0, v1.19.0 declares go 1.25.0 and is the first affected version, and v1.21.2 declares go 1.26.0.
- Never was the default rotationPolicy until 1.18, whose release notes flipped it to Always and told operators to set Never explicitly to keep the old behavior.
Why it matters
- exposure Every CA issued with rotationPolicy: Never on 1.18 or earlier and renewed with the same key on 1.19 or later leaves its outstanding older leaves with an AKI the CA no longer matches.
- decision In our view the old CA certificate stays in every trust bundle until each pre-renewal leaf is reissued or expired, since OpenSSL verified those leaves only with it present.
- constraint One OpenSSL result does not clear other clients. The report calls breakage client-dependent, so each verifier in a fleet needs its own pre-renewal-leaf check.
The controller does not set the Subject Key Identifier itself [3]. It leaves the field empty and Go fills it, so the value depends on the toolchain that built the controller [4]. Per Go's godebug documentation, a build's default comes from the go line of its main module [5].
The renewed CA kept the same key [1]. A leaf issued before the renewal carries an Authority Key Identifier derived from the old SHA-1 SKI. That value no longer matches the renewed CA's SHA-256 SKI [7]. Against a trust store holding only the renewed CA, openssl verify returned "unable to get local issuer certificate". With the old and renewed CA bundled together, it accepted the leaf [2].
This is one run on one client. The lab used a single-node kind cluster and RSA-2048. The chain ran from a SelfSigned Issuer to a CA Certificate to a CA Issuer to a leaf, and the CA was upgraded in place through v1.19.6 and v1.20.4 to v1.21.2 [12]. The report says whether a mismatch breaks path building is client-dependent [11]. For the result to transfer, your verifiers would have to treat a mismatched AKI the way OpenSSL 3.0.13 did here.
cert-manager's Certificate documentation says that with rotationPolicy: Never, "cert-manager reuses the existing private key on each issuance" [9]. That held in the lab [1]. The report describes the identifier change as "a change recorded only one layer down" [13].
Anyone still on 1.18 is already off support. The vendor lists 1.18 as end of life on 2026-03-10 [14], and the lab measurement was taken on 2026-09-24 [15], which is 198 days later [18]. The 1.19 line, where the change starts, reached end of life on 2026-07-08 [17]. The current supported release is v1.21.2 [16], the version that produced the changed SKI in the lab [1].
What to watch
- Results from verifiers other than OpenSSL 3.0.13 against a pre-renewal leaf and a trust store holding only the renewed CA.
- Whether setting GODEBUG x509sha256skid=0 on the controller keeps SHA-1 SKIs across a same-key CA renewal.
- Whether cert-manager's upgrade guidance for 1.19 and later mentions the SKI change.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence72
- Adoption
- Insufficient
- Hype gap−10
- Incentives
- Insufficient
- Confidence68
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
On cert-manager v1.21.2, a v1.18.6-issued rotationPolicy: Never CA renewed with the same key kept its public key but got a new Subject Key Identifier, changing from SHA-1 to truncated SHA-256.
- [2]
With OpenSSL 3.0.13's openssl verify, the pre-renewal leaf failed against a trust store holding only the renewed CA ('unable to get local issuer certificate') and verified against the old and renewed CA bundled together.
- [3]
The cert-manager controller does not set the certificate's Subject Key Identifier itself.
- [4]
The Go 1.25 release notes state that CreateCertificate now uses truncated SHA-256 to populate the SubjectKeyId if it is missing, and that the GODEBUG setting x509sha256skid=0 reverts to SHA-1.
- [5]
Whether a build generates SKIs the new way (truncated SHA-256) or the old way (SHA-1) is decided by the go line of the main module, per Go's godebug documentation.
- [6]
In the controllercmd/controller go.mod, v1.18.6 declares go 1.24.0, v1.19.0 declares go 1.25.0 (the first affected version), and v1.21.2 declares go 1.26.0.
- [7]
A leaf issued before the renewal carries an Authority Key Identifier derived from the old CA's SHA-1 SKI, which no longer matches the renewed CA's SHA-256 SKI.
- [8]
The affected population is cert-manager CA Certificates issued with rotationPolicy: Never on 1.18 or earlier and then renewed with the same key on 1.19 or later.
- [9]
cert-manager's Certificate documentation, checked 2026-09-14, says that with rotationPolicy: Never "cert-manager reuses the existing private key on each issuance".
- [10]
Never was the default rotationPolicy until cert-manager 1.18, whose release notes changed the default to Always and advise operators to explicitly set rotationPolicy: Never to keep the old behavior.
- [11]
Whether the SKI/AKI mismatch breaks path building or verification is client-dependent, according to the report.
- [12]
The lab used a single-node kind cluster, a SelfSigned Issuer, a CA Certificate (isCA: true, rotationPolicy: Never, RSA-2048), a CA Issuer and a leaf Certificate, with the CA renewed in place with the same key after an in-place upgrade from v1.18.6 through v1.19.6 and v1.20.4 to v1.21.2.
- [13]
The report describes the identifier change as 'a change recorded only one layer down' from the cert-manager documentation that promises key reuse.
- [14]
cert-manager 1.18 is vendor-listed end of life on 2026-03-10.
- [15]
The lab was measured on 2026-09-24 (v1.18.6 to v1.21.2).
- [16]
cert-manager v1.21.2 is the current supported release, the latest as of 2026-09-11.
- [17]
The cert-manager 1.19 line, the first affected, reaches end of life on 2026-07-08.
- [18]
The lab measurement on 2026-09-24 came 198 days after the 1.18 end-of-life date of 2026-03-10.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toWhen a Renewed cert-manager CA Runs on the Same Key but a New Key Identifier
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- PKI trust chainsFollow
- Certificate managementFollow
- Kubernetes SecurityFollow