SSL Certificate Errors After Redirects with a Custom CA Bundle
Check whether an explicitly selected CA file contains all trust material needed by the actual request path, including redirected hosts.
The company CA file fixes the first URL, then a redirect fails verification. Check whether the custom CA option replaced the client's previous trust input rather than adding to it.
That behavior depends on the TLS backend and option. A file containing only the corporate CA can leave the client without other authorities it needs.
- Follow each peer. The first host may be intercepted under the corporate issuer. A later host can use a bypass, another inspection path or a publicly issued chain.
- Record the failing client's inputs. Keep the requested hostname, redirect target, received issuer, verification result and selected trust configuration. A working browser may use another root store.
- Check the backend's selection rules. curl builds can use native verification or file-based roots, and explicit CA options can alter that choice. A recipe for that executable does not configure a Python environment or JVM.
Use a maintained bundle or supported trust-store arrangement containing the public and private authorities the application is intended to trust. Do not add a CA's private key or promote each failing leaf certificate to a root merely to clear the next error.
Deliver the trust material through the deployment's supported update path. Manually replacing a vendor CA package can be undone by its next update; keep the owner and maintenance process explicit so verification continues across the full request route.