Slack outbound webhook failures with incomplete certificate chains on custom domains

Enterprise Grid administrators configure custom domains for inbound webhook endpoints and API integrations, expecting Slack's outbound delivery to validate TLS certificates against the public Mozilla CA bundle. The platform rejects self-signed certificates and private CA chains without a public trust path, yet the exact handling of incomplete certificate chains — missing intermediate certificates — remains inconsistently documented. DNS resolution for these custom domains must also succeed before the TLS handshake begins, and propagation delays during migration can surface as transient 5xx errors that resemble certificate problems.

The goal is to determine whether Slack's outbound client performs full chain validation (requiring the server to present the complete chain) or attempts to fetch missing intermediates, and how it classifies the resulting failures in integration logs. This distinction affects how operators diagnose intermittent delivery failures versus permanent configuration errors.

• Does Slack's outbound HTTP client require the full certificate chain to be presented by the server, or does it attempt AIA fetching for missing intermediates?
• How are chain validation failures surfaced in the Slack API error codes — as distinct SSL handshake errors or grouped with generic connection timeouts?
• During custom domain migration, what is the expected retry behavior when DNS propagation delays overlap with certificate validation attempts?