Whether the site forces HTTPS. No-SSL means consumer keys + customer PII fly in plaintext on every REST call, direct PCI/GDPR exposure. Top-3 audit (WC03).
At a glance
Real-time check that the WooCommerce store forces HTTPS. No-SSL means consumer keys and customer PII fly in plaintext on every REST call, a direct PCI / GDPR exposure.
Calculation
Calculated automatically from your WooCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A self-hosted UK fashion brand on Bluehost shared hosting. Polled 12 Apr 26.
The card flips to “at risk” with two findings: force-SSL disabled, cert expiring in 8 days. Three observations:
- Self-hosted variance is the recurring theme. Bluehost’s Let’s Encrypt auto-renew has a known intermittent failure mode where the renewal cron does not run if the host throttled the merchant for resource use. This brand has tripped the renewal failure twice in 6 months. Managed-Woo hosts (Pressable, Kinsta) operate their own renewal pipeline and rarely fail.
- Plugin-induced data shape variance:
force_ssl_checkoutreset. A WooCommerce update in early April migrated some legacy settings, includingforce_ssl_checkoutfor stores that had it set via constants inwp-config.php. The setting silently flipped to false on dozens of stores. This card caught it within an hour of the next poll. - Customer impact is non-obvious. With
force_ssl_checkoutoff, the checkout page still loads over HTTPS for users typing the full URL, but customers landing onhttp://versions of product pages stay on HTTP through checkout, exposing card data on the wire. This is a PCI compliance breach that does not trigger any user-visible browser warning until the form posts.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in WordPress / WooCommerce Admin: WP Admin → Settings → General forsiteurl. WP Admin → WooCommerce → Settings → Advanced → Page setup → Force secure checkout. Cert details typically need a separate tool (host control panel or openssl s_client).
Why our finding may differ from WP Admin:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Self-hosted vs managed-Woo, why does it matter? Self-hosted owns SSL renewal end-to-end. Auto-renewal on cheap shared hosting can fail silently. Managed-Woo handles SSL transparently. Status-filter selection, why include cert expiry? A 14-day expiry warning gives the merchant time to act. Beyond 14 days the issue is severity-low; under 14 days it is high-severity (cert expiry breaks the entire site instantly). Refund-object accounting? Not applicable. Plugin-induced data shape variance? “Really Simple SSL” and “WP Force SSL” plugins rewrite HTTP to HTTPS at runtime via output buffering. These maskforce_ssl_checkout = false from the customer’s perspective but not from the configuration. An attacker bypassing the plugin (e.g. via a direct wp-cron.php call) would still expose plaintext data. Vortex IQ flags the underlying config, not the runtime override.
Multi-currency, does it affect SSL?
No, currency-independent.
Why does Woo and Stripe disagree?
Stripe does not measure SSL. They only verify that webhook URLs are HTTPS.
Today is jumpy, why?
Stable. The card flips on / off discretely on configuration change or cert expiry.
Sync-lag from self-hosted server slowness?
Hourly poll. Cert expiry detection runs on the polled value; brief outages mean detection is up to 1 hour late, not a problem for a 14-day countdown.
My WP Admin shows SSL is fine, why is the alert firing?
- Verify
force_ssl_checkoutin WC Settings. - Check cert expiry directly:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates. - If using a Really Simple SSL plugin, disable it temporarily and check whether the site still loads on HTTPS, the plugin may be masking a real config gap.
- If genuinely fine, contact support.