Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: When attempting to establish a VPN connection using strongswan and NetworkManager, journalctl shows that charon-nm is looking for certificates in /usr/share/ca-certificates where as the correct place, according to https://docs.fedoraproject.org/en-US/quick-docs/using-shared-system-certificates/ is /usr/share/pki/ca-trust-source/anchors/ Version-Release number of selected component (if applicable): strongswan-5.9.0-1.fc32.x86_64 How reproducible: Always Steps to Reproduce: 1. Define a new strongswan ipsec VPN connection intended to use a shared system certificate, with the certificate added as per https://docs.fedoraproject.org/en-US/quick-docs/using-shared-system-certificates/ 2. Try to establish the ipsec VPN connection Actual results: The connection fails, with the journal reporting "opening directory '/usr/share/ca-certificates' failed: No such file or directory" Expected results: The VPN connection is established correctly. Additional info:
Thank you. This is bug #1504016 revisited. A concern raised in that bug was that CAs automatically trusted for VPN should not be, as a general rule, commingled with system-wide trust anchors used for web and the like. Note also that the system policy stipulates that /etc/pki/ca-trust/source/anchors/ should be considered in preference to the directory under /usr/share, but the charon-nm settings only allow a single directory to be configured for the lookup. So for complete compliance, charon-nm needs to be patched.
That is extremely unfortunate. Where am I supposed to put the certificate then? Keeping it in my home directory and manually selecting the certificate while defining the VPN connection does not work either, because charon-nm can't read the file. Something here appears broken.
certificates are supposed to be placed in /etc/strongswan/ipsec.d/certs/ CA certificates in /etc/strongswan/ipsec.d/cacerts/ private keys in /etc/strongswan/ipsec.d/private/ I'm not sure which part of charon is looking in /usr/share/ca-certificates/ but I suspect it is the openssl code. It should surely NOT be picking up CAcertificates from the system's WwebPKI store for VPN usage.
(In reply to iolo from comment #2) > That is extremely unfortunate. Where am I supposed to put the certificate > then? The directory is configurable in strongswan.conf or strongswan.d/*.conf: charon-nm { ca_dir = /etc/strongswan/ipsec.d/cacerts } > Keeping it in my home directory and manually selecting the certificate > while defining the VPN connection does not work either, because charon-nm > can't read the file. Something here appears broken. I think there is an architectural disagreement between strongswan developers assuming that an arbitrary file path can be passed from the UI to be opened by the charon-nm daemon, and Fedora SELinux policies locking the daemon down to prevent it from accessing users' home directories and the like. A proper way to fix this would likely require changes in the NetworkManager plugin, the charon-nm daemon, and possibly other places.
(In reply to Paul Wouters from comment #3) > I'm not sure which part of charon is looking in /usr/share/ca-certificates/ The location used by charon-nm is defined in the code and can be changed by the --with-nm-ca-dir configure option.
After creating the file /etc/strongswan/strongswan.d/charon-nm.conf with the contents charon-nm { ca_dir = /etc/strongswan/ipsec.d/cacerts } followed by putting the certificate in that ca_dir, and then rebooting, I was able to get my IPsec VPN working. If this is the right directory to put CA certificates in, then that should probably be reflected in the default configuration. Many thanks Mikhail and Paul for you help!
FEDORA-2020-140ccee40b has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-9d19f63e99 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d19f63e99
FEDORA-2020-9d19f63e99 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9d19f63e99` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9d19f63e99 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-9d19f63e99 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-3ae0a4b75d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ae0a4b75d
FEDORA-2020-3ae0a4b75d has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3ae0a4b75d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ae0a4b75d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-3ae0a4b75d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.