Server manager does not close properly
Describe the bug
The bundle org.eclipse.kura.http.server.manager does not close properly. At least in case of error with the certificate. If you remove the certificate localhost from the default Httpskeystore, the server goes into error and leave the endpoint on port 443 opened, preventing any further deployment of the web interface.
To Reproduce
Steps to reproduce the behavior (it is advisable to backup file /opt/eclipse/kura/user/security/httpskeystore.ks before this as it will be emptied during the test):
beware the web portal will be lost after the test until you restore the keystore file and restart Kura
- Remove localhost certificate from HttpsKeystore
- Check opened ports on the system
- Port 443 is still in use
- The port remains used until Kura is stopped
Expected behavior The server should get an error and be closed but the port should not be present, allowing a restart of the service once everything is fine again or it is restarted from the platform (Kapua).
Target Environment (please complete the following information):
- Raspberry Pi 4B
- OS version: raspbian
- Kura version: 5.0.1
Additional context This test was found when the localhost certificate was being updated. At some time any user should do this and will find the issue it he does not want to restart Kura
There is a workaround possible by stopping the bundle prior to the critical operation and starting it again after it. Make sure you have remote access to the device via Kapua or similar, as the web interface will get down after the stop
This issue is stale because it has been open for 60 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Wow! I don't think this issue should be closed without fixing it.
This issue is stale because it has been open for 60 days with no activity.
The issue remains on version 5.5.0, any update on this?
Hi there @pintify, thanks for pinging us.
Given this is not a common use-case scenario, the fix for this particular issue wasn't scheduled and thus remains a known issue in 5.5.0.
I don't think we have any reference in the docs about this but, from what I understand, the correct procedure for changing a certificate at runtime should be:
- upload the new certificate
- change the alias used by the web server
- restart
Hope this helps.
Thanks for the update and the new procedure. We are currently using the one I describe up in the issue: close manually and remotely the server manager prior to update the certificate.