Issue with configuration of trusted reader/verifier certificates

[antonio-ivanovski]

I have used the configureReaderTrustStore method to configure trust in my reader certificate by adding a CA root certificate of verifier. However, even after this, the wallet still returns error for Invalid resolution: InvalidJarJwt(cause=Untrusted x5c)

Root CA certificate

-----BEGIN CERTIFICATE-----
MIICZTCCAgygAwIBAgIURa2ELYFO8EayqnT32mYIGbudt7YwCgYIKoZIzj0EAwMw
MDELMAkGA1UEBhMCVUsxDjAMBgNVBAoMBVZpZG9zMREwDwYDVQQDDAhWaWRvcyBD
QTAeFw0yNTEwMTAxNjA0MDhaFw0zNTEwMDgxNjA0MDhaMDAxCzAJBgNVBAYTAlVL
MQ4wDAYDVQQKDAVWaWRvczERMA8GA1UEAwwIVmlkb3MgQ0EwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAAQd8JTI8SPsSzRo7rY42A9PDnIJxWE+qfJERN+TDV9wTmEu
zLS73bDjOxo/sKpIIFhS09QrGWB6/fNBLVMoq84So4IBAjCB/zASBgNVHRMBAf8E
CDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUcWNXLdPGcBewKnfh
7UNcQfRKGnMwawYDVR0jBGQwYoAUcWNXLdPGcBewKnfh7UNcQfRKGnOhNKQyMDAx
CzAJBgNVBAYTAlVLMQ4wDAYDVQQKDAVWaWRvczERMA8GA1UEAwwIVmlkb3MgQ0GC
FEWthC2BTvBGsqp099pmCBm7nbe2MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjAuBgNVHRIEJzAlgQxjYUB2aWRvcy5jb22GFWh0dHA6Ly9wa2kudmlkb3Mu
Y29tLzAKBggqhkjOPQQDAwNHADBEAiBy9nE2L5DWtWbBpM9qsscUFuMpQ3mZyazB
nHo4OABlxQIgQUP3MORu2eRf8zBV+/Gbetranj81k9Ylub+EZbELJoo=
-----END CERTIFICATE-----

Certificate from the x5c header of the JWT Auhtorization Request:

MIIB0jCCAXegAwIBAgIUio2z4v8fCdW7k2KhOZN8OitkIxowCgYIKoZIzj0EAwIwMDELMAkGA1UEBhMCVUsxDjAMBgNVBAoMBVZpZG9zMREwDwYDVQQDDAhWaWRvcyBDQTAeFw0yNTEwMTAxNjM0MjVaFw0yNjEwMTAxNjM0MjVaMBsxGTAXBgNVBAMTEFZpZG9zQXV0aFNpZ25pbmcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARWrRP4YvSBTPtiuKIsHW9ei8uTD/x6VvD/pJ8ezhf6xkhcpXdgELgPDneUsy1YzLoFNiR11Rjuo4purHLwasCRo4GDMIGAMB0GA1UdDgQWBBRsmJbkj59iY6i8n7psqZ/hm9jIVTAfBgNVHSMEGDAWgBRsmJbkj59iY6i8n7psqZ/hm9jIVTAMBgNVHRMBAf8EAjAAMDAGA1UdEQQpMCeCJWJhcmVseS1jZXJ0YWluLW1hbW1vdGgubmdyb2stZnJlZS5hcHAwCgYIKoZIzj0EAwIDSQAwRgIhANDQl4UBlGxYK6ofGcarCQgXvHoPX0tonByK3Wwnfj0+AiEA0oaldYc1lGSVY+Kp2sQG+SX1JSipAHmHFvJ5AIsbVaU=

Local implementation based on node-forge or @peculiar/x509 is verifying the certificate chain successfully.

Also tried placing the trusted root ca certificate inside the x5c header, but still no success.

Can you please add explanation what are the exact requirements for the certificates to be considered trusted?

[dzarras]

Dear @vkanellopoulos,

Could you please take a look? Could the certificates be missing any of the required extensions per the X509 Profile we require?

Kind regards.

[antonio-ivanovski]

Dear @vkanellopoulos,

Could you please take a look? Could the certificates be missing any of the required extensions per the X509 Profile we require?

Kind regards.

Where can I see the x509 profile you require?

[antonio-ivanovski]

Gave another try with more accurate root certificate and leaf certificate, still no success:

Root cert:

-----BEGIN CERTIFICATE-----
MIIBajCCARCgAwIBAgIUKJn7JnTYmXNK+UDHdbeSCrENEdQwCgYIKoZIzj0EAwMw
EzERMA8GA1UEAwwIVmlkb3MgQ0EwHhcNMjUxMDIyMTM0MjA0WhcNMzUxMDIwMTM0
MjA0WjATMREwDwYDVQQDDAhWaWRvcyBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEH
A0IABKOgnB2jiq4+7aVY5oa1ZqikdiKie5+XnIaaiQgegsCeCQXcP/kZLczcJ+it
uKzuFs/NQYn3Si2027e/PpirBYqjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0P
AQH/BAQDAgIEMB0GA1UdDgQWBBTPorYy+nH+7owO5k+eNZ/NzSpIzjAKBggqhkjO
PQQDAwNIADBFAiBnBv93AXVsHH5wul7UvykXavisYEBVLQbPh4OErCQvmwIhAKkq
mHVLcYUqqBf5uP8S7Xz+vEwDGPwi0dM1Qiip/QsL
-----END CERTIFICATE-----

JWT:

eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWF1dGh6LXJlcStqd3QiLCJ4NWMiOlsiTUlJQnFEQ0NBVTJnQXdJQkFnSVVEMU5aZi9nTlNrYUF2TmNLaUNHa3FhZk45QTh3Q2dZSUtvWkl6ajBFQXdNd0V6RVJNQThHQTFVRUF3d0lWbWxrYjNNZ1EwRXdIaGNOTWpVeE1ESXlNVE0xTVRBeldoY05NalV4TVRJeE1UTTFNVEF6V2pBeU1Rc3dDUVlEVlFRR0V3SlZTekVPTUF3R0ExVUVDZ3dGVm1sa2IzTXhFekFSQmdOVkJBTU1Da3BYVkNCVGFXZHVaWEl3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVM5c3piQXF2bm9HSmJEK05YN3hRemxUWjQvZUdDV0Vtanh6OExEOEZHdG1jM2xyMW0wWmN6dWFRU09CUmtBamFzcExzOFhOM3JoNDUwZ3pPbk5rVGxNbzJBd1hqQU1CZ05WSFJNQkFmOEVBakFBTUE0R0ExVWREd0VCL3dRRUF3SUhnREFkQmdOVkhRNEVGZ1FVdUtwcE1DNHRyellHODRNeUpzRHFLUjc1dGVnd0h3WURWUjBqQkJnd0ZvQVV6NksyTXZweC91Nk1EdVpQbmpXZnpjMHFTTTR3Q2dZSUtvWkl6ajBFQXdNRFNRQXdSZ0loQU5xN2ZlU1pMbWkrdmhkSm1qQnZjNmtHbkZwL09TUXlUeTdWQ0dMZGIwSG5BaUVBb3VxYU5uSXZZdXRjTHJIejNWNEViNSt6dnJEei95VW5JMUVBQkJ6Z1pXTT0iXX0.eyJjbGllbnRfaWQiOiJ4NTA5X3Nhbl9kbnM6YmFyZWx5LWNlcnRhaW4tbWFtbW90aC5uZ3Jvay1mcmVlLmFwcCIsImNsaWVudF9tZXRhZGF0YSI6eyJhdXRob3JpemF0aW9uX2VuY3J5cHRlZF9yZXNwb25zZV9hbGciOiJFQ0RILUVTIiwiYXV0aG9yaXphdGlvbl9lbmNyeXB0ZWRfcmVzcG9uc2VfZW5jIjoiQTI1NkdDTSIsImNsaWVudF9uYW1lIjoiVmlkb3MiLCJjbGllbnRfdXJpIjoiaHR0cHM6Ly92aWRvcy5pZCIsImp3a3MiOnsia2V5cyI6W3siYWxnIjoiRUNESC1FUyIsImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiLCJ1c2UiOiJlbmMiLCJ4IjoiU1ZJaWVsekMtWV9hVThrMy11OHBJa0JCLVlJS3UzXzFTU2pvUVJsQlBCWSIsInkiOiJaMlc2bUlUR2Jub2oyQTFHTUE0cGVka3plYkVKZ3pMeS13SW1FOTdPeFhvIn1dfSwibG9jYXRpb24iOiJ2aWRvcy5pZCIsImxvZ29fdXJpIjoiaHR0cHM6Ly92aWRvcy5pZC9kb2NzL3ZpZG9zLWxvZ28tbG9uZy5zdmciLCJ2cF9mb3JtYXRzIjp7Imp3dF92cCI6eyJhbGciOlsiRVMyNTYiXX0sIm1zb19tZG9jIjp7ImFsZyI6WyJFUzI1NiJdfSwidmMrc2Qtand0Ijp7InNkLWp3dF9hbGdfdmFsdWVzIjpbIkVTMjU2Il0sImtiLWp3dF9hbGdfdmFsdWVzIjpbIkVTMjU2Il19LCJkYytzZC1qd3QiOnsic2Qtand0X2FsZ192YWx1ZXMiOlsiRVMyNTYiXSwia2Itand0X2FsZ192YWx1ZXMiOlsiRVMyNTYiXX19fSwibm9uY2UiOiJuLTMxNTdiYTU4LWY4ZTAtNDg2MC04MzMxLTdiNjg0NDgxNmEzYiIsImRjcWxfcXVlcnkiOnsiY3JlZGVudGlhbHMiOlt7ImlkIjoicXVlcnlfMCIsImZvcm1hdCI6ImRjK3NkLWp3dCIsIm1ldGEiOnsidmN0X3ZhbHVlcyI6WyJ1cm46ZXVkaTpwaWQ6MSJdfX1dfSwicmVzcG9uc2VfbW9kZSI6ImRpcmVjdF9wb3N0Lmp3dCIsInJlc3BvbnNlX3R5cGUiOiJ2cF90b2tlbiIsInJlc3BvbnNlX3VyaSI6Imh0dHBzOi8vYmFyZWx5LWNlcnRhaW4tbWFtbW90aC5uZ3Jvay1mcmVlLmFwcC9hdXRoL29wZW5pZDQvdnAvdjFfMC9hLWI2NmVmZDNmLTUxZmMtNDE2Ny1iZTgzLTMxMjc4YmJiZmRkMy9kaXJlY3RfcG9zdC5qd3QiLCJzdGF0ZSI6InMtZGI1MDdjMDYtNWI2NC00NDM0LTg4OGItZjRlZTBmOTdmZDk2IiwiYXVkIjoiaHR0cHM6Ly9iYXJlbHktY2VydGFpbi1tYW1tb3RoLm5ncm9rLWZyZWUuYXBwL2F1dGgvb3BlbmlkNC92cC92MV8wIiwiZXhwIjoxNzYxMTYwODM1LCJpYXQiOjE3NjExNTcyMzUsImlzcyI6Imh0dHBzOi8vYmFyZWx5LWNlcnRhaW4tbWFtbW90aC5uZ3Jvay1mcmVlLmFwcC9hdXRoIn0.ztDH1Pf8OwCneP9gTDqwVMvhVzZWsNKyTEyhauWur3qIBoLZakgZP3rYrop4hzdvUY5P6ZHX7Vn7p0rXlJdARQ

[kjcsb1]

Comment for GitHub Issue #230

We're experiencing the same InvalidJarJwt(cause=Untrusted x5c) error with publicly-trusted Let's Encrypt certificates.

Our Scenario

Environment:

• Library: eu.europa.ec.eudi:eudi-lib-android-wallet-core:0.20.0
• Certificate Authority: Let's Encrypt (public CA)
• Certificate Chain in x5c:
  • Leaf certificate (verifier's domain)
  • Intermediate: CN=E8, O=Let's Encrypt, C=US
  • Root: CN=ISRG Root X1 (not included in x5c, per RFC 7515 standard practice)

Configuration:

EudiWalletConfig {
    configureOpenId4Vp {
        withClientIdSchemes(
            listOf(
                ClientIdScheme.X509SanDns,
                ClientIdScheme.X509Hash
            )
        )
    }

    configureReaderTrustStore(
        context,
        R.raw.letsencrypt_isrg_root_x1,  // Let's Encrypt Root CA
        R.raw.letsencrypt_e8              // Let's Encrypt E8 Intermediate CA
    )
}

Testing Results

We systematically tested adding certificates to ReaderTrustStore:

1. Root CA only - Error persists
2. Root + Intermediate CA - Error persists
3. Root + Intermediate + Leaf certificate - Error persists

It seems that ReaderTrustStore configuration has no effect on OpenID4VP remote presentation JWT x5c validation.

Additional Evidence

TLS validation succeeds:

KtorHttpClient: checkServerTrusted: authType=GENERIC, chain size=2
KtorHttpClient: Cert 0: subject=CN=<verifier-domain>
KtorHttpClient: Cert 0: issuer=CN=E8,O=Let's Encrypt,C=US
KtorHttpClient: Cert 1: subject=CN=E8,O=Let's Encrypt,C=US
KtorHttpClient: Cert 1: issuer=CN=ISRG Root X1,O=Internet Security Research Group,C=US
EUDI Wallet: BODY Content-Type: application/oauth-authz-req+jwt
EUDI Wallet: Invalid resolution: InvalidJarJwt(cause=Untrusted x5c)

The Android system successfully validates the same certificate chain during the TLS handshake, but the library rejects it during JWT x5c validation.

Certificate verification:

• Certificates are valid (not expired)
• Chain structure is correct per RFC 7515
• ISRG Root X1 is in Android's default system trust store
• TLS validation succeeds with the same chain

Questions for EUDI Team

Following up on @dzarras's comment about X.509 profile requirements:

1. Where are the X.509 profile requirements documented?

   • What specific extensions are required?
   • Are there restrictions on key usage, extended key usage, or other certificate fields?

2. Why doesn't ReaderTrustStore apply to OpenID4VP remote presentation?

   • Is this by design or a bug?
   • Is there a separate configuration API for remote presentation trust anchors?

3. Does the library expect the complete chain including root in x5c?

   • RFC 7515 §4.1.6 states the root CA SHOULD be omitted from x5c
   • Most standard verifiers follow this practice
   • Does the library require non-standard behavior?

4. Is there any workaround for publicly-trusted CA certificates?

   • Can we configure the library to use Android's system trust store?
   • Is there an undocumented configuration option we're missing?

[antonio-ivanovski]

Got it working. The things missing were

• The leaf (signing) certificate needs to have valid AKI pointing to the issuer's SKI extensions
• Key usage of digital signature
• Not CA
• As mentioned in the Make a distinction between PresentationManager's and TransferManager's ReaderTrustStores #247 there is also requirement for the leaf certificate to have extended key usage needs to be mdlReaderAuth oid: 1.0.18013.5.1.6. This is probably

Suggestions:

• Configuration for allowing untrusted readers
• Clear documentation of what requirements needs to be fulfilled
• More descriptive error and stacktrace on what has failed

[mgiakkou]

Dear all,

Thank you for reporting this issue. We are looking into it and will come back to you ASAP with a relevant solution for that.

Thank you,
Michalis.