Overview

Khoros Aurora Community Endpoints allow server-side code (Node.js plugins) to make outbound HTTP calls to external APIs. Before an Endpoint can call an external hostname, that hostname must be added to the Allowed Domains for Endpoints allowlist under Account → Dev Tools → Endpoint Settings.

This article covers the correct format for adding domains, the validation rules Aurora enforces (including private-IP blocking), and a key platform limitation: Aurora Endpoints do not support presenting client certificates for outbound mTLS (mutual TLS) connections.

In This Article

• Adding Allowed Domains
• Domain Validation Rules
• Private / Internal IP Blocking
• mTLS Client Certificates — Not Supported
• Workaround for mTLS Requirements
• FAQ

Adding Allowed Domains

To allow an Endpoint to call an external service:

1. Navigate to Account → Dev Tools → Endpoint Settings.
2. Under Allowed Domain for Endpoints, enter the domain as a domain suffix beginning with a dot.
3. Click Save.

Format Requirements

The value must be a domain suffix in the form .domain.com:

• Leading dot required — e.g. .example.com
• No protocol — do not include https://
• No path — do not include /anything after the domain
• No leading/trailing spaces or quotes

Examples:

• .itcloud.ea.com — allows all subdomains under itcloud.ea.com
• .api.example.com — allows only subdomains under api.example.com

Domain Validation Rules

When a domain is saved, Aurora runs several backend checks. The domain will be rejected if any of the following conditions are true:

Check	Rejection Reason
Domain is an IP address (e.g. 10.0.0.1)	HOSTNAME_CONTAINS_IP
Invalid characters (only a-z, 0-9, hyphen, and dot are allowed)	INVALID_DOMAIN_NAME
Domain is all wildcards	WILDCARD_ONLY
Domain ends with lithium.com	LITHIUM_DOMAIN_NAME
Domain resolves to a private/local IP (see below)	IS_LOCALHOST
Fewer than 2 dots in the domain	INVALID_DOMAIN_NAME

The error displayed in the UI for any of these failures is: "An unidentified problem occurred during the action you took. Please try again later."

Private / Internal IP Blocking

Aurora resolves the hostname at save time and blocks any domain that resolves to a private or internal IP address. The following address ranges are blocked:

• 10.x.x.x (Class A private)
• 172.16.x.x – 172.31.x.x (Class B private)
• 192.168.x.x (Class C private)
• 127.x.x.x (loopback)
• 169.254.x.x (link-local)
• Multicast addresses

This is enforced because Aurora Endpoints run in Khoros cloud infrastructure and cannot reach private/internal network addresses. The UI blocks these domains to prevent misconfiguration.

Resolving Private-IP Rejections

If your domain is rejected because it resolves to a private IP:

1. Verify DNS resolution from a public resolver (not from inside your corporate network):
   • Use dnschecker.org, or
   • Run nslookup yourdomain.example.com 8.8.8.8, or
   • Run dig yourdomain.example.com @8.8.8.8
2. If the result shows a private IP, expose the service via a publicly accessible endpoint. Common approaches:
   • Place the service behind a Public Load Balancer
   • Use an API Gateway
   • Use a Reverse Proxy with a public IP
   • Map DNS to a public NAT gateway
3. Once the domain resolves to a publicly routable IP, retry adding it in Endpoint Settings.

mTLS Client Certificates — Not Supported

Aurora Endpoints provide an outbound fetch capability for calling external APIs, but there is no supported mechanism to upload, install, or attach a client certificate (e.g. a PFX file) to outbound requests.

Key constraints:

• The Endpoint runtime does not expose the Node.js https or fs modules. Attempting to import them will cause a build failure (e.g. "Cannot find https in plugin").
• Endpoint package.json dependencies are restricted to an allowlist; adding arbitrary npm packages will fail the build and prevent the Endpoint from being installed.
• The Allowed Domains setting is purely an outbound hostname allowlist — it does not configure mutual TLS.

Workaround for mTLS Requirements

If your external service requires mTLS (client certificate authentication), use an intermediary service pattern:

1. Deploy an intermediary (API gateway, reverse proxy, or lightweight service you control) that:
   • Accepts inbound HTTPS calls from Aurora without requiring a client certificate.
   • Makes the outbound call to your target service using mTLS with your client certificate.
2. Allowlist the intermediary's hostname in Aurora Endpoint Settings (e.g. .proxy.example.com).
3. Secure the intermediary so only Khoros can call it. You can IP-allowlist the Aurora outbound static IP addresses to restrict access.

This keeps the Aurora Endpoint calling a standard HTTPS endpoint while your intermediary handles the mTLS handshake.

FAQ

Q1: Why do I get "An unidentified problem occurred" when adding a domain?
A1: Aurora performs several validation checks at save time (see Domain Validation Rules). The most common causes are entering the domain without a leading dot, the domain resolving to a private IP address, or the domain containing invalid characters. Verify the format and public DNS resolution, then retry.

Q2: Can I use wildcard entries like *.example.com in the Allowed Domains list?
A2: No. Aurora uses a domain-suffix format with a leading dot (e.g. .example.com), not traditional wildcard syntax. The leading-dot suffix inherently covers all subdomains under the specified domain.

Q3: Is there a way to request native mTLS support for Aurora Endpoints?
A3: This would be a feature request. Contact your Account Manager to discuss the requirement and have it submitted to the Khoros product team for consideration.