tests: add name constraints integration test. #40
Conversation
This file contains 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
cpu
commented
Aug 9, 2023
Comment on lines
+129
to
+114
| // Note: We take the cheap way out here and assume single byte length - if the following | ||
| // assert fails we'll need to more intelligently encode the sequence DER length. |
There was a problem hiding this comment.
This is a little bit shoddy but I think probably sufficient for tests 🤷
cpu
commented
Aug 9, 2023
Comment on lines
+147
to
+132
| // We don't expect any excluded subtrees as this time. | ||
| assert!(constraints.excluded_subtrees.is_none()); |
There was a problem hiding this comment.
We could revisit this if it turns out that there will be trust anchors with name constraints including excluded subtrees. There aren't any today so I didn't bother complicating the testing harness to handle them.
cpu
force-pushed
the
cpu-name-constraint-integration-tests
branch
3 times, most recently
from
d817342
to
99c5e77
Compare
cpu
changed the title
djc
reviewed
Aug 9, 2023
This commit adds integration testing for trust anchors in webpki-roots with name constraints. The general idea is that for each name constraints extension we: * parse the name constraints with x509-parser, verifying that the encoding is well formed and contains something approximating what we expect (e.g. at least one permitted subtree, no excluded subtrees). * convert the name constraints into the form rcgen expects for certificate generation parameters. * issue our own trust anchor CA certificate with the name constraints from the webpki trust anchor. * for each permitted subtree base dns name in the name constraints we use our generated CA to issue end entity certificates that will be permitted, and rejected by the name constraints. * we then translate our issued CA back to a webpki trust anchor, and use webpki to verify each of the permitted and rejected end entity certificates, asserting the result matches what we expect for the name constraint.
cpu
force-pushed
the
cpu-name-constraint-integration-tests
branch
from
99c5e77
to
4c59e8a
Compare
djc
approved these changes
Aug 9, 2023
|
Going to merge this w/ one review since it's only test code. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a follow up to #39 that adds a basic integration test for trust anchors in webpki-roots with name constraints.
The general idea is that for each name constraints extension we:
Checking out v0.25.1 and backporting this test identifies a problem with the KamuSM root name constraint, finding no subtrees after parsing:
With the fix from #39 the test passes.