powered by Jive Software

Update Openfire 3.9.3.0 to 4.3.2.0

hello all
could you help me with some Openfire-Update?

Database: SQL-Server
VM-01: Server with Openfire 3.9.3.0 installed. Device communicates by XMPP-Messages.
Openfire run as Service.
Plugins used.

VM-02: Clone of VM-01 with the same Client/Server Certificates.
Device is booked under Sessions.
I can send XMPP-Messages in Swift, Device cannot answer.
It can be Cert-Problem.

Update on VM-02:
Using bundled (32-Bit) Installer openfire_4_3_2_bundledJRE.exe.

Database-Update manual running of SQL-Scripts from path:
C:\Program Files (x86)\Openfire\resources\database\upgrade\
Scripts 21 till 29.

Install Openfire as Service.

After Update client.truststore was empty.
“C:\Program Files (x86)\Openfire\resources\security\client.truststore”
I take one old from backup of 3.9.3.0.
All Certificates now exist.

In the Log are next Lines:

2019.06.27 16:29:04 org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin ‘admin’.
2019.06.27 16:29:04 org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin ‘user-status’.
2019.06.27 16:29:04 org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin ‘userimportexport’.
2019.06.27 16:29:04 org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin ‘search’.
2019.06.27 16:29:04 org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin ‘presence’.

  1. First questions
    It’s mean, I donen’t need recompile plugins wich the new Java-Envirement?

  2. Second questins
    After Update Device cannot communicate with XMPP-Server.
    SSL handshake failed.

Hiere ist outpout of Info-Log:
2019.06.27 17:01:34 WARN [socket_c2s-thread-2]: org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000021: nio socket, server, /10.200.6.71:55908 => /10.200.6.98:5222)
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
4.3.2.0 is stronger as 3.9.3.0 about Certificates?

Certificates dowsn’t suits to new VM-02, but by the Version 3.9.3.0 Device was at least booked in XMPP-Server, under Openfire->Sessions.

thanks

Is this a triple repeat in your post? Please fix it.
What is this “Device” you mention and how is it different from Swift and where do you run Swift? Is this some mobile device?

A lot has changed since 3.9.3 and Openfire indeed can be more strict about certificates now.

Plugins should work without “recompiling”. If there is an update for your newer Openfire version, then it will be suggested to you on Plugins page.

Device ist a heating system and is xmpp-client.
Device authenticates with certificate.
It connects to Openfire.
Swift connect to Openfire too.
I send messages to device over Swift.

Some plugins were changed and newly created with 3.9.3.0.

I try to update the original system becouse of certificates.

It’s hard to follow you.

Do you mean you had custom plugins developed for Openfire 3.9.3? Then it is likely that they could stop working. From the list of standard plugins you have provided i think everything should work. Unless you have modified these standard plugins in some way.

I’m not sure i understand what was the original issue with certificates on older version. Maybe you can try to explain it again.

Original testsystem was updated.
Clients of one type can connect to Openfire server.
The other clients cannot connect.
The clients have diffrent client certificates.

Application use starndard plugins, one was modified and rebilt with the same Java-Version (3.9.3.0).
It looks like, plugins are working without rebild, although plugins with new version exist.

Server has a server certificate with CN = xmpp.XYZ.de.
And a clone of the server has the same certificate, but another URL.

After update some clients cannot connect to Openfire
… 15 more
2019.06.28 12:52:32 DEBUG [socket_c2s-thread-2]: org.apache.mina.filter.ssl.SslFilter - Session Server445: Writing Message : WriteRequest: HeapBuffer[pos=0 lim=145 cap=256: 3C 73 74 72 65 61 6D 3A 65 72 72 6F 72 20 78 6D…]
2019.06.28 12:52:32 DEBUG [socket_c2s-thread-2]: org.apache.mina.filter.ssl.SslFilter - Session Server445: Writing Message : WriteRequest: HeapBuffer[pos=0 lim=16 cap=16: 3C 2F 73 74 72 65 61 6D 3A 73 74 72 65 61 6D 3E]
2019.06.28 12:52:32 DEBUG [socket_c2s-thread-2]: org.apache.mina.filter.ssl.SslFilter - Session Server[445]: Writing Message : WriteRequest: HeapBuffer[pos=0 lim=7 cap=8: 15 03 03 00 02 01 00]
2019.06.28 12:52:32 DEBUG [socket_c2s-thread-2]: org.jivesoftware.openfire.spi.RoutingTableImpl - Removing client route xmpp.XYZ.de/xxxxxxxx
2019.06.28 12:52:32 DEBUG [NioProcessor-2]: org.apache.mina.filter.ssl.SslHandler - Unexpected exception from SSLEngine.closeInbound().
javax.net.ssl.SSLException: Inbound closed before receiving peer’s close_notify: possible truncation attack?
at sun.security.ssl.Alerts.getSSLException(Unknown Source) ~[?:1.8.0_202]
at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) ~[?:1.8.0_202]
at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) ~[?:1.8.0_202]
at sun.security.ssl.SSLEngineImpl.closeInbound(Unknown Source) ~[?:1.8.0_202]

Well, this is still hard to grasp and probably this issue is too complex to solve in the forums. Sorry, can’t help.

Not sure what you mean by another URL on the clone of a server. If certificate is for xmpp.xyz.de, but you try to access it via xmpp2.xyz.de, then this will create a mismatch in certificate and this can be a reason of error. Again, you probably need someone with more experience working directly to solve this. You may try contacting someone on this list https://www.igniterealtime.org/support/service_providers.jsp or wait for someone else to reply.

Btw, your real domain is showing in the error log you provided above. Maybe you want to mask it.

thank you wroot for your help.

I have two device types with different client/server certificates.
After update Openfire 3.9.3.0 to 4.3.2.0 devices of one type can communicate with openfire.
Devices of another type cannot.

It’s the same Server.
Perhaps have you any idea, how can I localize the problem.
I think, it’s certificate problem, so you say in your comment above:
“A lot has changed since 3.9.3 and Openfire indeed can be more strict about certificates now.”

Version 3.9.3.0 has the Settings:
Server->Server Settings->Security Settings.

Does this setting exists in the Version 4.3.2.0 ?

I compare two Installations:

Version 3.9.3
Server -> Server Manager -> Server Information

Update information
Server version 4.0.2 is now available. Click here to download or read the change log for more information.
Below you will find server information, ports being used and latest news about Openfire.

Server Properties

Server Uptime: 175 days, 20 hours, 47 minutes – started Jan 7, 2019 2:55:25 PM
Version: Openfire 3.9.3
Server Directory: C:\Program Files (x86)\Openfire
Server Name: xmpp.XYZ.de

Environment

Java Version: 1.7.0_55 Oracle Corporation – Java HotSpot™ Client VM
Appserver: jetty/7.x.y-SNAPSHOT
Host Name: xxxxxxxx
OS / Hardware: Windows Server 2012 / x86
Locale / Timezone: en / Greenwich Mean Time (0 GMT)
Java Memory

Version 4.3.2
Server -> Server Manager -> Server Information

Below you will find server information, ports being used and latest news about Openfire.
Server Properties

Server Uptime: 4 days, 1 hour, 18 minutes – started Jun 28, 2019 11:28:52 AM
Version: Openfire 4.3.2
Server Directory: C:\Program Files (x86)\Openfire
XMPP Domain Name: xmpp.XYZ.de

Environment

Java Version: 1.8.0_202 Oracle Corporation – Java HotSpot™ 64-Bit Server VM
Appserver: jetty/9.4.12.v20180830
Server Host Name (FQDN): test-www.XYZ.de DNS configuration appears to be missing or incorrect.
OS / Hardware: Windows Server 2012 R2 / amd64
Locale / Timezone: en / Greenwich Mean Time (0 GMT)
OS Process Owner: xxxxxxxx**$**
Java Memory

DNS SRV Record verification

No DNS SRV records for this host are found.

To compose the information on this page, a DNS SRV query has been made, using the value of xmpp.XYZ.de, which is the XMPP domain name that is configured for Openfire. Any resulting records are inspected for a match against the value of test-www.XYZ.de, which is the fully qualified domain name of the server that is running Openfire, as configured here.

Current DNS Configuration Evaluation

There appear to be no DNS SRV records at all for this XMPP domain. With the current configuration of Openfire, it is recommended that DNS SRV records are created for this server.

Without a valid DNS SRV record, clients are likely to have trouble connecting to your server. Even when clients provide a manual connect host, it is likely that they provide a different value than the fully qualified domain name that is configured for your server, which will cause problems with certain authentication mechanisms. It is recommended to have a DNS SRV record for this XMPP domain that matches the fully qualified domain name of the server on which you are running this instance of Openfire.

It is expected that your DNS configuration has at least two SRV records, which are similar to this (values like TTL, priority and weight are examples, and might be different in your configuration):
•_xmpp-client._tcp.xmpp.XYZ.de. 86400 IN SRV 0 5 5222 test-www.XYZ.de.
•_xmpp-server._tcp.xmpp.XYZ.de. 86400 IN SRV 0 5 5269 test-www.XYZ.de.

Note that changes that have been applied to DNS configuration might take a while to propagate. It might take some time for Openfire to be able to see the changes that were made to your DNS configuration.

I think this setting is now in Server Settings > Client Connections now. Also you can find information on your certificates in TLS/SSL Cerificates menu and pressing on the first Manage Store link. Are your certificates for xmpp.xyz.de domain in that menu?

I installed 4.4.0.0 over 4.3.2.0
After Installation menutree is in German, so wie operation system.
Installation 3.9.3.0 and 4.3.2.0 were in English.

yes, I have the certificate xmpp.XMZ.de under TLS/SSL Cerfiticates
C:\Program Files (x86)\Openfire\resources\security\keystore

But there is a warning here:
Openfire Identity Certificate Store
A certificate for the domain of this server is missing. Click here to generate a self-signed certificate or here to import a signed certificate and its private key.

3.9.3.0
Server->Server manager -> System properties

sasl.mechs = EXTERNAL

4.4.0.0
Server->Server manager -> System properties
sasl.mechs = EXTERNAL

If I insert some other SASL Mechanisms under Register and Login, I have:

sasl.mechs.00001 EXTERNAL
sasl.mechs.00002 PLAIN
sasl.mechs.00003 DIGEST-MD5
sasl.mechs.00004 CRAM-MD5
sasl.mechs.00005 GSSAPI

After deleting some options under Register and Login, I have:

sasl.mechs.00001 EXTERNAL

After chaning
sasl.mechs.0001 to sasl.mechs
I get 2 Settings:
sasl.mechs EXTERNAL
sasl.mechs.00001 EXTERNAL

Is it right?
Need the communication the setting sasl.mechs EXTERNAL
or
sasl.mechs.00001 etc…