How to Access HiveMQ Cloud Enterprise

This page describes how clients and services reach your HiveMQ Cloud Enterprise deployment over the network.

Because HiveMQ Cloud Enterprise is a managed, support-driven service, HiveMQ sets up the network configuration for your deployment. Use this page to understand the endpoints your clients connect to and the options available to you. To request changes, contact your Technical Account Manager (TAM), Customer Success Manager (CSM), or HiveMQ support.

Public Listener

By default, clients reach your deployment through a public listener that uses TLS.

Listener Address and Ports

The default public listener for HiveMQ Cloud Enterprise uses the following fully qualified domain name (FQDN) scheme, where the leftmost label is the environment:

prod.<hivemq-generated-string>.hivemq.cloud

HiveMQ generates the <hivemq-generated-string> portion when it provisions your deployment. The same hostname serves both the secure MQTT (MQTTS) and the secure WebSocket (WSS) listeners. The port determines which protocol you reach:

Protocol Default port Example

MQTTS (MQTT over TLS)

8883

prod.<hivemq-generated-string>.hivemq.cloud:8883

WSS (MQTT over secure WebSocket)

443

prod.<hivemq-generated-string>.hivemq.cloud:443

Per-Environment Behavior

HiveMQ Cloud Enterprise supports separate environments, such as production, staging, and development. You purchase environments as part of your subscription. They are not included by default. When your subscription includes more than one environment, each environment has its own listener. The leftmost label of the FQDN identifies the environment:

Environment FQDN label

Production

prod.<hivemq-generated-string>.hivemq.cloud

Staging

staging.<hivemq-generated-string>.hivemq.cloud

Development

dev.<hivemq-generated-string>.hivemq.cloud

Connect each client to the listener for its environment. Where multiple environments are provisioned, the available feature set is consistent across them, subject to the allowances defined in your subscription.

HiveMQ can configure additional listeners on request. For example, an extra TLS, WSS, or TCP listener, or a changed port. To keep access secured, HiveMQ offers plain TCP listeners only in combination with private networking. To request a listener change, contact your account team or HiveMQ support.

Custom Domains (Custom DNS)

You can use your own domain name for the default MQTT listener instead of the generated *.hivemq.cloud name. HiveMQ Cloud Enterprise issues and renews certificates automatically using the ACME protocol with Let’s Encrypt by default. Custom domains must be set up to work with that automated flow.

What You Provide and What HiveMQ Handles

At a high level, you and HiveMQ share responsibilities as follows.

  • You provide: a registered custom FQDN, and the required records on your own external DNS:

    • a CNAME record that points your custom FQDN to the HiveMQ-provided *.hivemq.cloud name, and

    • a matching _acme-challenge CNAME record that points to the HiveMQ _acme-challenge name. This record lets the certificate authority validate domain control through the ACME dns-01 challenge.

    • Optionally, if your DNS uses Certification Authority Authorization (CAA) records, a CAA record that authorizes Let’s Encrypt to issue certificates for the FQDN.

  • HiveMQ handles: configuring your services for the custom FQDN, and the automated issuance and renewal of Let’s Encrypt certificates (rotated approximately every 60 days).

After your records are in place and validated, share the chosen FQDN with HiveMQ. HiveMQ then activates the configuration. Before you share your public DNS records, you can validate them with the HiveMQ DNS validator tool.

Once a custom domain is active, the custom FQDN and the default *.hivemq.cloud FQDN reach the same endpoint. Both use the same authentication, authorization, and data flow. You can migrate devices to the custom domain at your own pace. Devices that use the default name continue to work.

Certificates from a Different Certificate Authority

Some deployments require server certificates from a certificate authority other than Let’s Encrypt. This is common when you use mutual TLS against your own public key infrastructure (PKI). In this case HiveMQ can integrate with your PKI through an ACME-compatible cert-manager issuer. Arrange this with HiveMQ support as part of your deployment configuration.

Private Networking

In addition to public access, HiveMQ Cloud Enterprise supports private connectivity through PrivateLink (AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect). HiveMQ sets up private connectivity on request.

PrivateLink, or the equivalent native private-link service of your cloud provider, is the only private-networking option for HiveMQ Cloud Enterprise. HiveMQ Cloud Enterprise does not offer Virtual Private Cloud (VPC) peering or shared-VPC models.

Private connectivity applies to MQTT endpoints. The REST API and the Control Center are not available over private connectivity. You reach them over their public HTTPS endpoints.

Private connectivity always has a direction: one side provides the service and the other consumes it. There are two paths, depending on which side HiveMQ is on:

  • HiveMQ provides the service: HiveMQ exposes your MQTT broker as a private-link service that your cloud network consumes. See Private access to your deployment.

  • HiveMQ consumes the service: An Enterprise Extension reaches one of your third-party services, for example, a Kafka cluster or database, that you expose as a private-link service. See Private connectivity to a third-party service.

Both paths use the same underlying technology and exchange similar information. They differ in which side provides the private-link service and which side consumes it.

Private Access to Your Deployment

In this path, HiveMQ exposes your MQTT broker as a private-link service that you consume from your own cloud network. At a high level:

  • You provide: your cloud account, subscription, or project ID so HiveMQ can authorize the connection.

  • HiveMQ handles: creating the private-link service and providing the connection information. For example, the service name or ID, DNS name, and port.

  • You then:

    1. Create a private-link endpoint in your VPC or VNet using the HiveMQ-provided connection information.

    2. Create an internal DNS record that resolves your FQDN to the endpoint’s internal IP address.

    3. Create the external _acme-challenge CNAME record required for certificate issuance (as in Custom domains).

    4. Grant network-flow permissions (routing, firewalls, network security groups, and access control lists) between the endpoint and the services and devices that consume the MQTT service.

You initiate traffic over the endpoint. Traffic is network-address-translated in both directions, following cloud-native best practice.

Private Connectivity to a Third-Party Service

In this path, the direction reverses. An Enterprise Extension connects from HiveMQ to one of your services, such as a Kafka cluster, database, or data lake. You expose that service for HiveMQ to consume privately. At a high level:

  • You provide: a private-link service, or equivalent, for your third-party service, plus the connection details HiveMQ needs to reach it.

  • HiveMQ handles: creating the consuming endpoint on the HiveMQ side and connecting the Enterprise Extension to your service.

  • The Configuration mirrors the inbound path, with the roles of provider and consumer swapped.

Because the exact steps differ per cloud and per target service, HiveMQ support arranges a per-service setup for this path. For which Enterprise Extensions are available, see Enterprise Extensions.

Private connectivity applies to services that are reachable in your cloud network, such as a Kafka cluster or database. Global services that do not reside in your account, such as Google Cloud Pub/Sub or Azure Event Hubs, are reached directly using the credentials you provide, not through private connectivity.

TLS and Authentication

By default, all HiveMQ Cloud Enterprise listeners use TLS. In addition to TLS, several client authentication and authorization methods are available. This section states what is available and what is not. For details about how each method works, follow the links to the broker and Enterprise Security Extension documentation rather than configuring it yourself.

Supported Authentication and Authorization

HiveMQ Cloud Enterprise supports the following methods:

  • Username and password (Basic) authentication, the default method.

  • Client certificate authentication (mutual TLS, X.509).

  • JSON Web Token (JWT) authentication, with integration for OAuth and OpenID Connect providers.

  • Role-based access control (RBAC) for authorization, which assigns permissions to roles, and roles to credentials, client certificates, or JWT authentication.

To manage credentials, roles, and permissions in HiveMQ Cloud Enterprise, see Authentication and authorization. For placeholders and variables in permissions, see the Enterprise Security Extension variables documentation.

JWT and client-certificate authentication establish the identity of a client (authentication). Authorization comes through RBAC: you assign a role to the authentication method itself. Apply a default role to all clients that use the method, or select a role from a client identifier, such as a JWT claim or a certificate field. You do not need a separate username and password to authorize a JWT-authenticated or certificate-authenticated client.

Not Supported in HiveMQ Cloud Enterprise

HiveMQ Cloud Enterprise does not support the following authentication method:

  • LDAP authentication and authorization.

LDAP integration relies on a persistent connection to a directory service and is not offered in the managed Cloud environment. For single sign-on based on OAuth and OpenID Connect instead of LDAP, HiveMQ Cloud Enterprise offers integration through JWT and the Enterprise Security Extension.

Authentication Notes

  • You can manage a single Basic authentication flow yourself through the Cloud Console and REST API. A deployment can attach this flow to one or more public and private listeners.

  • If you need a second, separate authentication flow, one flow remains self-service. HiveMQ manages the other through a change-control request.

  • HiveMQ configures the authentication method of a listener on request. For example, HiveMQ can change the default TLS listener from Basic to JWT or client-certificate authentication.

Where to Go Next