search

eu-digital-identity-wallet / eudi-lib-ios-siop-openid4vp-swift

Implementation of SIOPv2 and OpenID4VP protocols (wallet's role) in SWIFT
Apache License 2.0
4 stars 3 forks source link

Self Signed Certificates #70

Closed icarboneaq closed 3 weeks ago

icarboneaq commented 1 month ago

Hello, I'm attempting to issue and verify MDOC credentials besides MDL and am running into an issue around verifying the cert chain that is passed in the JWT's header during the OpenID4VP process. For the purposes of testing I am using self signed certificates that chain up to an untrusted root, and the service is expectedly treating it as untrusted. Openid4vp-Swift treats it as a 'recoverableFailure' and allows the presentation to continue, while Openid4vp-kt throws and error and ends the interaction. Is this intended?

It appears that the issue comes from here. Are there any plans to support self signed certificates in this way? I found some code in the EUDI demo wallet that allows for support of self signed certificates served by web servers, but not for this specifically.

dtsiflit commented 1 month ago

Hi @icarboneaq ! Using self-signed certificates should work fine for chain verification as long as each certificate is signed by the next one in the chain using its private key.

For a reference, you can see how this is handled in kit here.

Alternatively, you can supply your own CertificateTrust closure that returns true to bypass verification — just keep in mind this approach should only be used in non-production environments.

Hope this helps!

icarboneaq commented 1 month ago

So the CertificateTrust closure is I believe what I'm looking for, as I can provide logic to trust the self signed certs myself. I will try that and report back if I have an issue.

Just to confirm though when I pass in my self signed cert as a chain of length 1, the validation seems to fail. Based on your response, would you expect that to succeed? I just wanted to verify that there's not something else I can do with the default chain verification code?

dtsiflit commented 1 month ago

So the CertificateTrust closure is I believe what I'm looking for, as I can provide logic to trust the self signed certs myself. I will try that and report back if I have an issue.

Yes, this seems reasonable for your development.

Just to confirm though when I pass in my self signed cert as a chain of length 1, the validation seems to fail. Based on your response, would you expect that to succeed? I just wanted to verify that there's not something else I can do with the default chain verification code?

I'll have to do some research on my end in order to see exactly what is happening in this case and get back to you. I'll respond here.

dtsiflit commented 3 weeks ago

I ran a few tests and found that passing a single certificate to SecTrustCreateWithCertificates and evaluating it using SecTrustEvaluate results in .recoverableTrustFailure. It appears that with just one certificate, .recoverableTrustFailure is the best outcome we can expect 🙂.

According to the documentation, .recoverableTrustFailure suggests that while the chain cannot be fully trusted as is, it may be trusted with minor adjustments to the evaluation context, such as ignoring expired certificates or adding another trusted anchor.