Bug 1945885

Summary: strongSwan - IKEv2 VPN connection "no trusted RSA public key found"
Product: [Fedora] Fedora Reporter: Miguel Santana <mikeytsantana>
Component: NetworkManager-strongswanAssignee: Petr Menšík <pemensik>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 35CC: code, jan.public, mikhail.zabaluev, pemensik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-08 21:37:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miguel Santana 2021-04-02 13:11:08 UTC
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/

Comment 1 Ben Cotton 2021-11-04 13:56:31 UTC
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.

Comment 2 Ben Cotton 2021-11-04 14:25:52 UTC
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.

Comment 3 Ben Cotton 2021-11-04 15:23:32 UTC
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.

Comment 4 Miguel Santana 2021-11-06 17:35:56 UTC
The bug still exists in Fedora 35

Comment 5 Petr Menšík 2021-11-08 19:26:26 UTC
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.

Comment 6 Petr Menšík 2021-11-08 21:29:21 UTC
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.

Comment 7 Petr Menšík 2021-11-08 21:37:47 UTC
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 ***