Android IKEv2 Trust Error: Send the Intermediate CA, Not a Root
The phone rejects the gateway because the chain it received stops early. Decide: send the intermediate, fix identity, or change the key type.
The phone refuses to connect and prints No trusted RSA public key found for vpn.example.net, while the same gateway certificate works from a laptop on the same network. The tempting move is to reissue the certificate. Before you do, work out which of three failures you have, because only one of them is about the certificate's contents. The message covers an incomplete chain, an identity mismatch, and an unsupported key or signature, and each has a different repair.
Three failures behind one message
Android builds a chain from the gateway certificate to the CA selected in the VPN profile, then checks the server name against the profile. The notification reports the outcome, not the stage. A trust failure means the chain could not be completed from the certificates delivered in the exchange; an identity failure means the chain validated but the name did not match; an algorithm failure means the device or profile does not accept the key type or signature.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Decide with evidence rather than by trying repairs in order. One attempt at log level 2 against the daemon tells you which row you are in, and it costs less than reissuing a certificate that was never wrong.
Decide first: did the whole chain arrive?
strongSwan sends the certificate configured for that connection, and intermediates are separate credentials. They have to be loaded as CA certificates before the daemon can place them in a payload, so a layout where the server certificate is signed by an intermediate, the root is the trust anchor, and the intermediate lives only in the CA's build directory produces exactly this failure: leaf alone on the wire, chain ending early on the phone.
Check what the daemon holds with swanctl --list-certs on a swanctl deployment, or ipsec listcerts with the older starter. The intermediate should appear as a CA certificate with the root above it. If it is missing, no client option will help; if it is present, move to the next question.
Then check whether it would be sent. The swanctl.conf reference documents send_cert, whose default ifasked sends certificates only when the peer has asked; always sends regardless. The legacy equivalent is leftsendcert=always in ipsec.conf. That setting controls sending, not availability, so it cannot compensate for an intermediate the daemon never loaded.
If the chain is short, load the intermediate where the daemon looks
Put the intermediate in the CA directory rather than beside the leaf: /etc/ipsec.d/cacerts for an ipsec.conf setup, /etc/swanctl/x509ca for swanctl, or the path your package substitutes. Reload the configuration and list the certificates again. Some versions will also send a bundle that contains the chain inside the leaf file, but the CA directory is the portable arrangement across versions and packages.
Verify from the client side as well. The phone only sees what the exchange carried, so the daemon log at level 2 should show the intermediate in the transmitted certificates. If the log shows it and the phone still fails, you are in a different row of the table, and continuing to adjust CA files will not move the outcome.
If the chain is complete, stop editing certificates
An identity failure is a mismatch between the name in the VPN profile and the name in the certificate. Android compares the server identity you configured against the certificate it validated, so a profile pointing at an address while the certificate names a hostname, or a profile naming a hostname the certificate does not cover, fails after a successful chain validation. Fix whichever side is wrong, and keep the profile and the certificate aligned when either changes.
An algorithm failure appears with a valid chain and a matching name. Android releases differ in which key types and signature schemes they accept, and the profile type itself constrains the options. If the gateway uses an older or unusual combination, compare it with what the device supports before assuming the certificate is corrupt. The daemon log will show the handshake progressing further than in the trust case, which is the signal that the chain is no longer the problem.
Do not install the intermediate as a user root on the phone
Installing the missing intermediate as a user certificate on the phone makes the warning disappear and changes the phone's trust model for every app that accepts user-installed roots. It also hides a delivery bug that will hit the next client, and it leaves the gateway sending an incomplete chain to every future device. The durable repair is at the server, once, for all clients.
Keep the three decisions separate in the change record: which certificates were transmitted, which identity was compared, and which algorithm was negotiated. A gateway that always sends its full chain, a profile that names the certificate correctly, and a key type the fleet supports are three small facts, and they are the whole of this failure.