Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CDH: fail to get token due to non-existence of certificate chain #858

Open
hashimotor-ntt opened this issue Dec 27, 2024 · 1 comment
Open
Labels
bug Something isn't working

Comments

@hashimotor-ntt
Copy link

Describe the bug

Requesting a token by CDH failed with the log:

[2024-12-09T06:13:30Z ERROR ttrpc_aa::server] AA (ttrpc): get token failed
RCAR handshake failed: Unable to get token. RCAR handshake retried 5 times. Final attempt failed with: RCAR handshake failed: KBS attest unauthorized, Error Info: ErrorInformation { error_type: "https://github.com/confidential-containers/kbs/errors/AttestationFailed", detail: "Attestation failed: status: Aborted, message: "Attestation: Verifier evaluate failed: Cert chain is unset", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Mon, 09 Dec 2024 06:13:30 GMT", "content-length": "0"} }" }

whilst the host already has that cert chain (ARK, ASK, and VCEK) installed by sev-host-set-cert-chain, CDH could find the chain like the other tools do, otherwise, any alternative ways to register the chain might be provided.

How to reproduce

  1. Install and invoke CVM with CDH.
  2. Run the SKR flow.

CoCo version information

CoCo v0.9.0

What TEE are you seeing the problem on

Snp

Failing command and relevant log output

No response

@hashimotor-ntt hashimotor-ntt added the bug Something isn't working label Dec 27, 2024
@fitzthum
Copy link
Member

We support two ways of setting the cert chain.

  1. User/admin downloads the cert chain on the host and puts it at a specific path on the host filesystem (default location is /opt/snp/cert_chain.cert). The kata runtime will then supply this to QEMU when starting the guest. This does not work with the upstream kernel/QEMU, but it does work with the version that we are using with CoCo today.

  2. Trustee requests the cert chain from the KDS when it goes to validate the request. This was introduced in verifier: Fetch VCEK cert from KDS instead of bailing trustee#555. You might need to update to pick up this change.

We could add an option for the guest to contact the KDS, but these two existing options have worked fine so far.

Note that when we talk about the cert chain, we are really just talking about the VCEK, because Trustee has the ARK/ASK hard-coded in it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants