fix: reject CA startup when commonName collides with issuer certificate CN#2621
Open
FlorianGross wants to merge 1 commit intosmallstep:masterfrom
Open
fix: reject CA startup when commonName collides with issuer certificate CN#2621FlorianGross wants to merge 1 commit intosmallstep:masterfrom
FlorianGross wants to merge 1 commit intosmallstep:masterfrom
Conversation
…suing CA certificate's CommonName, any certificate signed by that CA will have Subject == Issuer and be treated as self-signed by TLS stacks and validators, causing handshake failures and trust errors. Added validateCommonNames() which is called during authority initialization (SoftCAS path) after the intermediate certificate chain is loaded. It returns a clear error message pointing to the misconfiguration, covering both the top-level commonName field (used for the CA's own TLS cert) and the authority.template.commonName field (used as the default subject CN for issued leaf certificates).
github-actions
bot
added
the
needs triage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Name of feature:
Startup validation: reject configuration when commonName or authority.template.commonName collides with the issuing CA certificate's CommonName
Pain or issue this feature alleviates:
When config.commonName or authority.template.commonName in ca.json is set to the same value as the intermediate CA certificate's CommonName, all affected certificates will have Subject == Issuer. TLS stacks and certificate validators interpret this as a self-signed certificate, causing handshake failures and trust errors — even though the certificate chain is technically correct. The root cause is difficult to diagnose because the error appears on the client side (e.g. PowerShell: "Could not establish trust relationship for the SSL/TLS secure channel") and nothing in the CA log indicates a misconfiguration.
Why is this important to the project:
The misconfiguration is easy to make (especially when setting up step-ca manually without step ca init) and produces a silent, hard-to-diagnose failure. A clear startup error pointing directly to the problematic field saves significant debugging time.
Is there documentation on how to use this feature? If so, where?
No documentation needed — the feature is a startup guard that emits a self-explanatory error message and exits. The error message itself contains the corrective action:
"use a distinct name or leave commonName empty to use the default"
"use a distinct name or remove authority.template.commonName"
In what environments or workflows is this feature supported?
All SoftCAS deployments (default step ca init setup). Validation runs during authority.init() after the intermediate certificate chain is loaded.
In what environments or workflows is this feature explicitly NOT supported (if any)?
External CAS deployments (CloudCAS, StepCAS/RA mode) — in those cases the intermediate certificate is not loaded locally, so the check is skipped.
The PR and the commit was created using Claude AI.