CIRCUIT

Locking Down Replication Agents for Secure Publisher Communication

Replication agents are the quiet workhorses of any Adobe Experience Manager deployment. They ferry authored content from the author tier to publishers, sync user-generated data back through reverse replication, and keep dispatchers and CDNs aligned. When healthy, nobody notices them. When broken or misconfigured, symptoms range from stale production pages to sensitive payloads leaking across unencrypted channels.

Australian enterprise estates carry higher stakes than many other markets. Obligations under the Notifiable Data Breaches scheme, combined with rules from APRA for banking and the OAIC for government tenants, mean a misconfigured agent leaking content between data centres can become a reportable incident before the morning standup. Teams running AEM for the Big Four banks or for telcos such as Telstra and Optus have learned that replication traffic deserves the same care as any other privileged channel.

The defaults shipped with a fresh AEM install assume a developer laptop talking to a local publisher. Production needs certificates, transport hardening, and deliberate choices around authentication. Knowing how to configure each agent transport, credential, and queue setting is what separates a stable author-publish relationship from an incident-prone one. This guide walks through the practical steps, drawing on patterns that work well in Sydney and Melbourne where publisher latency comfortably sits under 30 milliseconds.

By the end you will know which agent properties control the connection, how to layer SSL onto legacy configurations, and where the usual traps hide. The advice assumes familiarity with the AEM author-publish topology and with Java keytool.

Setting Up SSL Between Author and Publisher

The single biggest change that improves security posture is moving replication traffic onto HTTPS. Many older queues still expect plain HTTP on port 4502, which means payloads including asset binaries that may carry personal information traverse the network in cleartext. Switch the agent's transport URI from http:// to https://, then configure it to point at the publisher's listener with the appropriate port.

Generating or importing a server certificate is the next step. For Australian customers on Adobe Managed Services, Adobe provisions the certificates and rotates them annually. Self-managed clusters running in AWS Sydney (ap-southeast-2) or Azure Australia East can use a local CA such as DigiCert, use Let's Encrypt, or export a PEM bundle from AWS Certificate Manager into the Java truststore on the author instance.

Once the certificate is in place, validate the chain with OpenSSL from a bastion host before trusting it inside AEM. A surprising number of east-coast replication outages turn out to be intermediate certificates missing from the bundle rather than expired leaves. After verification, restart the author and check the agent test connection button. A successful handshake there beats a green dashboard LED.

Choosing Authentication for Replication Calls

Authentication is where most teams either over-engineer or under-engineer. The simplest approach enables the publisher's authentication handler for the replication servlet and stores a long-lived shared credential in the agent's OSGi configuration. Fine for a single region, but it leaves a static secret in a config file that often lands in source control by mistake.

A stronger pattern, particularly for regulated customers running AEM for CBA or Westpac, is system user accounts paired with token-based authentication. Create a dedicated replication-service user in publisher user admin, give it the minimum ACLs (typically replicate, read on /content, and a few service paths), and pass the credentials as a token rather than a password. The AEM security guide covers the supported syntax for SerializationType and TransportUser.

For the highest assurance environments, mutual TLS removes credentials from the equation. Both ends hold a client certificate, and the transport only completes if both sides trust the chain. This is heavier operationally since certificate rolls need orchestration across the author cluster, but it removes replay and credential theft risks that have bitten a number of Australian government tenants running federated AEM setups.

Hardening Reverse Replication

Reverse replication works in the opposite direction. The publisher pushes user-generated content including form submissions, profile updates, and cart state back to the author. It is the channel most often forgotten, yet it is where the most sensitive payloads travel. Treat its outbound agent with the same rigour as its forward sibling.

Lock down the queue by capping retries, time-to-live, and maximum payload size. A queue that retries indefinitely against a reachable but poorly secured publisher eventually lands its payload somewhere unsafe. Set max.old.versions realistically and put a hard cap on the size attribute so a malicious form payload cannot exhaust the heap.

Where possible, route reverse replication traffic through private VPC peering rather than across the public internet. In ap-southeast-2 this is straightforward when author and publisher sit inside the same AWS organisation; AWS PrivateLink or a transit gateway keeps everything on a private backbone and makes interception meaningfully harder. Cross-region replication to a Melbourne disaster recovery site benefits from the same approach. For teams adding captcha or second-factor controls to the forms feeding this channel, the write-up on securing AEM Forms endpoints covers the relevant dispatcher and publisher-side configuration in more depth.

Observability and Retry Behaviour

A replication agent that is hardened but invisible is only half a job. Observability is what lets you catch a slow certificate expiry or a flapping network interface before it escalates into a customer-facing incident. Most production teams in Sydney ship agent metrics into Grafana, where queue depth, retry count, and last-error messages can be graphed alongside JVM and dispatcher metrics.

The classic signal is the agent queue staying above zero for more than a few minutes during business hours. Anything approaching a backlog in the arvo usually means either the publisher is under load or the transport has silently fallen back to an unencrypted channel after a config drift. Alerting on the agent's lastUpdated timestamp and on TLS handshake failures recorded in the error log catches both conditions earlier than waiting for a content author to file a ticket.

For a practical walkthrough of wiring these signals into a dashboard, the Grafana replication dashboards post from CIRCUIT shows a working setup that runs nicely on a small EC2 instance in Sydney.

Pitfalls in Multi-Region Deployments

Once replication spans more than one region, complexity multiplies. A common Australian pattern is a primary author cluster in Sydney with publishers in Sydney and Melbourne for DR, plus a content syndication out to Auckland for trans-Tasman coverage. Each link in that chain has its own certificate, its own service user, and its own retry semantics.

The mistake teams make most often is treating agents as immutable. They are not. The publisher's certificate rotates, the author is rebuilt, a load balancer changes its listener port, and an agent that has worked for eighteen months stops working. Build agent configuration as code, version it in Git, and reconcile it with whatever configuration management tool you prefer. The local sandbox script approach is no substitute for declarative config.

Another trap is DNS. If your agent points at a hostname that resolves to an IP that has since been retired, the agent keeps queueing payloads against a dead address without raising a clear error. Pin the transport URI to a stable CNAME, or where the publisher sits behind an internal load balancer to the load balancer's DNS name. For organisations running .NET microservices alongside AEM, structured event metadata from those services can be correlated with replication queue events using patterns described in C# 11 generic attributes.

Practical Recommendations Before You Go Live

A short checklist helps when locking in a replication configuration ahead of a production cutover. Run through each item as a sanity gate and you will avoid most of the post-go-live firefighting that otherwise eats the first week of a new release.

Order matters. Pinning the transport and certificate chain comes first because everything else assumes a working TLS layer. Replacing shared passwords runs second, since static credentials in OSGi config files have been the root cause of more Australian regulatory findings than any other misconfiguration we have seen in incident reviews.

  • Pin every agent transport URI to HTTPS and verify the certificate chain from a host outside the cluster.
  • Replace shared passwords with tokens tied to a dedicated system user with minimal ACLs.
  • Put reverse replication behind a private network link rather than across public infrastructure.
  • Wire agent queue depth, retry counts, and last-updated timestamps into a Grafana board with paging alerts.
  • Version all replication agent configuration as code and reconcile it on every author rebuild.

If you want to chat through your replication topology or run a live review of your agent configuration, the CIRCUIT team is happy to hear from Australian teams running AEM at scale. Drop us a note via the usual channels, or browse our off-topic chat for slower conversations between events.