kubernetes/kops · error

unable to find created certificate

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.

Solutions

  1. Inspect the keystore backend for the cluster and confirm the write path actually persists keysets (check permissions, bucket/object store health).
  2. Re-run kops with a different --target or phase to force re-render and see if the keystore write succeeds.
  3. Check for concurrent kops runs against the same cluster that could overwrite or hide the newly stored keyset.
  4. 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

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

Related errors


AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/d999927087dee09b. Report an issue: GitHub.

Appendix: 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)