Before creating an issue, make sure you've checked the following:
Platform
Linux 6.8.0-1057-aws #60~22.04.1-Ubuntu SMP Wed May 27 08:16:59 UTC 2026 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
Version
v1.35.4+k0s.0
Sysinfo
`k0s sysinfo`
Total memory: 15.4 GiB (pass)
File system of /var/lib/k0s: ext4 (pass)
Disk space available for /var/lib/k0s: 85.3 GiB (pass)
Relative disk space available for /var/lib/k0s: 88% (pass)
Name resolution: localhost: [127.0.0.1] (pass)
Operating system: Linux (pass)
Linux kernel release: 6.8.0-1057-aws (pass)
Max. file descriptors per process: current: 1048575 / max: 1048576 (pass)
AppArmor: active (pass)
Executable in PATH: modprobe: /usr/sbin/modprobe (pass)
Executable in PATH: mount: /usr/bin/mount (pass)
Executable in PATH: umount: /usr/bin/umount (pass)
/proc file system: mounted (0x9fa0) (pass)
Control Groups: version 2 (pass)
cgroup controller "cpu": available (is a listed root controller) (pass)
cgroup controller "cpuacct": available (via cpu in version 2) (pass)
cgroup controller "cpuset": available (is a listed root controller) (pass)
cgroup controller "memory": available (is a listed root controller) (pass)
cgroup controller "devices": available (device filters attachable) (pass)
cgroup controller "freezer": available (cgroup.freeze exists) (pass)
cgroup controller "pids": available (is a listed root controller) (pass)
cgroup controller "hugetlb": available (is a listed root controller) (pass)
cgroup controller "blkio": available (via io in version 2) (pass)
CONFIG_CGROUPS: Control Group support: built-in (pass)
CONFIG_CGROUP_SCHED: Group CPU scheduler: built-in (pass)
CONFIG_FAIR_GROUP_SCHED: Group scheduling for SCHED_OTHER: built-in (pass)
CONFIG_CFS_BANDWIDTH: CPU bandwidth provisioning for FAIR_GROUP_SCHED: built-in (pass)
CONFIG_BLK_CGROUP: Block IO controller: built-in (pass)
CONFIG_NAMESPACES: Namespaces support: built-in (pass)
CONFIG_UTS_NS: UTS namespace: built-in (pass)
CONFIG_IPC_NS: IPC namespace: built-in (pass)
CONFIG_PID_NS: PID namespace: built-in (pass)
CONFIG_NET_NS: Network namespace: built-in (pass)
CONFIG_NET: Networking support: built-in (pass)
CONFIG_INET: TCP/IP networking: built-in (pass)
CONFIG_IPV6: The IPv6 protocol: built-in (pass)
CONFIG_NETFILTER: Network packet filtering framework (Netfilter): built-in (pass)
CONFIG_NETFILTER_ADVANCED: Advanced netfilter configuration: built-in (pass)
CONFIG_NF_CONNTRACK: Netfilter connection tracking support: module (pass)
CONFIG_NETFILTER_XTABLES: Netfilter Xtables support: module (pass)
CONFIG_NETFILTER_XT_TARGET_REDIRECT: REDIRECT target support: module (pass)
CONFIG_NETFILTER_XT_MATCH_COMMENT: "comment" match support: module (pass)
CONFIG_NETFILTER_XT_MARK: nfmark target and match support: module (pass)
CONFIG_NETFILTER_XT_SET: set target and match support: module (pass)
CONFIG_NETFILTER_XT_TARGET_MASQUERADE: MASQUERADE target support: module (pass)
CONFIG_NETFILTER_XT_NAT: "SNAT and DNAT" targets support: module (pass)
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: "addrtype" address type match support: module (pass)
CONFIG_NETFILTER_XT_MATCH_CONNTRACK: "conntrack" connection tracking match support: module (pass)
CONFIG_NETFILTER_XT_MATCH_MULTIPORT: "multiport" Multiple port match support: module (pass)
CONFIG_NETFILTER_XT_MATCH_RECENT: "recent" match support: module (pass)
CONFIG_NETFILTER_XT_MATCH_STATISTIC: "statistic" match support: module (pass)
CONFIG_NETFILTER_NETLINK: module (pass)
CONFIG_NF_NAT: module (pass)
CONFIG_IP_SET: IP set support: module (pass)
CONFIG_IP_SET_HASH_IP: hash:ip set support: module (pass)
CONFIG_IP_SET_HASH_NET: hash:net set support: module (pass)
CONFIG_IP_VS: IP virtual server support: module (pass)
CONFIG_IP_VS_NFCT: Netfilter connection tracking: built-in (pass)
CONFIG_IP_VS_SH: Source hashing scheduling: module (pass)
CONFIG_IP_VS_RR: Round-robin scheduling: module (pass)
CONFIG_IP_VS_WRR: Weighted round-robin scheduling: module (pass)
CONFIG_NF_CONNTRACK_IPV4: IPv4 connection tracking support (required for NAT): unknown (warning)
CONFIG_NF_REJECT_IPV4: IPv4 packet rejection: module (pass)
CONFIG_NF_NAT_IPV4: IPv4 NAT: unknown (warning)
CONFIG_IP_NF_IPTABLES: IP tables support: module (pass)
CONFIG_IP_NF_FILTER: Packet filtering: module (pass)
CONFIG_IP_NF_TARGET_REJECT: REJECT target support: module (pass)
CONFIG_IP_NF_NAT: iptables NAT support: module (pass)
CONFIG_IP_NF_MANGLE: Packet mangling: module (pass)
CONFIG_NF_DEFRAG_IPV4: module (pass)
CONFIG_NF_CONNTRACK_IPV6: IPv6 connection tracking support (required for NAT): unknown (warning)
CONFIG_NF_NAT_IPV6: IPv6 NAT: unknown (warning)
CONFIG_IP6_NF_IPTABLES: IP6 tables support: module (pass)
CONFIG_IP6_NF_FILTER: Packet filtering: module (pass)
CONFIG_IP6_NF_MANGLE: Packet mangling: module (pass)
CONFIG_IP6_NF_NAT: ip6tables NAT support: module (pass)
CONFIG_NF_DEFRAG_IPV6: module (pass)
CONFIG_BRIDGE: 802.1d Ethernet Bridging: module (pass)
CONFIG_LLC: module (pass)
CONFIG_STP: module (pass)
CONFIG_EXT4_FS: The Extended 4 (ext4) filesystem: built-in (pass)
CONFIG_PROC_FS: /proc file system support: built-in (pass)
What happened?
#6380 added functionality to regenerate certs issued by custom CAs when the CA cert and key are present.
However, it does not account for the possibility that the etcd CA may have a different Common Name than the cluster CA.
Thus, here
|
case ca.Subject.CommonName: |
when you compare the cert issuer CN with the CA CN, you only compare it with the cluster CA, while etcd certs are usually issued by a separate CA. Even in the case of k0s CA, you have 2 different common names for cluster
kubernetes-ca and etcd
etcd-ca. But in the case of custom CA certs, you only account for one common name, the name of the
filepath.Join(m.K0sVars.CertRootDir, "ca.crt")
Steps to reproduce
- Deploy k0s with custom cluster CA and etcd CA, as well as server and peer certs issued by the etcd CA
- Observe logs, you will see something like
Jun 12 20:19:05 ip-172-31-0-127.us-east-2.compute.internal k0s[54952]: time="2026-06-12 20:19:05" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/server.crt, not managed by k0s: MKE etcd Root CA"
Jun 12 20:19:05 ip-172-31-0-127.us-east-2.compute.internal k0s[54952]: time="2026-06-12 20:19:05" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/peer.crt, not managed by k0s: MKE etcd Root CA"
Expected behavior
In addition to filepath.Join(m.K0sVars.CertRootDir, "ca.crt"). You should also check the CA at filepath.Join(m.K0sVars.EtcdCertDir, "ca.crt")` and regenerate the etcd certs with a custom etcd CA.
Actual behavior
The etcd certs are ignored by the k0s cert manager.
Screenshots and logs
No response
Additional context
It's worth mentioning that #6380 mostly fixed the issue, and it worked correctly for most of my certs. For example, before #6380 landed, I had
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/konnectivity.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/scheduler.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/apiserver-kubelet-client.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/admin.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/ccm.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/k0s-api.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:45 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:45" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/server.crt, not managed by k0s: swarm-ca"
Jun 08 19:29:46 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:46" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/server.crt, not managed by k0s: MKE etcd Root CA"
Jun 08 19:29:46 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:46" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/peer.crt, not managed by k0s: MKE etcd Root CA"
Jun 08 19:29:46 ip-172-31-1-21.eu-central-1.compute.internal k0s[115666]: time="2026-06-08 19:29:46" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/apiserver-etcd-client.crt, not managed by k0s: MKE etcd Root CA"
whereas after #6380, the list has shortened to just
Jun 12 20:19:05 ip-172-31-0-127.us-east-2.compute.internal k0s[54952]: time="2026-06-12 20:19:05" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/server.crt, not managed by k0s: MKE etcd Root CA"
Jun 12 20:19:05 ip-172-31-0-127.us-east-2.compute.internal k0s[54952]: time="2026-06-12 20:19:05" level=debug msg="cert regeneration not needed for /var/lib/k0s/pki/etcd/peer.crt, not managed by k0s: MKE etcd Root CA"
However, the fact that the etcd certs are ignored is a bug that should be easy to fix. We would love to have it backported to 1.35 as well. Thank you!
Before creating an issue, make sure you've checked the following:
Platform
Version
v1.35.4+k0s.0
Sysinfo
`k0s sysinfo`
What happened?
#6380 added functionality to regenerate certs issued by custom CAs when the CA cert and key are present.
However, it does not account for the possibility that the etcd CA may have a different Common Name than the cluster CA.
Thus, here
k0s/pkg/certificate/manager.go
Line 233 in e9260d2
kubernetes-caand etcdetcd-ca. But in the case of custom CA certs, you only account for one common name, the name of thefilepath.Join(m.K0sVars.CertRootDir, "ca.crt")Steps to reproduce
Expected behavior
In addition to
filepath.Join(m.K0sVars.CertRootDir, "ca.crt"). You should also check the CA atfilepath.Join(m.K0sVars.EtcdCertDir, "ca.crt")` and regenerate the etcd certs with a custom etcd CA.Actual behavior
The etcd certs are ignored by the k0s cert manager.
Screenshots and logs
No response
Additional context
It's worth mentioning that #6380 mostly fixed the issue, and it worked correctly for most of my certs. For example, before #6380 landed, I had
whereas after #6380, the list has shortened to just
However, the fact that the etcd certs are ignored is a bug that should be easy to fix. We would love to have it backported to 1.35 as well. Thank you!