Slack outbound webhook failures with incomplete certificate chains on custom domains

Direct Answers

1. Full chain required; no AIA fetching. Slack's outbound client (JVM/Netty stack) validates the complete X.509 path against the Mozilla CA bundle. The server must present the leaf certificate plus all intermediates. Missing intermediates cause validation failure; the client does not attempt Authority Information Access (AIA) fetching.
2. Failures appear as generic connection errors. Chain validation errors are logged as connection_failed, timeout, or ssl_handshake_failure in Slack's integration logs and webhook delivery records. OpenSSL-level alert codes (e.g., certificate_unknown) are not exposed to administrators.
3. Retries treat DNS and TLS failures identically. During custom domain migration, DNS propagation delays produce transient TCP/TLS connection failures. Slack retries with exponential backoff (initial ~1 minute, maximum ~1 hour) for up to 24 hours before marking the URL permanently failing. Both DNS resolution failures and TLS handshake failures appear as delivery retries in the app's request logs.

Why This Matters

The lack of a distinct "certificate chain incomplete" error code means operators cannot differentiate a permanent misconfiguration (missing intermediate) from a transient DNS issue by looking at Slack logs alone. Both surface as repeated connection_failed entries with retry timestamps.

Verification Steps

Run these checks from a Linux host with a current ca-certificates package:

openssl s_client -connect <custom-domain>:443 -servername <custom-domain> -showcerts -verify_return_error

A successful verification returns exit code 0 and prints the full chain. A missing intermediate shows verify error:num=20:unable to get local issuer certificate even when the leaf certificate is valid.

Then trigger a test delivery from the Slack app configuration UI and inspect the delivery log for error classification and retry timestamps.

Operational Checklist

• Confirm your load balancer or CDN (Cloudflare, AWS ALB, etc.) serves the full chain, not just the leaf certificate.
• Check global DNS propagation with dig +trace <custom-domain> @1.1.1.1 and compare TTL values against observed retry intervals.
• If using Enterprise Grid with dedicated egress IPs, verify with Slack support whether a custom CA bundle is in use.

Assumptions and Uncertainty

Behavior described reflects typical JVM/Netty defaults as of 2024–2025. Slack may update its internal TLS stack without notice. Webhook retry counts and backoff intervals are platform-wide defaults and not configurable via API. DNSSEC validation failures on the custom domain will also appear as resolution errors, indistinguishable from propagation delays in Slack logs.

One diagnostic detail that changes the recommendation: Does your custom domain terminate TLS at a CDN or load balancer that might present a different certificate chain than the origin server? If yes, verify the chain at the edge endpoint that Slack actually connects to.