kubernetes/kops · error
unable to find created certificate %q: %w
Error message
unable to find created certificate %q: %w
What it means
In the keypair task's Render, after storing a new certificate the code re-reads the keyset from the keystore to make sure it round-trips. If FindKeyset returns nil (not found) the task returns this error, meaning the certificate that was just created cannot be read back from the keystore.
Source
Thrown at upup/pkg/fi/fitasks/keypair.go:235
Type: e.Type,
Subject: *subjectPkix,
AlternateNames: e.AlternateNames,
}
keyset, err := CreateKeyset(ctx, c.T.Keystore, name, req)
if err != nil {
return fmt.Errorf("error creating certificate: %v", err)
}
if err := e.setResources(keyset); err != nil {
return fmt.Errorf("error setting resources: %v", err)
}
// Make double-sure it round-trips
if roundtrip, err := c.T.Keystore.FindKeyset(ctx, name); err != nil {
return err
} else if roundtrip == nil {
return fmt.Errorf("unable to find created certificate %q: %w", name, err)
}
klog.V(8).Infof("created certificate with subject %v", subjectPkix)
}
// TODO: Check correct subject / flags
if changeStoredFormat {
// We fetch and reinsert the same keypair, forcing an update to our preferred format
// TODO: We're assuming that we want to save in the preferred format
keyset, err := c.T.Keystore.FindKeyset(ctx, name)
if err != nil {
return err
}
if keyset == nil {
return fmt.Errorf("keyset %q not found", name)
}
View on GitHub (pinned to 4c8573c808)
Solutions
- Inspect the keystore backend for the cluster and confirm the write path actually persists keysets (check permissions, bucket/object store health).
- Re-run kops with a different --target or phase to force re-render and see if the keystore write succeeds.
- Check for concurrent kops runs against the same cluster that could overwrite or hide the newly stored keyset.
- If using a custom keystore, verify FindKeyset returns stored keysets immediately after StoreKeyset.
Example fix
// before (custom keystore may not see uncommitted writes)
roundtrip, err := c.T.Keystore.FindKeyset(ctx, name)
// after: ensure StoreKeyset is committed before re-reading, or add retry
roundtrip, err := c.T.Keystore.FindKeyset(ctx, name)
if roundtrip == nil {
time.Sleep(100 * time.Millisecond)
roundtrip, err = c.T.Keystore.FindKeyset(ctx, name)
} Defensive patterns
Strategy: validation
Validate before calling
ks, err := keystore.FindKeyset(ctx, name)
if err != nil { return err }
if ks == nil { return fmt.Errorf("keyset %q missing before render", name) } Type guard
if keyset == nil { return fmt.Errorf("keyset %q not found", name) } Try / catch
if err != nil { return fmt.Errorf("verifying created certificate %q: %w", name, err) } Prevention
- Do not run concurrent kops updates against the same cluster
- Back up the state-store pki directory before applying changes
- Verify keystore backend persistence after StoreKeyset in custom implementations
When it happens
Trigger: Render creates a certificate for a keypair, stores it, then the immediate verification call c.T.Keystore.FindKeyset(ctx, name) returns nil — i.e. the write did not persist or is invisible to subsequent reads.
Common situations: Broken or misconfigured keystore backends (e.g. a VFS/CSI keystore that silently drops writes), racing processes writing the same keyset, or a custom keystore implementation whose FindKeyset does not see freshly stored keysets.
Understand the failure class
- SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
Related errors
- unable to issue certificate: %v
- unknown CA %q
- reading %q certificate: %v
- error issuing certificate: %v
- certificate %q not found
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/d999927087dee09b.
Report an issue: GitHub.