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.

  1. 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.
  2. 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.
  3. 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.

Allakkat attuumassuteqartut