On 6/24/25 11:32 PM, Mike Pattrick wrote:
> On Fri, Jun 20, 2025 at 2:54 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
>>
>> If started with --no-restart-ike-daemon, ovs-monitor-ipsec doesn't
>> clear the NSS database. This is not a problem if the certificates do
>> not change while the monitor is down, because completely duplicate
>> entries cannot be added to the NSS database. However, if the monitor
>> is stopped, then certificates change on disk and then the monitor is
>> started back, it will add new tunnel certificates alongside the old
>> ones and will fail to add the new CA certificate. So, we'll end up
>> with multiple certificates for the same tunnel and the outdated CA
>> certificate. This will not allow creating new connections as we'll
>> not be able to verify certificates of the new CA:
>>
>> # certutil -L -d sql:/var/lib/ipsec/nss
>>
>> Certificate Nickname Trust Attributes
>> SSL,S/MIME,JAR/XPI
>>
>> ovs_certkey_c04c352b u,u,u
>> ovs_cert_cacert CT,,
>> ovs_certkey_c04c352b u,u,u
>> ovs_certkey_c04c352b u,u,u
>> ovs_certkey_c04c352b u,u,u
>> ovs_certkey_c04c352b u,u,u
>> ovs_certkey_c04c352b u,u,u
>> ovs_certkey_c04c352b u,u,u
>>
>> pluto: "ovn-c04c35-0-out-1" #459: processing decrypted
>> IKE_AUTH request containing SK{IDi,CERT,CERTREQ,IDr,AUTH,SA,
>> TSi,TSr,N(USE_TRANSPORT_MODE)}
>> pluto: "ovn-c04c35-0-out-1" #459: NSS: ERROR:
>> IPsec certificate CN=c04c352b,OU=kind,O=ovnkubernetes,C=US invalid:
>> SEC_ERROR_UNKNOWN_ISSUER: Peer's Certificate issuer is not recognized.
>> pluto: "ovn-c04c35-0-out-1" #459: NSS: end certificate invalid
>>
>> Fix that by always checking certificates in the NSS database before
>> importing the new one. If they do not match, then remove the old
>> one from the NSS and add the new one.
>>
>> We have to call deletion multiple times in order to remove all the
>> potential duplicates from previous runs. This will be useful on
>> upgrade, but also may save us if one of the deletions ever fail for
>> any reason and we'll end up with a duplicate entry anyway.
>>
>> One alternative might be to always clear the database, even if the
>> --no-restart-ike-daemon option is set, but there is a chance that
>> we'll refresh and ask to re-read secrets before we got all the tunnel
>> information from the database. That may affect dataplane. Even if
>> this is really not possible, the logic seems too far apart to rely on.
>> Also, Libreswan 4.6 seems to have some bug that prevents re-adding
>> deleted connections if we removed and re-add the same certificate
>> (newer versions don't have this issue), so it's better if we do not
>> touch certificates that didn't actually change if we're not restarting
>> the IKE daemon.
>>
>> The clearing may seem redundant now, but it may still be useful to
>> clean up certificates for tunnels that disappeared while the monitor
>> was down. Approach taken in this change doesn't cover this case.
>>
>> Test is added to check the described scenario. The 'on_exit' command
>> is converted to obtain the monitor PID at exit, since we're now killing
>> one monitor and starting another.
>>
>> Fixes: fe5ff26a49f6 ("ovs-monitor-ipsec: Add option to not restart IKE
>> daemon.")
>> Reported-at: https://issues.redhat.com/browse/FDP-1473
>> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
>> ---
>>
>> Version 2:
>> * Changed the approach to compare existing NSS entry with the current
>> certificate instead of always removing and re-adding. This allows
>> to avoid a weird bug in Libreswan 4.6 where deleted connection
>> cannot be re-added if the certificate is removed and re-added.
>> This new version should also be slightly faster since we're most of
>> the time calling one external command (cert dump) instead of two
>> (delete + add).
>> * Tested with Libreswan 4.6, 4.9, 4.15, 5.1 and 5.2.
>>
>
> This looks accurate per the noted issues with the previous patch that
> you identified.
>
> Acked-by: Mike Pattrick <m...@redhat.com>
>
Thanks! Applied and backported down to 3.2.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
