# kubectl certificate: Usage, Options & CI Errors

> kubectl certificate approves or denies CertificateSigningRequests. The node-bootstrap and custom-CSR flow, and the no-CSR and already-approved cases.

Source: https://latchkey.dev/learn/command-reference/kubectl-certificate  
Updated: 2026-06-25

Approve or deny pending certificate signing requests.

kubectl certificate approve/deny acts on CertificateSigningRequests (CSRs) - the requests nodes and clients make for signed certs. It appears in node-bootstrap automation and custom PKI flows.

## What it does

kubectl certificate approve NAME marks a pending CSR approved so the signer issues a certificate; deny rejects it. You typically list candidates with kubectl get csr first, then approve the matching ones. In managed clusters a controller auto-approves node CSRs; manual approval is for custom or kubelet-serving certs.

## Common usage

```Terminal
kubectl get csr
kubectl certificate approve csr-abc123
kubectl get csr -o name | xargs kubectl certificate approve   # bulk
kubectl certificate deny csr-suspicious
```

## Common errors in CI

"Error from server (NotFound): certificatesigningrequests.certificates.k8s.io \"X\" not found" usually means the CSR expired and was garbage-collected (CSRs are short-lived) before your automation approved it. Approve promptly or recreate. Approving an already-approved CSR is a no-op but reads as success; denying an approved one will not un-issue the cert. Bulk-approving every pending CSR with xargs is a security risk in untrusted clusters. Only auto-approve CSRs you can attribute to known requesters.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl certificate: Usage, Options & CI Errors?

kubectl certificate approve/deny acts on CertificateSigningRequests (CSRs) - the requests nodes and clients make for signed certs. It appears in node-bootstrap automation and custom PKI flows.

### What it does?

kubectl certificate approve NAME marks a pending CSR approved so the signer issues a certificate; deny rejects it. You typically list candidates with kubectl get csr first, then approve the matching ones. In managed clusters a controller auto-approves node CSRs; manual approval is for custom or kubelet-serving certs.

### Common errors in CI?

"Error from server (NotFound): certificatesigningrequests.certificates.k8s.io \"X\" not found" usually means the CSR expired and was garbage-collected (CSRs are short-lived) before your automation approved it. Approve promptly or recreate.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt