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>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
