Last Modified: Aug 01, 2024
Affected Product(s):
F5OS F5OS
Fixed In:
F5OS-A 1.7.0, F5OS-A 1.5.2
Opened: Mar 01, 2023 Severity: 2-Critical
After setting a valid ECDSA curve type: prime256v1 X9.62/SECG curve over a 256 bit prime field secp384r1 NIST/SECG curve over a 384 bit prime field and storing into tls the self-signed certificate the GUI will show the certificate info for this URL. Going into the CLI and deleting the key and certificate: su admin config no system aaa tls config certificate no system aaa tls config key commit removes the ecdsa certificate and key and http-server is restarted with the default created rsa key and certificate. However, the GUI still has the deleted certificate and continues to use it despite doing a refresh or attempting to log in from another browser window. Looking at what happens under the covers, it shows that the ecdsa key and certfiicate are deleted and that httpd was restarted (all have new PID's). The problem seems to happen with ecdsa curves only and might be explained by either of the following: On linux operating systems, a file isn't completely deleted until the last referring program releases it. The browser caches the certificate if it's type ecdsa and does not release that cache right away. We notice that using the default rsa key and certificate seems to fail when the ecdsa is deleted, but after a 60 second timeout, the http-server recovers and everything seems back to normal. I could take a couple timeouts, meaning that two minutes must go by.
This can be a bit concerning, in that one expects the certificate to be replaced immediately once the key and certificate are removed. From an operational perspective, the flow does not seem to be affected as the webUI continues to work. Eventually the certificate type will no longer be the ECDSA type, but this can take a few minutes, perhaps longer.
After selecting an ECDSA key type (for curve type prime256v1 or secp384r1) and connecting successfully, the key and certificate are deleted from ConfD, resulting in having the http-server use a default created RSA key and certificate.
To hasten the fix, one can do: docker restart http-server, which usually fixes the issue right away, or a reboot will also accomplish this.
None