On 12:38 Mon 27 Aug , Apollon Oikonomopoulos wrote: > So, it turns out ganeti's internal CA is using SHA1 to sign all > generated certificates, which - by the looks of it - is not acceptable > by OpenSSL 1.1. > > I'll need some time to investigate and see how we should handle this.
The good news is that it's pretty straightforward to get Ganeti to issue SHA256-signed certificates. The bad news is that this will need a cluster-wide crypto material renewal (CA cert + client certs) using `gnt-cluster upgrade', which must be performed *after* installing the updated package on *all* nodes and cannot be done as part of a maintainer script (and thus can't be properly sequenced using Breaks). I still need to investigate the following bits: - Whether I can get ganeti-luxid to use SECLEVEL=1 so that it won't refuse to load the existing client certificates and thus won't cause breakage during the time after the package installation and before gnt-cluster upgrade. A quick look here says that this is not possible, since libcurl seems to set the cipher list (which is used to piggy-back security level information) *after* loading the client certificates[1]. Using curl(1) confirms this as well. [1] https://github.com/curl/curl/blob/curl-7_61_0/lib/vtls/openssl.c#L2396 - Whether a cluster that doesn't work because of SECLEVEL=2 + SHA-1 certs can be restored simply by using `gnt-cluster renew-crypto --new-cluster-cert`, which will greatly simplify things. IOW, whether `gnt-cluster renew-crypto` works without using Ganeti's RPC. Finally, to ensure a smooth upgrade, SHA256 support must be backported to Stretch to allow users to upgrade their crypto material and upgrade to Buster without problems. Regards, Apollon
