From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Reason why we do not set rigthca in the strongswan conf Date: Wed, 12 Feb 2025 09:26:12 +0000 Message-ID: In-Reply-To: <47de53fca244e7ad2f5b780942ecf2192c49e3a7.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3563579449440284174==" List-Id: --===============3563579449440284174== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Jonatan, That is a good question. I am aware of the certificate pinning problem that w= e have here and that we cannot easily just roll over the host certificate (wh= ich we should be able to!) because it is pinned on the remote side. I did not= have time to look into this in detail, but simply accepting the CA would be = a good solution for this and potentially will make the configuration even eas= ier. Long term, I would like to think how to move away from X.509 for IPsec, but t= hat is a story for another day. What are the disadvantages of just using the CA? I suppose there is the probl= em that most people don=E2=80=99t use the FQDN of the remote side to establis= h their connections. Very often, the firewall does not even have a proper FQD= N that actually resolves to the right IP address at all; therefore I believe = that we cannot even perform any solid validation based on the certificate=E2= =80=99s subject/hostname. Usually within IPFire, this should not be a problem because the CA is not iss= uing that many certificates, but in theory it is possible to use a public CA.= Both problems put together would mean that the remote firewall will accept *= any* certificate that has ever been issued (even some road warrior certificat= es that might have been issued); or in case of a public CA like Let=E2=80=99s= Encrypt, this could be a large chunk of the internet. How does strongswan deal with incoming connections? Just because it has a CA = does not mean that it should find the right connection because this usually i= s found by the subject of the certificate. Does it simply iterate through all= CAs and go with anything that matches? That would be very broad as well I su= ppose. So in theory, I like the idea, just the CA should be enough. But I believe in= practice there might be some problems. Maybe some of the things I outlined h= ere are not a concern at all; that would need to be tested. Are you up for th= at? -Michael > On 8 Feb 2025, at 20:50, Jonatan Schlag wrote: >=20 > Hi list, >=20 > recently I had to renew the host cert of my IPFire system for > strongswan. As we currently write: >=20 > rightcert =3D >=20 > into the config (see for this: > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dhtml/cgi-bin/vpnmai= n.cgi;h=3D3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=3Drefs/heads/master#l379 > I have to change the cert of the remote system as well. Is there a > reason for this? When I use=20 >=20 > rightca=3D >=20 > the connection works out of the box. Is there a reason why we make not > use of this option? >=20 > Jonatan --===============3563579449440284174==--