Use custom certificates for the agent too

[ansasaki]

Previously, the agent supported only RSA key/certificate as the mTLS key because it was also used to encrypt data in the secure payload mechanism.

With keylime/rust-keylime#1129, the agent is now able to use different algorithms for mTLS.

Summary by Sourcery

Enable functional tests to generate and configure custom agent certificates for mTLS using the specified cryptographic algorithm

Tests:

• Generate agent key pair with CRYPTO_ALG instead of default RSA
• Sign the agent certificate with the intermediate CA
• Copy agent certificate and key into the test certificate directory
• Update agent configuration in tests to reference full paths for the server_cert and server_key

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

This PR extends the basic attestation functional test script to generate, sign, install, and configure a custom‐algorithm certificate/key pair for the agent (previously commented out), ensuring mTLS uses the new certificates.

File-Level Changes

Change	Details	Files
Extended test.sh to fully support agent certificate generation with custom algorithms	Added explanatory comment for agent certificate purpose Uncommented and parameterized x509KeyGen for agent with CRYPTO_ALG Replaced self-sign with x509CertSign via intermediate-ca for agent	functional/basic-attestation-with-custom-certificates/test.sh
Enabled copying of agent cert and key into CERTDIR	Uncommented cp commands for agent-cert.pem and agent-key.pem Aligned file placement with other component certificates	functional/basic-attestation-with-custom-certificates/test.sh
Updated agent mTLS config to use full CERTDIR paths	Prefixed server_key and server_cert values with ${CERTDIR} in limeUpdateConf Ensured agent config points to the correct file locations	functional/basic-attestation-with-custom-certificates/test.sh

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ansasaki]

/packit test

[ansasaki]

@Koncpa @kkaarreell I added a special treatment for the agent when using PQC due to https://issues.redhat.com/browse/RHEL-117439, could you please check if it is OK?

[ansasaki]

/packit retest-failed

[kkaarreell]

keylime_verifier[276837]: 2025-09-25 16:38:55.706 - keylime.tpm - ERROR - PCR #16: invalid bind data b7be84b9057e3f0c2041acf51a535af3a7c8c5a97468ae5950ae160d51d11996 from quote (from agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000) does not match expected value 7a1f3d06f9b9e1a9a818e0882aaad49cc160ebed428edfbf7d3cf85aea0ffebe

This is new to me (F42+Rawhide test results).

 [   FAIL   ] :: Command 'tail /var/tmp/limeLib/agent.log | grep 'Executing revocation action local_action_modify_payload'' (Expected 0, got 1)

This I can't explain as well, I can see the message in the agent's log. (Rawhide)
EDIT: I can, we are checking just last 10 lines, I will prepare a PR.
EDIT2: No, I can't, we are checking last 20 lines in fact :-(

[kkaarreell]

 [   FAIL   ] :: Command 'tail /var/tmp/limeLib/agent.log | grep 'Executing revocation action local_action_modify_payload'' (Expected 0, got 1)

This I can't explain as well, I can see the message in the agent's log. (Rawhide)
EDIT: I can, we are checking just last 10 lines, I will prepare a PR.
EDIT2: No, I can't, we are checking last 20 lines in fact :-(

So I did some cosmetic changes in #901 and I am not seeing the failure there. Still, it doesn't really explain why this is happening.

[ansasaki]

keylime_verifier[276837]: 2025-09-25 16:38:55.706 - keylime.tpm - ERROR - PCR #16: invalid bind data b7be84b9057e3f0c2041acf51a535af3a7c8c5a97468ae5950ae160d51d11996 from quote (from agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000) does not match expected value 7a1f3d06f9b9e1a9a818e0882aaad49cc160ebed428edfbf7d3cf85aea0ffebe

This is new to me (F42+Rawhide test results).

 [   FAIL   ] :: Command 'tail /var/tmp/limeLib/agent.log | grep 'Executing revocation action local_action_modify_payload'' (Expected 0, got 1)

This I can't explain as well, I can see the message in the agent's log. (Rawhide) EDIT: I can, we are checking just last 10 lines, I will prepare a PR. EDIT2: No, I can't, we are checking last 20 lines in fact :-(

This also caught my attention. That PCR#16 is used to check that the payload encryption public key provided by the agent is extended to the PCR#16, which was kind of the binding mechanism to relate the public key with the TPM quote provided by the agent.

A related change I made was to separate the payload mechanism key from the mTLS key. I didn't see any problem doing that because the agent always re-registers itself at startup, meaning that in case of restart of the agent (that will make the agent to create a new ephemeral key for the payload mechanism), the new public key should be updated in the registrar side, which should be used by the verifier to check the PCR#16.

I think the problem is that the verifier do not know that the agent restarted, and then checks the PCR#16 against the previous version of the public key. The information the verifier has would only be updated upon a re-enrollment using the tenant.

So, there are few ways to fix it (if it is the issue I described above):

1. Make the payload mechanism key persistent. Not difficult to do, but needs agent configuration changes. Will not prevent failures when the persisted key is removed. Speeds up initialization as there is no need to re-generate the payload keys during startup.
2. Modify the verifier to expect the key to change between attestations. Only requires changes to the verifier, supports ephemeral keys and keys removed between attestations.
3. Stop using the PCR#16 for this purpose completely, and use another mechanism to check the binding of the public key with the agent AK (TPM2_Certify). Supports keys removed between attestations, and also supports ephemeral keys. This is kind of a breaking change, but it is the best semantically. Can be done in multiple steps, first as an optional alternative to check the public key, then later completely replacing the PCR#16 usage

For me, the best self-contained fix is number 1, with changes only to the agent, without any other visible changes to the rest (it would return the behavior as it was prior to the changes). Then, number 2 could be implemented for best resilience in the verifier side. Number 3 is actually the best solution overall, and proposed a number of time already in many opportunities. One thing to weigh here is if we should really invest this amount of effort to keep the payload delivery mechanism alive when it is not even planned to be implemented for the push attestation agent.

[ansasaki]

 [   FAIL   ] :: Command 'tail /var/tmp/limeLib/agent.log | grep 'Executing revocation action local_action_modify_payload'' (Expected 0, got 1)

This I can't explain as well, I can see the message in the agent's log. (Rawhide)
EDIT: I can, we are checking just last 10 lines, I will prepare a PR.
EDIT2: No, I can't, we are checking last 20 lines in fact :-(

So I did some cosmetic changes in #901 and I am not seeing the failure there. Still, it doesn't really explain why this is happening.

This one I do not understand, sorry.

[kkaarreell]

/packit test

[kkaarreell]

I would also avoid changing payload mechanism. We need to keep it compatible with older releases so the current functionality would have to remain anyway.
Would you have an explanation why the issue is not visible on F41 and C10S?

[ansasaki]

I would also avoid changing payload mechanism. We need to keep it compatible with older releases so the current functionality would have to remain anyway. Would you have an explanation why the issue is not visible on F41 and C10S?

To be honest, the explanation I gave above still needs confirmation. I don't know why it is not visible there, but it is visible for fedora > 42.

EDIT: The confirmation is not difficult. It would be enough to:

• Start verifier, registrar, agent; then add the agent to the verifier with the tenant
• Stop the agent while being attested and then start again (quick enough so that the verifier does not give up)
• If my theory is correct, the attestation will fail due to the new payload key hash extended into PCR#16

[kkaarreell]

EDIT: The confirmation is not difficult. It would be enough to:
* Start verifier, registrar, agent; then add the agent to the verifier with the tenant
* Stop the agent while being attested and then start again (quick enough so that the verifier does not give up)
* If my theory is correct, the attestation will fail due to the new payload key hash extended into PCR#16

Event though the failure seems to be quite reliable in CI I wasn't equally successful in trying to reproduce it on my test system. I think that the timing is crucial here.

[ansasaki]

/packit test

[kkaarreell]

@ansasaki Hi, can we merge it? Test results looks good now. Thank you.