Ssl Certificate Laravel Package

Product Decisions This Supports

• Certificate-expiry monitoring as a first-class product surface. daysUntilExpirationDate(), isValidUntil(Carbon $date) and isExpired() give you the primitives for a "90/30/7-day" alerting ladder. PM decision enabled: do we ship proactive expiry warnings (reducing support tickets and outage risk) or stay reactive?
• Portfolio/domain coverage audits. getDomains(), getAdditionalDomains() and wildcard-aware isValid($domain) let you answer "does our certificate actually cover www., api. and the new regional subdomain we just launched?" This directly informs decisions about launching new subdomains and consolidating vs. splitting certificates.
• Crypto-agility and security-posture reporting. getSignatureAlgorithm(), getPublicKeyAlgorithm(), getPublicKeySize(), usesSha1Hash() and isSelfSigned() turn "are we on SHA-1 / 1024-bit keys anywhere?" from an audit project into a scheduled report. This supports roadmap decisions on deprecating legacy integrations and preparing for CA/Browser Forum rule changes.
• Third-party integration readiness. Before committing to a vendor integration or a customer-facing SLA, SslCertificate::createForHostName() lets you verify the counterparty's certificate properties (issuer, validity window, key strength). Useful input for build-vs-buy and vendor-risk scoring, and for a pre-flight check in onboarding flows.
• Inventory and change-evidence. toArray()/createFromArray(), getFingerprint(), getFingerprintSha256() and getSerialNumber() give you a snapshot you can store and diff over time — a cheap audit trail for "when did this certificate change?" questions from security or compliance.
• Build vs. buy for ops tooling. This replaces hand-rolled openssl_x509_parse glue and one-off shell scripts. Decision enabled: build the internal certificate dashboard on top of 200 lines of our own code plus this package, rather than buying a certificate-lifecycle SaaS seat per domain.
• Internal admin/support tooling. Because it accepts a file, a string, or a live host (including custom ports and IP targets), the same class powers an admin panel "check this domain's cert" button and a queued background scanner — one dependency, two surfaces.

Important scoping decision this package does not make for you: the README's own "Important notice" states it does not verify that a certificate is signed by a trusted authority. Treat it as a certificate property reader, not a TLS validator. Any roadmap item framed as "we validate TLS" cannot be satisfied by this package alone — pair it with actual handshake validation (curl/Guzzle, openssl s_client, or a scanning vendor) if trust is the requirement.

When to Consider This Package

Adopt when:

• You are on PHP 8+ and already in the Spatie/Laravel ecosystem — the API is idiomatic, MIT-licensed, and dependency-light.
• Your need is metadata and monitoring: expiry alerts, SAN coverage checks, issuer/key-algorithm reporting, certificate snapshots for audit.
• You want low lock-in: it is a thin, readable wrapper over PHP's OpenSSL extension. Worst case, you fork or reimplement in a day.
• The consumers are internal — ops dashboards, scheduled jobs, admin panels, pre-integration checks — where a best-effort read is acceptable.
• You can isolate the network calls: run scans from a queued job or scheduler with explicit timeouts, not inline in a request cycle. Decide this up front; createForHostName() is blocking I/O against a remote host.

Look elsewhere when:

• Trust verification is the requirement. No chain-of-trust validation, no revocation checking (OCSP/CRL), no hostname-verification-as-a-control. Use the HTTP client's TLS stack or a dedicated scanner.
• You need a monitoring product, not a library. Global vantage points, CT-log monitoring, alert routing, on-call integration and SLA reporting are out of scope. A certificate read from inside your VPC can differ from what the public internet sees (CDN edges, SNI-based serving, split-horizon DNS) — a real limitation for customer-facing availability decisions.
• You need compliance-grade attestation. If an auditor must accept the output, a self-built scanner plus a library with a documented "we don't check trust" caveat is a weak artifact. Buy a recognized scanner.
• Documentation depth matters to your team. Maturity is README + changelog + tagged releases; there is no dedicated docs site or long-form guidance. Fine for a utility class, thin for a platform team onboarding juniors.
• Volume is high or the stack is polyglot. Per-host TCP handshakes don't scale cheaply, and a non-PHP estate gets no reuse.
• You need guarantees on maintenance. Weigh the adoption signal carefully: the "0 dependents" figure in the evaluation is almost certainly a telemetry artifact rather than reality, but verify against Packagist download counts and recent commit activity before you build a roadmap item on it. The latest release date and steady 2.x changelog (PHP 8.2 compatibility, IPv6, DER files, SHA-256 fingerprints, public-key algorithm/size) suggest it is alive — confirm, don't assume.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can cut a recurring class of customer-visible outages — expired or mis-scoped TLS certificates — and answer security questions about our certificate estate, for the cost of a small MIT-licensed dependency rather than a per-domain SaaS contract. It gives us expiry dates, covered domains, issuer, key algorithm and size, and fingerprints as plain PHP objects, so we can add proactive expiry alerting and a crypto-posture report to the existing ops dashboard in days, not a quarter. It is a visibility tool, not a security control: it explicitly does not verify that a certificate is signed by a trusted authority, so we should position it as monitoring and inventory, and keep real TLS validation in the HTTP layer or a scanning vendor. Net: low cost, low lock-in, clear scope, no overclaiming.

For engineering (the practical case):

• What it is: Spatie\SslCertificate\SslCertificate — named constructors (createForHostName, createFromFile, createFromString, createFromArray) plus a fluent downloader (usingPort, fromIpAddress incl. IPv6, withSocketContextOptions, usingSni, withFullChain, withVerifyPeer/withVerifyPeerName) and typed accessors returning Carbon instances or scalars.
• Why not roll our own: it replaces scattered openssl_x509_parse code, handles wildcard matching edge cases (a wildcard does not cover the root domain), and is covered by a Pest test suite on GitHub Actions.
• Boundaries to design around: no trusted-authority check (per README), no revocation checking, and createForHostName() performs blocking network I/O — wrap it in queued jobs with explicit timeouts, cache results, and never call it in a request path.
• Rollout plan: (1) scheduled scan of our domain list writing toArray() snapshots; (2) alert thresholds at 30/14/7 days via isValidUntil(); (3) a "certificate health" panel reading the snapshots; (4) a one-off SHA-1 / small-key / self-signed sweep using usesSha1Hash(), getPublicKeySize(), isSelfSigned(). Step 4 is the highest-value, lowest-effort item — start there.
• Failure modes to test: unreachable hosts and CouldNotDownloadCertificate, invalid hostnames (InvalidUrl), invalid IPs (InvalidIpAddress), expired certs where you want the data (createForHostName($host, $timeout, false)), and certificates served differently behind a CDN. Log and surface these — a silent scan failure is worse than no scan.