Repository navigation
Send a placeholder subject in the certificate signing request - #199
Merged
mengqiy merged 1 commit intoOct 18, 2026
Merged
Conversation
STS does not parse the CSR, so the subject passes through to the signer, and the signer rejects a blank one. Every X.509-SVID issuance therefore fails against the current stack, because buildCSR sent an empty pkix.Name. Set a fixed common name instead. The value names the agent rather than the workload on purpose: the agent does not choose the identity, so a common name that looked like one would claim it does. The SPIFFE ID still comes only from the attested session, and the request continues to carry no SAN and no extensions. This is temporary. STS intends to overwrite the subject with an empty value and mark the SAN extension critical itself, which is what makes a certificate with no subject SPIFFE compliant; that change is blocked on the signer's own validation. Any subject works until then and is ignored afterwards, so this is forwards compatible and the constant should be deleted once STS overwrites it. buildCSR keeps its signature, since the value is fixed and needs nothing from the workload. Its doc comment claimed STS ignores the subject and SAN in the request, which is not true of either; it now states the invariant that holds, that the request names no identity. TestBuildCSRCarriesNothingButTheKey is renamed to TestBuildCSRNamesNoIdentity, as the request is no longer nothing but the key, and now pins the exact subject so an extra attribute fails. Its other assertions are unchanged.
adp-825
force-pushed
the
adpotdar/add-subject-name-to-csr
branch
from
October 18, 2026 05:38
fd5cb73 to
86bad81
Compare
mengqiy
approved these changes
Oct 18, 2026
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
2 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.
X.509-SVID issuance fails against the current STS stack:
buildCSRsent anempty
pkix.Name, and since STS does not parse the CSR, that empty subjectreaches the signer, which rejects it.
Set a fixed common name,
eks-workload-identity. It names the agent ratherthan the workload on purpose — the agent does not choose the identity. The
SPIFFE ID still comes only from the attested session, and the request still
carries no SAN and no extensions.
Temporary: STS will overwrite the subject with an empty value and mark the SAN
extension critical itself (blocked on the signer's validation). Any subject
works until then and is ignored afterwards, so delete
csrSubjectCommonNameonce that ships.
Also:
buildCSR's doc comment claimed STS ignores the subject and SAN, whichis what made the empty subject look safe — corrected.
TestBuildCSRCarriesNothingButTheKeyis renamed toTestBuildCSRNamesNoIdentityand now pins the exact subject; its other assertions are unchanged.