Openfire 5.1.0 running on Devuan 5 (= Debian 13). Debian package installation from Openfire website. Java is openjdk 17.0.19 2026-04-21 from openjdk-17-jre-headless:amd64
Upgrade from 5.0.5 to 5.1.0 went fine. Got message “Your server is using legacy SHA1 key derivation for encrypted properties. Migrate to PBKDF2 for improved security.” after logging in to admin GUI.
Initiated migration to PBKDF2 via admin GUI as suggested. GUI did not report any problems.
After migration, GUI will not come up, neither HTTP not HTTPS. No listeners on 9090/tcp and 9091/tcp.
In fact, logs (file attached) show an “Unable to save XML properties”, “No file specified” exception after starting the migration. openfire.log (71,3 KB)
Thanks for the report, and the heads-up Daryl. Just dropping a message to let you know I’ve seen this and I’m digging into it today. My early suspicion is that it relates to how security.xml is handled during the migration, but I want to investigate properly before saying more. I’ll follow up here once I have something concrete.
The root cause was that the PBKDF2 migration generates a fresh random salt and records it
(together with the kdf=pbkdf2 setting) in conf/security.xml, then re-encrypts the
encrypted properties in the database with the new key. On your server, security.xml
could not be written at that point (that is the Unable to save XML properties / No file specified in your log): Openfire had already fallen back to an
in-memory-only copy of the security config, so the new salt and KDF setting were
silently lost, even though the database re-encryption went ahead and the tool reported
success.
After the restart, with no stored salt and the KDF back at its sha1 default, the
server could no longer decrypt the re-encrypted values, including the keystore password
(which is stored as an encrypted property). With the keystore unreadable, the admin
console could not start its listener, which is why there was nothing on 9090/9091.
The trigger underneath all of that was that conf/security.xml was empty or invalid
before the migration ran, which is what put Openfire into the in-memory fallback in the
first place. (For Daryl’s earlier question: the startup log line that names openfire.xml is itself misleading; the file that actually failed to load is security.xml. That wrong filename is corrected too.)