--- title: "What's New in HiveMQ 4.57?" description: "HiveMQ 4.57 adds PEM certificate support for the TLS connections of the HiveMQ Enterprise Security Extension, and stores and replicates the metrics history so the diagnostic archive keeps the metrics of restarted and replaced nodes." date: 2026-11-03 author: HiveMQ Team tags: - HiveMQ Release source: https://www.hivemq.com/changelog/whats-new-in-hivemq-4-57 --- # What's New in HiveMQ 4.57? The HiveMQ team is pleased to announce the release of HiveMQ Enterprise MQTT Broker 4.57. This release focuses on performance, stability, and security. The HiveMQ Enterprise Security Extension adds PEM certificate support for TLS connections and the metrics history in the diagnostic archive now persists across node restarts. In the HiveMQ broker, asynchronous event logging and better memory handling improve performance in demanding environments. Additionally, the HiveMQ Control Center increases the protection of sensitive data in diagnostic archives and error messages, and several HiveMQ Enterprise Extensions receive important fixes. ## Highlights - **PEM certificates in TLS configurations**: Configure the TLS connections of the HiveMQ Enterprise Security Extension directly with PEM certificates and keys, without first converting them to Java keystores. - **Metric history that persists across node restarts:** HiveMQ now stores and replicates the metrics history, so the diagnostic archive keeps the metrics of restarted and replaced nodes. ## PEM Certificate Support in the HiveMQ Enterprise Security Extension HiveMQ 4.56 added PEM certificate support to the HiveMQ Enterprise MQTT Broker and the HiveMQ Enterprise Bridge Extension. HiveMQ 4.57 extends this support to the HiveMQ Enterprise Security Extension. Realms in the extension, such as SQL realms, get authentication and authorization information from an external source, for example, a database. When these connections use Transport Layer Security (TLS), the extension can now load certificates and private keys directly from PEM files. ### How it works Each PEM element is the counterpart of an existing keystore element. In SQL realms, the `` element accepts `` for the client certificate and private key, and `` for the trusted certificate authorities: The other realm types follow the same pattern: - LDAP, JWT, OAuth, and OIDC realms accept `` in place of ``. This element points to a file that contains your trusted certificate authority certificates. - In OIDC realms, `` and `` accept `` in place of ``. **Details to consider for production**: - **Relative paths:** In every realm, the extension resolves relative PEM file paths against the home directory of the extension. - **Startup validation:** The extension reads the keystore, truststore, and PEM certificate files of its realms when the extension starts. If a file is missing or unreadable, or a password is wrong, the extension does not start. To apply a renewed certificate, restart the extension. - **Hostname verification:** SQL realms now use the hostname verification of the Java Runtime Environment instead of the hostname verification of the JDBC driver. The certificate must list the host as a DNS name or, for an IP address, as an IP address. The extension uses the common name only if the certificate contains no DNS names. - **Encrypted private keys:** The extension supports keys in PKCS #8 format with PBES2, PBES1, or PKCS #12 encryption, and keys in the traditional OpenSSL format. All Java runtimes read these keys the same way, even with non-ASCII passwords. - **MySQL Connector/J:** The MySQL Connector/J driver in the `drivers/jdbc` folder reads only keystore files. If a MySQL realm uses this driver, PEM elements prevent the extension from starting. This driver also reads the keystore and truststore files for every connection instead of at startup, and it keeps its own hostname verification. The startup validation and hostname verification described above do not apply to it. MySQL realms that use the included MariaDB driver support PEM files. For the changes that affect existing TLS configurations of SQL realms and OIDC realms, see the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#ese-sql-realm-tls). ### How it helps Many certificate authorities and tools, such as cert-manager, issue certificates as PEM files. Previously, you had to convert the PEM files with `keytool` into Java keystore and truststore files. Now, you can use the certificates exactly as they are issued. To rotate a PEM certificate, replace the file and restart the extension. In Kubernetes deployments, you can reference the certificate that cert-manager writes to a mounted secret directly. For configuration options and additional examples, see the [PEM certificate files section of the HiveMQ Enterprise Security Extension documentation](https://docs.hivemq.com/hivemq-enterprise-security-extension/latest/ese.html#pem-certificates). ## Metrics History That Persists Across Node Restarts in the HiveMQ Enterprise Broker Since HiveMQ 4.34, the diagnostic archive includes the last 72 hours of metrics from every node. However, each node kept this history in memory. When a node restarted, crashed, or was replaced, the diagnostic archive lost its history. HiveMQ 4.57 stores the metrics history on disk and replicates it across the cluster. As a result, the diagnostic archive now also includes the metrics of nodes that are no longer part of the cluster. ### How it works Every 5 seconds, instead of every 20 seconds, each node writes a snapshot of its metrics to disk. The history covers the last 72 hours. HiveMQ replicates each snapshot to other nodes using the configured replica count (default: 2). When you create a diagnostic archive, each node contributes the history that it holds, including copies from nodes that left the cluster. With the default replica count, it uses about 0.5 GB of disk space per node in a cluster. To maintain the history during maintenance or upgrades, follow the standard rolling upgrade procedure and restart the nodes of your cluster [one at a time](https://docs.hivemq.com/hivemq/latest/user-guide/cluster.html#wait-for-synchronization). ### How it helps In case of an incident, the complete metrics from the diagnostic archive give valuable insights for analysis. For example, a node can run out of memory because subscribers cannot keep up. Until now, these metrics were lost with the crashing node. Now, other nodes still hold a metrics copy for the diagnostic archive. The shorter 5-second interval also captures brief spikes that the previous 20-second interval could miss. Together, these changes help HiveMQ Support find the root cause of an incident, even after the affected node is gone. For more information, see the [diagnostic archive documentation](https://docs.hivemq.com/hivemq/latest/control-center/diagnostic-archive.html). ## More Noteworthy Features and Improvements ### HiveMQ Enterprise MQTT Broker - Updated the default `logback.xml` file to write event logs asynchronously to avoid reduced broker performance when many clients connect and disconnect frequently. If you customized your `conf/logback.xml` file, add the new asynchronous event log configuration manually during the upgrade. - Improved HiveMQ broker performance on machines with 8 GB or less of RAM. - Fixed an issue where a [native memory leak in RocksDB](https://github.com/facebook/rocksdb/issues/15036) during regular background operations could increase the memory usage of the broker. - Fixed an issue where a cluster could stop accepting new or rejoining nodes if a node left the cluster during a join operation or if data replication failed. - Fixed an issue where a malformed CONNECT packet could abort active trace recordings. - Fixed an issue where consumer spans in distributed tracing were incorrectly marked as failed in some cases. - Fixed an issue where, under TCP backpressure, the broker could send MQTT packets such as PINGRESP after it sent a `DISCONNECT` packet for a keep-alive timeout. - Fixed an issue where extension consumers with overlapping topic filters could receive duplicate messages, which affected the Kafka, MongoDB, MySQL, PostgreSQL, Microsoft SQL Server, Data Lake, Snowflake, and Bridge extensions. - Changed the field names in the Client Lifecycle Topic (`$client-events`) payload to camelCase, which requires consumer updates before you upgrade, as described in the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#client-lifecycle-topic-payload). - Updated TLS configurations with PEM files to reject private key files that contain more than one private key, and certificate files that contain `TRUSTED CERTIFICATE` blocks, at startup. The change also applies to the HiveMQ Enterprise Bridge Extension, as described in the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#pem-certificate-files). - Fixed an issue where HiveMQ and the HiveMQ Enterprise Bridge Extension could not load encrypted PEM private keys with non-ASCII passwords, PEM files that start with a byte order mark (BOM), or keys with legacy encryption on Oracle JDK. ### HiveMQ Enterprise Security Extension - Added support for the `resource` parameter in OpenID Connect authentication requests to request access to a specific resource. - Improved OpenID Connect authentication to accept role claims that contain a single string value, in addition to a list of values. - Changed the TLS behavior of SQL realms, which can require configuration updates before you upgrade, as described in the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#ese-sql-realm-tls). - Changed OIDC realms to load the keystore for `tls-client-auth` and `private-key-jwt` when the extension starts. An invalid keystore now prevents the extension from starting, as described in the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#ese-oidc-realm-keystore). ### HiveMQ Control Center - Improved the diagnostic archive creation dialog to provide more options for the information that the archive includes. - Improved error handling in the HiveMQ Control Center API to return simpler error responses. - Disabled the details views of the *Queued Messages* and *Dropped Messages* charts on the *Overview* dashboard during maintenance mode. - Fixed column sorting in the Trace Recordings view so that recordings appear in the selected order. ### HiveMQ Enterprise Bridge Extension - Updated the extension to read JKS and PKCS #12 keystore and truststore files with any file name, and to stop at startup if it cannot read one of these files. - Added a startup check that verifies that the extension can read the configured truststore file. - Updated the extension to require the `` element for JKS truststores that have a password, as described in the [HiveMQ 4.56 to 4.57 Migration Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#bridge-keystore-validation). ### HiveMQ Enterprise Data Lake Extension - Improved the performance of the extension when the log level is set to DEBUG. - Fixed an issue where an Azure Blob Storage route repeatedly retried an upload with the same file name if a blob with that name already existed. ### HiveMQ Enterprise Extension for Kafka - Fixed intermittent load failures of custom transformers with multiple constructors in the Kafka extension by always using the public no-argument constructor. ## Get Started Today To upgrade HiveMQ from a previous version, follow the steps in the [HiveMQ Upgrade Guide](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html) and review the [Known Issues](https://docs.hivemq.com/hivemq/latest/upgrade/4-56-to-4-57.html#known-issues). To learn more about all the features the HiveMQ Platform offers, explore the [HiveMQ User Guide](https://docs.hivemq.com/hivemq/latest/user-guide/introduction.html). [Get HiveMQ 4.57 now](https://app.hivemq.com/signup?target=software)