Description of problem: When connecting to a previously created IKEv2 VPN connection, it is impossible to connect to it. It is always getting the "no trusted RSA public key found" when there is no certificate in the "Certificate" input box in the GUI and “Permission failed” when opening the given certificate file. Nevertheless, this connection is possible with SELinux in permissive mode. Version-Release number of selected component (if applicable): version 1.26.6-1.fc33 How reproducible: Steps to Reproduce: 1. Make sure you have SELinux in enforcing mode 2. Create a IKEv2 VPN connection 3. Insert the certificate file in the certificate input box 4. Connect to the VPN 5. Check the logs with "sudo journalctl -u NetworkManager.service" and check the end of the file for "Permission failed" Actual results: "Permission failed" or "no trusted RSA public key found" when no certificate is given. Expected results: The VPN connection should be established, with or without the certificate. Additional info: There has been a discussion about this bug before in the Ask Fedora forum at https://ask.fedoraproject.org/t/cannot-connect-to-ikev2-vpn-on-fedora-33-no-trusted-rsa-public-key-found/
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The bug still exists in Fedora 35
It seems to me a different way of pushing certificate to charon from userspace. I expect selinux failures are hit, because charon tries to read some certificates directly from file path in home. That would be usually ok for any root owned process, but SELinux policy prevents that. It seems NM plugin (or nm-plasma-strongswan plugin) should send contents of certificate, not the path of it to the system daemon. Then the daemon would have already everything it needs and would not require reading something from home directory, which got blocked.
I would need architecture change inside charon-nm service. But I don't think I am able to do this myself. Let's ask on upstream, maybe they would propose something simpler.
I think more people reported it on bug #1932473, where it is better explained. Let's do only one common bug for it. *** This bug has been marked as a duplicate of bug 1932473 ***