Stats
Actions
Tags
From hub-cert-tools
Assess the risk of changing hub cluster kube-apiserver certificates on clusters with ACM. Evaluates impact of certificate type changes, rotations, root CA changes, and intermediate CA changes. Provides risk analysis and mitigation guidance. Accepts --kubeconfig (optional, defaults to KUBECONFIG env var) and --new-cert (required) parameters.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hub-cert-tools:assess-hub-cert-changeThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill helps you assess the risk and impact of changing kube-apiserver certificates on OpenShift clusters with ACM installed. It compares your current certificate with a planned new certificate and provides step-by-step guidance for a safe transition.
This skill helps you assess the risk and impact of changing kube-apiserver certificates on OpenShift clusters with ACM installed. It compares your current certificate with a planned new certificate and provides step-by-step guidance for a safe transition.
When this skill is invoked:
Parse Arguments
--kubeconfig parameter (optional, defaults to KUBECONFIG env var)--new-cert parameter (required - path to new certificate file)--new-cert is missing, display error and usage instructionsValidate Inputs
Execute Assessment Workflow
bash <skill-dir>/scripts/assess-hub-cert-change.sh --kubeconfig <path> --new-cert <path>Present Results
IMPORTANT: Always include the full detailed procedure with all commands from the script output. Do NOT summarize the steps - users need the complete copy-paste-ready commands with:
ca-chain.crt, actual API FQDN)Present the procedure in formatted code blocks so users can easily copy and execute the commands.
DO NOT ADD: Pre-execution checklists, post-execution checklists, or other extra sections beyond what the script outputs. Present the assessment results and procedure directly.
--new-cert <path>
--kubeconfig <path>
KUBECONFIG environment variable# Set kubeconfig environment variable
export KUBECONFIG=/path/to/kubeconfig
# Run assessment with new certificate
/assess-hub-cert-change --new-cert /path/to/new-certificate.pem
# Run assessment with explicit kubeconfig and new certificate
/assess-hub-cert-change --kubeconfig /path/to/kubeconfig --new-cert /path/to/new-cert.pem
╔═══════════════════════════════════════════════════════════════╗
║ Hub Certificate Change Assessment ║
╚═══════════════════════════════════════════════════════════════╝
━━━ Current Certificate Configuration
Certificate Type: Custom Certificate (Well-Known CA)
Subject: CN=api.example.com
Issuer: CN=R3,O=Let's Encrypt,C=US
Root CA: CN=ISRG Root X1,O=Internet Security Research Group,C=US
━━━ ACM Status and Server Verification Strategy
Verification Strategy: Auto-Detected CA Bundle
━━━ Managed Cluster Status
All 3 managed clusters are AVAILABLE
━━━ Planned Certificate Change
New Subject: CN=api.example.com
New Issuer: CN=E1,O=Let's Encrypt,C=US
New Root CA: CN=ISRG Root X1,O=Internet Security Research Group,C=US
━━━ Change Assessment
What's changing:
• Root CA: No change
• Intermediate CA: Changing from R3 to E1
━━━ Risk Assessment
Risk Level: 🟢 LOW
Impact on ACM Hub:
• Certificate update requires API server restart
• Brief connection interruption during update
Impact on Managed Clusters:
• No impact with correct procedure
• Clusters remain AVAILABLE throughout
━━━ Recommended Procedure
Procedure: Simple Certificate Update
Step 1: Create the certificate secret
oc create secret tls api-server-cert --cert=new-cert.pem --key=/path/to/new-key.pem -n openshift-config
Step 2: Update APIServer configuration
oc patch apiserver cluster --type=merge -p '{"spec":{"servingCerts":{"namedCertificates":[{"names":["api.example.com"],"servingCertificate":{"name":"api-server-cert"}}]}}}'
Step 3: Verify managed clusters remain AVAILABLE
# Watch for 15 minutes and ensure all clusters show AVAILABLE=True
oc get managedclusters -w
═══════════════════════════════════════════════════════════════
The skill identifies and provides guidance for three main scenarios:
Based on the scenario and ACM configuration, the skill recommends one of four procedures:
Each procedure includes complete step-by-step instructions.
ACM supports three strategies for hub certificate verification. For detailed information about these strategies, see the check-hub-cert-config skill.
Quick Reference:
Invoke this skill when you need to:
oc CLI installed and configured1. Parse arguments (--kubeconfig, --new-cert)
↓
2. Validate inputs (files exist, certificates valid)
↓
3. Analyze current certificate (retrieve from cluster, determine type)
↓
4. Detect ACM configuration (check installation, get ServerVerificationStrategy)
↓
5. Analyze new certificate (extract chain, root CA)
↓
6. Compare certificates (determine scenario)
↓
7. Generate comprehensive report (risk + procedure)
Error: "Missing required argument: --new-cert"
--new-cert parameterError: "No kubeconfig specified"
--kubeconfig parameterError: "File does not contain a valid PEM certificate"
Warning: "Root CA not included in certificate chain"
Failed to analyze current certificate
oc whoaminpx claudepluginhub stolostron/claude-code --plugin hub-cert-toolsReviews cert-manager PKI configuration for Kubernetes clusters: Issuer/ClusterIssuer scope, CertificateRequestPolicy coverage, certificate SAN/duration risks, trust-manager bundle distribution, and cloud CA auth methods.
Request and manage x509 certificates in a Kube-DC project. Supports private CA (mTLS, internal, code signing) or public ACME. Auto-renewing, stores in a Kubernetes Secret.
Enforces TLS compliance on Kubernetes and OpenShift Ingresses, Routes, and Services. Audits TLS version, certificates, and post-quantum readiness.