Enabling LDAP Connectivity with Amazon MQ Using Private SSL Certificates

Introduction

Amazon MQ supports LDAP authentication for ActiveMQ brokers, enabling centralized user management through your existing directory services. However, a common challenge arises when the LDAP server is internally hosted with a private SSL certificate and a non-publicly resolvable DNS name.

Amazon MQ requires that the LDAP server's SSL certificate be issued by a publicly trusted Certificate Authority (CA) private or self-signed certificates are not supported. Additionally, the LDAP server's Fully Qualified Domain Name (FQDN) must be resolvable by the Amazon MQ service.

This article presents a solution using an AWS Network Load Balancer (NLB) with a publicly signed SSL/TLS certificate from AWS Certificate Manager (ACM) and an Amazon Route 53 DNS alias record to enable LDAP connectivity with privately hosted directory servers without modifying your existing LDAP infrastructure.

Solution Overview

The solution introduces an internal Network Load Balancer (NLB) as a TLS proxy between the Amazon MQ broker and the LDAP server. The NLB performs TLS termination using a publicly signed ACM certificate and forwards traffic to the backend LDAP server on port 636. A DNS record in Route 53 (or your DNS provider) maps a publicly resolvable FQDN to the NLB, which Amazon MQ can then use as the LDAP endpoint.

Key Components

• Internal Network Load Balancer (NLB) - Deployed in the same VPC as the Amazon MQ broker to handle TLS termination.
• AWS Certificate Manager (ACM) - Provides a publicly signed SSL/TLS certificate bound to the NLB listener.
• Target Group - Routes traffic to the LDAP server's private IP address on port 636.
• Amazon Route 53 - Creates a DNS A record (alias) pointing to the NLB, giving the LDAP endpoint a publicly resolvable FQDN.

Prerequisites

• An Amazon MQ broker (ActiveMQ) deployed in a VPC.
• An LDAP server (on-premises or EC2-based) accessible from the VPC, listening on port 636 (LDAPS).
• A publicly signed SSL/TLS certificate in AWS Certificate Manager (ACM). If you don't have one, you can request it via ACM using DNS or email validation.
• A hosted zone in Amazon Route 53 (or access to your external DNS provider).
• Appropriate security group rules to allow traffic on port 636 between the NLB, the broker, and the LDAP server

Solution Walkthrough

Step 1: Create an Internal Network Load Balancer

Navigate to the EC2 Console → Load Balancers → Create Load Balancer and select Network Load Balancer.

• Name: Enter a descriptive name (e.g., ProxyLDAP).
• Scheme: Select Internal — this ensures the NLB is only accessible within the VPC.
• IP address type: Select IPv4.
• VPC: Choose the VPC where your Amazon MQ broker resides.
• Availability Zones: Select all relevant subnets/availability zones for high availability.

Step 2: Configure the TLS Listener and Security Groups

In the Listeners and routing section: Protocol: Select TLS.

• Port: Enter 636 (standard LDAPs port).
• Security group: Assign a security group that allows inbound traffic on port 636 from the Amazon MQ broker's security group.
• Subnets: Select all relevant subnet CIDRs for multi-AZ deployment.

Step 3: Create a Target Group with the LDAP Server IP

Create a new target group for the LDAP server:

• Target type: Select IP addresses.
• Protocol: TLS
• Port: 636
• VPC: Same VPC as the NLB.

Register the target:

• Enter the private IP address of your LDAP server (EC2 instance or on-premises server reachable via VPN/Direct Connect).
• Set the port to 636.
• Click Include as pending below, then proceed.

Step 4: Review the Target Group

Verify the target group has been created successfully. You should see your LDAP server's IP address listed as a registered target. The health status may initially show as "Unused" until the NLB is fully provisioned and associated.

Step 5: Associate the Target Group with the NLB

Return to the NLB creation wizard:

• Refresh the target group dropdown in the listener configuration.
• Select the newly created target group (e.g., LDAPTargetGroup).
• Ensure the weight is set to route 100% of traffic to this target group.

Step 6: Select the Publicly Signed ACM Certificate

In the Secure listener settings section:

• Certificate source: Select From ACM.
• Certificate: Choose your publicly signed ACM certificate from the dropdown.
• Security policy: Use the recommended policy (e.g., ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09).

Note: If you don't have an ACM certificate, request one first via the ACM console. You can validate ownership using DNS validation (recommended) or email validation.

Step 7: Review and Create the NLB

Review the complete configuration:

• Verify the listener shows TLS:636 with the correct target group and ACM certificate.
• Click Create load balancer.
• Wait for the NLB status to change from "Provisioning" to "Active."

Step 8: Navigate to Route 53

Go to the Route 53 Console → Hosted Zones and select your hosted zone. Review the existing DNS records to understand the current configuration before adding the new alias record.

Step 9: Create an A Record Alias Pointing to the NLB

Create a new DNS record:

• Record name: Enter the subdomain (e.g., api for api.yourdomain.com).
• Record type: A – Routes traffic to an IPv4 address.
• Alias: Toggle ON.
• Route traffic to: Select Alias to Network Load Balancer → choose the appropriate region → select your NLB.
• Routing policy: Simple routing.
• Evaluate target health: Yes.

Click Create records.

Step 10: Verify the Setup Using LDAP Client

Test the LDAP connectivity using an LDAP client from an EC2 instance within the VPC:

ldapsearch -x -H ldaps://api.yourdomain.com:636 \
  -D "cn=admin,dc=example,dc=com" \
  -w "your_password" \
  -b "ou=users,dc=example,dc=com" -LL

If the query returns your LDAP directory entries successfully, the NLB proxy is working correctly.

Troubleshooting tips:

• If the connection times out, verify security group rules allow traffic on port 636 between the NLB, the broker, and the LDAP server.
• If DNS resolution fails, confirm the Route 53 A record is correctly pointing to the NLB.
• If TLS handshake fails, verify the ACM certificate is valid and properly associated with the NLB listener.

Step 11: Update the LDAP FQDN in the Amazon MQ Broker

Once Step 10 is successful, update your Amazon MQ broker's LDAP settings:

• Fully Qualified Domain Name: Set to the new DNS name (e.g., api.yourdomain.com).
• Service account username: Your LDAP bind DN (e.g., cn=admin,dc=example,dc=com).
• User Base, Role Base, and search matching patterns: Configure according to your LDAP directory structure.

The broker will now connect to the LDAP server through the NLB using the publicly signed certificate, resolving both the DNS and SSL certificate issues.

Important Considerations

• Cost: The NLB incurs hourly charges plus data processing fees. Review the Elastic Load Balancing pricing page for details.
• Certificate Renewal: ACM certificates are automatically renewed, eliminating manual certificate management overhead.
• High Availability: Deploy the NLB across multiple availability zones for resilience.
• Security Groups: Ensure that only the Amazon MQ broker and authorized resources can reach the NLB on port 636.
• Health Checks: Configure appropriate health checks on the target group to detect LDAP server failures.
• On-Premises Connectivity: If your LDAP server is on-premises, ensure network connectivity to the VPC via AWS Direct Connect or VPN, and register the on-premises server's IP in the target group.

Conclusion

Amazon MQ's requirement for publicly signed SSL certificates and resolvable DNS names for LDAP integration can be a challenge when working with internally hosted LDAP servers. By placing an internal Network Load Balancer with an ACM-issued public certificate in front of the LDAP server and creating a Route 53 alias record, you can seamlessly enable this connectivity without modifying your existing LDAP infrastructure.

This approach provides a clean, scalable, and secure solution that leverages native AWS services NLB for TLS termination, ACM for certificate management, and Route 53 for DNS resolution to enable Amazon MQ LDAP authentication with privately hosted directory servers.

---

About the authors
	Puneetha Kumara is a Senior Technical Account Manager at AWS, with over 17 years of industry experience, including roles in cloud architecture, systems engineering, and container orchestration.
	Manav Bhardwaj is a Support Engineer at Amazon Web Services, specializing in messaging services, cloud architecture, networking, and container orchestration. Outside of work, he firmly believes most problems can be solved with a fresh cup of coffee and a packet capture.