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

  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.