Gateway certificate issuance runs in the Karmada control plane and works. Challenges stall there only when the hostname does not resolve to our edge, so Let's Encrypt reaches someone else's server and gets a 404. This issue was filed and maintained on the belief that nothing was issuing fleet-wide, which the order history contradicts.
What the record shows
Valid orders in the control plane, by creation date, read on 2026-08-28:
| Date |
Valid orders |
| 2026-06-18 |
57 |
| 2026-07-04, 07-06 |
6 |
| 2026-07-14, 07-15, 07-18, 07-21, 07-22 |
10 |
| 2026-07-24 through 2026-08-05 |
5 |
| 2026-08-17, 08-19 |
39 |
The status note on this issue said no certificate had issued since roughly 2026-07-09. Orders completed on 07-14, 07-15, 07-18 and 07-21, before that note was written.
Current state is 61 of 67 gateway certificates ready, 138 orders valid, 8 pending. Every pending one is a hostname whose DNS points somewhere other than our edge, two of them resolving nowhere at all.
The topology split has an answer
The control plane holds the certificates that matter. Each member also runs its own copy of the machinery, and the challenges it produces never complete, because the shared issuer's solver names a gateway that does not exist on a member. Those objects issue nothing and nothing serves from them.
The writer is the cert-manager gateway shim on the member, not propagation, which managedFields shows directly. That was established on this thread and is confirmed: the propagation policy carries no Certificate selector, and no Karmada work object carries one.
What this means for the plan recorded here
The plaintext listener item was justified by the ACME request having nothing to attach to at the edge. Issuance completing 39 times this month says the request does arrive, so that item needs re-deriving from a working challenge before anyone builds on it.
The availability items stand on their own merit rather than as outage recovery. A single fleet-wide pipeline running one replica of each controller is worth fixing, and nothing alerts when issuance fails. Neither is a defect in this component and both belong in their own issues.
Gateway certificate issuance runs in the Karmada control plane and works. Challenges stall there only when the hostname does not resolve to our edge, so Let's Encrypt reaches someone else's server and gets a 404. This issue was filed and maintained on the belief that nothing was issuing fleet-wide, which the order history contradicts.
What the record shows
Valid orders in the control plane, by creation date, read on 2026-08-28:
The status note on this issue said no certificate had issued since roughly 2026-07-09. Orders completed on 07-14, 07-15, 07-18 and 07-21, before that note was written.
Current state is 61 of 67 gateway certificates ready, 138 orders valid, 8 pending. Every pending one is a hostname whose DNS points somewhere other than our edge, two of them resolving nowhere at all.
The topology split has an answer
The control plane holds the certificates that matter. Each member also runs its own copy of the machinery, and the challenges it produces never complete, because the shared issuer's solver names a gateway that does not exist on a member. Those objects issue nothing and nothing serves from them.
The writer is the cert-manager gateway shim on the member, not propagation, which
managedFieldsshows directly. That was established on this thread and is confirmed: the propagation policy carries noCertificateselector, and no Karmada work object carries one.What this means for the plan recorded here
The plaintext listener item was justified by the ACME request having nothing to attach to at the edge. Issuance completing 39 times this month says the request does arrive, so that item needs re-deriving from a working challenge before anyone builds on it.
The availability items stand on their own merit rather than as outage recovery. A single fleet-wide pipeline running one replica of each controller is worth fixing, and nothing alerts when issuance fails. Neither is a defect in this component and both belong in their own issues.