Ca Config Laravel Package

Product Decisions This Supports

• Onboarding and activation reliability. TLS handshake failures (“cURL error 60: unable to get local issuer certificate”) are a recurring first-run blocker for self-hosted installs, Docker deployments, Windows dev machines, and shared hosting. This package targets the root cause — resolving a usable default CA bundle — which maps directly to time-to-first-successful-request and setup drop-off.
• Support-cost reduction. CA misconfiguration generates a disproportionate share of “works on my machine” tickets. A deterministic resolver turns an open-ended debugging class into a controlled code path with a logged selected-CA source and an actionable error, instead of an opaque cURL failure.
• Security posture and compliance. The common workaround is verify => false. Any product handling customer data should treat “TLS verification stays on by default, everywhere” as a roadmap commitment; a CA-resolution layer makes that the path of least resistance. Note it only resolves where the bundle is — it never replaces actual verification, and the product must fail closed.
• Enterprise and air-gapped deployment readiness. Corporate TLS-inspection proxies, private PKI, and offline environments need a documented way to inject a custom CA bundle. This is a recurring procurement/security-review checkbox and a genuine blocker in regulated deals; a supported override key is the deliverable, not the library itself.
• Build vs. buy input. This is a thin, single-purpose utility. The real decision is “fund a small internal certificate-resolution helper or standardize on the already-ubiquitous composer/ca-bundle and wrap it” — framing that saves engineering a from-scratch design debate.
• Use cases to validate against: Laravel HTTP client / Guzzle calls to third-party APIs, webhook delivery, queue and scheduler workers in containers, mail and payment provider integrations, and any package we ship that performs outbound HTTPS on users’ behalf.
• Documentation caveat for planning: the package description reads as a generic array-backed config store, while the implementation and surrounding notes describe CA-bundle discovery for PHP HTTP clients. Treat the CA-resolution framing as authoritative and confirm scope before it enters any roadmap.

When to Consider This Package

Consider it only when all of the following hold:

• We have measured, recurring TLS/CA failures across a meaningful install segment (support tickets, failed health checks, activation telemetry) — not a hypothetical.
• We operate in environments we cannot fully control: third-party installs, multiple OS families, base images we don’t own, or customers behind TLS-inspection proxies.
• We specifically need CA detection heuristics — probing system trust stores and PHP INI settings (openssl.cafile, curl.cainfo) — beyond what our HTTP client already does.
• We are willing to pin a version, read and test the source, isolate it behind an internal adapter, and accept maintenance ownership if upstream stalls.

Look elsewhere — or build internally — when:

• Default Laravel usage is already sufficient. Guzzle resolves a CA bundle via composer/ca-bundle, present in effectively every Composer project and the de facto standard. Much of this package’s surface overlaps with it.
• Adoption signals matter. One star, zero dependents, a single maintainer: no ecosystem validation and real bus-factor risk. Nothing here becomes a critical-path dependency without a fork-and-vendor plan.
• We need framework integration. No service provider, config publishing, or facade — any Laravel wiring is our work.
• The actual problem is our images or docs. If failures stem from base images missing ca-certificates or from undocumented proxy setup, the fix is a Dockerfile and documentation change, not a dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap insurance policy against a specific and expensive failure mode — customers unable to connect our product to anything over HTTPS because their machine’s certificate configuration is unusual. It surfaces as failed installs, frustrated support tickets, and lost enterprise deals at security review. We are not proposing a large investment. The recommended action is a short spike to confirm the problem is real in our install base, then either a thin internal wrapper over the standard composer/ca-bundle or, if the detection logic proves valuable, a vendored fork of this library. Cost is days, not weeks; the return is fewer setup tickets and a clean answer to “how do you handle custom certificate authorities?”

To engineering: The package under evaluation is a narrow, lightly maintained utility for resolving a default CA bundle path. We should not adopt it as-is — one maintainer, no dependents, no Laravel integration, and some ambiguity between its stated description and its actual CA-resolution behavior. It is, however, a useful reference implementation for the detection cases we would otherwise forget (Windows, macOS, distro-specific bundle paths, INI overrides). The concrete ask is a timeboxed spike: inventory every PHP HTTP client and its current CA configuration, reproduce the top TLS failure modes in our Docker images and local dev setups, and determine how much composer/ca-bundle already covers. Deliver either a small config default or an internal CaBundleResolver adapter with an explicit override hook (env var or config key) for custom CAs, cached per process and logging which CA source was selected. Non-negotiable requirement: certificate verification stays enabled by default, failures are surfaced as actionable errors, and the fallback can never silently downgrade to an insecure connection.