Re: Reason why we do not set rigthca in the strongswan conf

[Jonatan Schlag <jonatan.schlag@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]


Hi,

> Am 12.02.2025 um 10:26 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
> Hello Jonatan,
> 
> That is a good question. I am aware of the certificate pinning problem that we have here and that we cannot easily just roll over the host certificate (which 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 easier.
> 
> Long term, I would like to think how to move away from X.509 for IPsec, but that is a story for another day.

Because the work of maintaining a certificate is too much? Or what are the reasons? I only need a short explanation. If there is a better alternative to implement then certificates, I’m happy to use this one. And we both don’t need to turn further time into how this strongswan feature works.
> 
> What are the disadvantages of just using the CA? I suppose there is the problem that most people don’t use the FQDN of the remote side to establish their connections. Very often, the firewall does not even have a proper FQDN 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’s subject/hostname.
> 
> Usually within IPFire, this should not be a problem because the CA is not issuing 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 certificates that might have been issued); or in case of a public CA like Let’s Encrypt, this could be a large chunk of the internet.
> 
The remote side id is also checked, isn’t it? So we could somehow pin to one certificate even if the hostname does not match. And if Let’s Encrypt provides you with a cert which has a subject alternative name set to something random, I would be very surprised.

> 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 is 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 suppose.

It’s kind of interesting. I’ve just read the documentation one more time and apparently you are supposed to set this option to the distinguished name of the certificate authority. I simply provided the file of my certificate authority certificate and it seems to work also. So we could set this relatively narrow, to the certificate authority we imported.

Jonatan

> 
> 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 here are not a concern at all; that would need to be tested. Are you up for that?


> 
> -Michael
> 
>> On 8 Feb 2025, at 20:50, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
>> 
>> Hi list,
>> 
>> recently I had to renew the host cert of my IPFire system for
>> strongswan. As we currently write:
>> 
>> rightcert =
>> 
>> into the config (see for this:
>> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/vpnmain.cgi;h=3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=refs/heads/master#l379
>> I have to change the cert of the remote system as well. Is there a
>> reason for this? When I use
>> 
>> rightca=
>> 
>> the connection works out of the box. Is there a reason why we make not
>> use of this option?
>> 
>> Jonatan