Repository navigation
Conversation
…ped through The check was a substring test on the RFC4514 form of the CSR subject and did not look at the signature at all. Both matter more than they look. The subject test accepted a CSR whose CN merely started with the callsign (CN=OTTER1X for OTTER1), and accepted one that carried the callsign in some other attribute while the real CN was something else entirely (OU=CN=OTTER1,CN=ADMIN). The CA signs the request as presented and the mTLS edge authorises on the CN it reads from the certificate, so the second case issues a working identity for a callsign the requester was never granted. Compare the parsed CN attributes instead, and require exactly one equal to the callsign. Other attribute types are still allowed: an MDM filling a subject template may add O or OU and nothing downstream reads them. The missing signature check meant we had no proof the requester held the private key. Worse, an unverifiable request was still passed to the CA, which rejects it only after Person.create_with_cert has committed the Person row, spending that callsign for good. Adds tests/test_csr_utils.py. Every negative case in it was accepted before.
CN=OTTER1X passed for OTTER1, and OU=CN=OTTER1,CN=ADMIN passed while the cert the CA issued said ADMIN. Now compares parsed CN attributes, and checks the signature so an unverifiable request never reaches the CA.
…on-rasenmaeher-api into fix/verify-csr-exact-subject
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
1 participant
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.
Description
verify_csrmatched the callsign as a substring of the rendered RFC4514 subject and never checkedthe request signature.
Old behavior:
CN=OTTER1XOTTER1OU=CN=OTTER1,CN=ADMINOTTER1CN=ADMINThe CA signs the request as presented and the mTLS edge authorises on the CN it reads from the certificate, so it may issue a working identity for a callsign the requester was never granted if so asked.
The missing signature check means we have no proof the requester holds the private key, and an
unverifiable request is still handed to the CA. The CA rejects it only after
Person.create_with_certhas already committed the Person row, so the callsign is spent for good.Now it compares the parsed CN attributes and requires exactly one equal to the callsign, plus
csr.is_signature_valid. Attributes other than CN are still allowed: an MDM filling a subjecttemplate may add O or OU, and nothing downstream reads them.
tests/test_csr_utils.pyAnything Else You'd Like to Mention
Groundwork for MDM driven device enrolment, where a certificate request is approved without a human
looking at it and this becomes the only subject gate before the CA signs.