SSL Monitoring for Magento Agencies: Adobe Commerce Cloud, Fastly, and Multi-Store Domains

Magento agencies managing enterprise client deployments deal with more SSL complexity per client than almost any other platform. A single Adobe Commerce Cloud deployment has three environments with separate SSL, a Fastly CDN layer with its own TLS provisioning, and often multiple store view domains for different brands or regions. Each of these certificates expires independently.

This post covers where SSL expiry hides in Magento deployments, how Fastly CDN changes the SSL monitoring picture, and what agencies need to include in scope to avoid SSL failures on client stores.

Adobe Commerce Cloud Environments and Independent SSL

Adobe Commerce Cloud — Magento's managed cloud platform — assigns each project environment a separate URL and supports custom domain mapping for each. A standard client project has three environments: production (clientstore.com), staging (staging.clientstore.com), and integration (integration.clientstore.com). When an agency configures custom domains for these environments, each domain gets its own SSL certificate provisioned through the Magento Cloud project configuration.

The three environment certificates are provisioned at different times and expire on different schedules. The production certificate receives the most attention because the production store has real customers. Staging and integration certificates receive less attention because they are used for internal reviews, QA testing, and CI/CD pipeline runs.

SSL expiry on staging blocks client QA cycles and CI/CD deployments. SSL expiry on integration breaks the automated build pipeline that runs against the integration environment before deploying to production. Neither failure is as visible as a production store SSL error — but both create real problems at the worst possible timing: when a client is reviewing features before a scheduled release, or when a planned deployment is blocked by a CI/CD pipeline SSL failure.

How Fastly CDN Changes the SSL Picture for Magento Cloud

Adobe Commerce Cloud uses Fastly as its default CDN and edge layer. When a custom domain (clientstore.com) is configured on a Magento Cloud project, the DNS configuration points the domain at a Fastly edge hostname — not directly at the Magento application server. Fastly terminates SSL at the edge and forwards traffic to the Magento origin over a separate connection.

This creates two independent SSL certificates for the same store domain:

Fastly edge certificate — The certificate that shoppers' browsers verify. Provisioned by Fastly's TLS service when the custom domain is configured. Renewed by Fastly automatically — but only when the DNS CNAME continues to point at the correct Fastly hostname.
Magento origin certificate — The certificate on the application server. Used by Fastly when forwarding requests to the origin. Not visible to shoppers directly, but required for the Fastly-to-origin connection when Fastly's encryption mode is Full or Full Strict.

Most agencies configure the Fastly edge certificate correctly at launch. The failure mode is time-delayed: when a client changes their DNS provider six months after launch, the new DNS zone is rebuilt from an export of the old zone. CNAME records for Fastly are sometimes modified during this process — the TTL is changed, the target is slightly different, or the record is omitted. The Fastly edge certificate renewal fails at the next cycle (90 days for Let's Encrypt, or at the custom certificate renewal date). The existing certificate serves until expiry. The store begins returning SSL errors to shoppers — often months after the DNS change that caused the problem.

Magento Multi-Store SSL: One Install, Multiple Certificate Schedules

Magento's Multi-Store feature allows a single installation to serve multiple websites and store views, each mapped to a different domain. A common configuration for enterprise agencies: clientbrand.com (primary retail), wholesale.clientbrand.com (B2B portal), clientbrand.eu (European regional store), and clientbrand.co.uk (UK regional store) all run from one Magento installation with separate store view configurations.

Each domain has an independent SSL certificate. The B2B wholesale portal runs on different infrastructure from the retail store, with SSL provisioned separately. The European and UK regional stores may have SSL managed through different CDN configurations or different Fastly custom TLS setups.

The practical problem for agencies: the certificate for the B2B portal or a regional store expires without triggering any of the monitoring that covers the primary retail store. An agency that monitors clientbrand.com — where most of the client's revenue comes from — has no visibility into the SSL health of wholesale.clientbrand.com or the regional stores. When the B2B portal SSL expires, the client's wholesale sales team cannot log in and place orders. The failure is reported as a product outage — not an SSL certificate issue — because the error message in most B2B sales applications is a generic connection failure rather than an SSL warning.

The Headless Magento Frontend SSL Problem

Agencies building headless Magento deployments deploy the Magento backend on one domain (api.clientstore.com or backend.clientstore.com) and a PWA or JavaScript frontend on the primary store domain through a CDN like Netlify, Vercel, or Cloudflare Pages. The backend SSL and the frontend SSL are provisioned and managed separately.

When the Magento backend SSL expires — on the api.clientstore.com or backend.clientstore.com endpoint — the PWA frontend continues to load, but all data fetching from the Magento GraphQL or REST API fails. Products do not load. The cart is empty. Checkout fails. The frontend appears functional, but all dynamic content from Magento is inaccessible.

For customers, the experience is a store that shows the shell of a website with no products. For the agency, the first escalation is typically a report that "the store is empty" or "products aren't showing" — not an SSL error, because the frontend SSL is valid and the browser shows no certificate warning.

What Magento Agencies Should Monitor

Adobe Commerce Cloud production custom domain — The primary store SSL, usually fronted by Fastly. Both the Fastly edge certificate and the Magento origin certificate need to be monitored independently.

Staging and integration environment domains — Staging.clientstore.com and integration.clientstore.com should be monitored with the same lead time as production. CI/CD pipeline failures from staging SSL expiry can block production deployments at release-critical moments.

All Multi-Store domain variants — Every store view mapped to a different domain (regional stores, B2B portals, brand variants) needs independent SSL monitoring. These certificates expire on different schedules from the primary retail domain.

Headless backend API subdomain — For decoupled Magento deployments, api.clientstore.com or backend.clientstore.com carries SSL independent from the frontend. Backend SSL expiry surfaces as missing product data, not a browser SSL warning.

CNAME integrity on Fastly-routed domains — The most important DNS check for Magento Cloud deployments. Fastly edge certificate renewal depends on the CNAME pointing at the correct Fastly hostname. CNAME integrity monitoring catches DNS changes before the renewal cycle fails — not 90 days later when the certificate expires and the store goes down.

Adding Magento Domains to SSL Monitoring

Merlonix verifies domain ownership once via DNS TXT record on the apex domain. All subdomains — staging.clientstore.com, integration.clientstore.com, api.clientstore.com, and Multi-Store regional domains under that apex — are added without re-verification.

For Magento Multi-Store domains on separate apex domains (clientbrand.eu, clientbrand.co.uk), each apex domain requires separate ownership verification. Under two minutes each.

CNAME integrity checks run on every monitoring interval for all configured domains. When a client DNS change breaks the Fastly CNAME for a Magento Cloud custom domain, the mismatch alert fires within minutes — before the certificate renewal cycle has a chance to fail.