Start implementing Pebble-based integration testing#74
Merged
Conversation
cpu
force-pushed
the
cpu-pebble_ci
branch
2 times, most recently
from
292aa93 to
150582e
Compare
djc
reviewed
Jan 27, 2025
Owner
djc
left a comment
djc
left a comment
There was a problem hiding this comment.
Cool stuff! Here's a first round of feedback.
djc
reviewed
Jan 28, 2025
Owner
djc
left a comment
djc
left a comment
There was a problem hiding this comment.
Looking good! I like the logging, but think you should use the structured logging capability tracing provides instead of stuffing everything into the message field.
Populate a tests/testdata directory with a PEM encoded CA certificate, a PEM encoded server certificate issued by the CA, and the PEM encoded private key for the server certificate. All of the above is generated by the `certgen.rs` example using `rcgen`. Run with: `cargo run --example certgen`
This commit adds an integration test using Let's Encrypt's pebble and pebble-challtestsrv utilities. Since it requires either building Go code from source, or downloading the pre-built binaries applicable for your arch, the test is disabled by default for `cargo test`. In CI, or once you've done the required setup, it can be invoked manually with `cargo test --test integration`. Once the test ACME server and challenge response server are ready, a test issuance is performed by: * Creating an ACME account, and order for "example.com" * Configuring a HTTP-01 challenge response using the pebble-challtestsrv * Finalizing the order and fetching the certificate chain * Using the Pebble issuer CA root to verify the issued certificate chain w/ rustls/webpki
This workflow runs with stable rust on ubuntu-latest. It downloads the latest available pebble and pebble-challtestsrv binaries, unpacks them into the pwd and runs the integration tests.
This makes it convenient to verify CI passes without needing to open a PR first.
djc
approved these changes
Jan 28, 2025
Owner
|
Great, thanks! |
Collaborator
Author
|
Thanks for the reviews :-) |
Owner
|
Going to do a followup, will tag you for review. 👍 |
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.
👋 Here's the start of some HTTP-01 integration testing w/ Pebble as the ACME CA, and the Pebble challenge test server serving mock DNS and the HTTP-01 response we populate from what instant-acme provides. It should be fairly straight forward to extend to testing other challenges, and different protocol features (e.g. errors with subproblems, ARI, cert profiles) but I wanted to get the minimum viable implementation up for review before going too far. WDYT?
So far a test issuance is performed by:
pebble-challtestsrv