Skip to content

Add support for additional CAPI certificate context properties#873

Open
joshdrake wants to merge 13 commits intomasterfrom
josh/capi-set-cert-context-props
Open

Add support for additional CAPI certificate context properties#873
joshdrake wants to merge 13 commits intomasterfrom
josh/capi-set-cert-context-props

Conversation

@joshdrake
Copy link
Contributor

This PR adds functionality to the capi KMS to support setting the "friendly name" and "description" certificate properties. The tpmkms passes these through as needed.

💔Thank you!

@joshdrake joshdrake marked this pull request as draft October 14, 2025 02:25
@CLAassistant
Copy link

CLAassistant commented Oct 14, 2025

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ darkfronza
❌ joshdrake
You have signed the CLA already but the status is still pending? Let us recheck it.

@joshdrake joshdrake requested a review from hslatman October 14, 2025 02:25
@hslatman hslatman changed the title Josh/capi set cert context props Add support for additional CAPI certificate context properties Oct 14, 2025
Copy link
Contributor Author

@joshdrake joshdrake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One nit/question, otherwise lgtm. Need another reviewer to be able to merge, cc @hslatman

@joshdrake joshdrake force-pushed the josh/capi-set-cert-context-props branch from b78b8bb to 5505db4 Compare January 8, 2026 16:13
@darkfronza darkfronza marked this pull request as ready for review January 8, 2026 21:30
@joshdrake
Copy link
Contributor Author

Looks good to me, just need @maraino or @hslatman to take a quick look.

}

func certSetCertificateContextProperty(certContext *windows.CertContext, propID uint32, pvData uintptr) error {
r0, _, err := procCertSetCertificateContextProperty.Call(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is r0? I think this could use a more descriptive name.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually r1, this invokes a system call on windows (whose procedure is found in a DLL), the system call returns r1, r2, error, in general, where r1 represents the return value status from the procedure stored in a register (e.g. on Linux the %rax value), the semantic value of this depends on the procedure invoked, r2 is usually not used but kept for compatibility with platforms that return status on more registers, and the 3rd value return is actually an error, on windows the error is always non nil so we must check r0(r1).
I think we can leave this low level stuff as is, or perhaps considering refactor this in another pr.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that all makes sense. Can you add a comment to these funcs explaining it? With the information you provided above, it's clear, but without it, it's not clear what's happening.

Comment on lines +622 to +625
if r0 == 0 {
return err
}
return nil

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is err assumed to be non-nil here?

If err != nil, and r0 is != 0, is it ok to drop the error?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This invokes CertSetCertificateContextProperty which returns a bool, on success it returns true.
But since this is system call invocation the bool is cast to int, false is zero, so in that case we actually return the error.
We handle this as syscall on windows always return a non nil error even if the function succeeds

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the above, I think comments helps a lot here.

joshdrake and others added 11 commits March 24, 2026 14:30
This fixes an issue with agent, where it was unable to find device
certificates due to using a key-id derived from a random string for
certificate lookups.

If the key-id lookup fails automatically attempt lookup by cert+attr
where attr can be one of the certificate atributes, serial number,
friendly-name, description, etc.
The function was a relic from past refactoring code, not necessary
anymore.
- Wrong variable names.
- Added missing forwarding issuer,description,friendly-name params to CAPI.
- Document lookup by issuer strategy.
- Attempt lookup by issuer only when lookup by KeyID fails with not
  found, on error return.
- Simplify code a little bit.
If lookup by keyID or container fail and issuer+(serial|friendly_name)
or the other fields specified are provided, then attempt another
certificate lookup using those.
@darkfronza darkfronza force-pushed the josh/capi-set-cert-context-props branch from 59b1bc2 to b42b536 Compare March 24, 2026 17:46
darkfronza and others added 2 commits March 24, 2026 15:04
The serial object was updated to be *big.Int instead of string.
…otFoundError

Previously, any error from findCertificateBySubjectKeyID would cause an
immediate return, preventing the issuer-based fallback from running.
Now only non-NotFoundError errors (or NotFoundError when issuer lookup
is unavailable) are returned early.

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants