The message ‘There is an error processing your request’ is one of Magento’s generic error messages. It appears in several contexts and from several different causes. Some are SSL-related; others are not. This guide focuses on the SSL and HTTPS causes specifically, which are the most common source of this error after a store migrates from HTTP to HTTPS, after an SSL certificate is installed or replaced, or when payment gateway connections start failing.
Before working through SSL-specific causes, confirm the error is SSL-related by checking Magento’s error logs. The log files are located at var/log/exception.log and var/log/system.log in your Magento root directory. If the log shows cURL errors with SSL-related codes (such as SSL certificate problem, unable to get local issuer certificate, or SSL handshake failure), proceed with this guide. If the log shows database connection errors or permission errors, the cause is not SSL-related.
SSL Causes of This Error: Quick Diagnosis
| When the error appears | Most likely SSL cause |
| Immediately after installing or switching to HTTPS | Base URL not updated in Magento configuration; secure_base_url in database still points to HTTP or wrong domain |
| On the checkout page specifically | Secure URL not enabled for the frontend; or SSL offload header not set (load balancer/CDN environment) |
| When processing payments (card entry or payment gateway redirect) | Outbound SSL failure: Magento cannot verify the payment gateway’s SSL certificate; outdated cacert.pem |
| After the server or SSL certificate was changed | Payment gateway CA chain changed; Magento’s bundled CA bundle does not include the new root |
| Intermittently across the site | Mixed content causing blocked resources on checkout; session cookie not set to secure flag |
Cause 1: Base URL Not Updated After SSL Installation
Magento stores its base URL configuration in the database in the core_config_data table, not just in configuration files. When a store migrates from HTTP to HTTPS, the base URL must be updated both in the Magento admin panel and, if the admin is inaccessible due to redirect loops, directly in the database.
If the base URL is still set to http:// after SSL is installed, Magento generates HTTP links internally. Browsers connecting over HTTPS receive pages with HTTP resource URLs, causing mixed content errors and redirect loops that can trigger the generic error message.
Magento 2: Updating base URL in the admin panel
Go to Stores, then Settings, then Configuration. Under General, select Web. Expand the Base URLs (Secure) section. Update the Secure Base URL to https://yourdomain.com/. Ensure Use Secure URLs on Storefront is set to Yes. Ensure Use Secure URLs in Admin is set to Yes. Save the configuration. Go to System, then Cache Management and flush all caches.
Magento 1: Updating base URL in the admin panel
Go to System, then Configuration. Under General, select Web. Click on the Secure tab. Update the Base URL to https://yourdomain.com/. Set Use Secure URLs in Frontend to Yes. Set Use Secure URLs in Admin to Yes if desired. Save configuration. Go to System, then Cache Management and refresh all cache types.
When the admin is inaccessible: updating core_config_data directly
If the redirect loops or SSL errors prevent access to the Magento admin panel, update the base URL directly in the database:
| — Check current base URL values in Magento database:
SELECT path, value FROM core_config_data WHERE path IN (‘web/secure/base_url’, ‘web/unsecure/base_url’);
— Update the secure base URL: UPDATE core_config_data SET value = ‘https://yourdomain.com/’ WHERE path = ‘web/secure/base_url’;
— Also update the unsecure URL if redirecting HTTP to HTTPS: UPDATE core_config_data SET value = ‘https://yourdomain.com/’ WHERE path = ‘web/unsecure/base_url’;
— After updating, clear Magento cache by deleting var/cache/ contents — or running: php bin/magento cache:flush (Magento 2) |
Always back up the database before making direct SQL changes. Updating core_config_data directly bypasses Magento’s configuration layer. After making the change, clear the Magento cache from the command line or by deleting the var/cache/ and var/page_cache/ directories. If you have a Magento 2 setup with a Redis or Varnish cache, flush those as well.
Cause 2: Secure URL Not Enabled for Checkout
In Magento, the secure base URL setting and the ‘Use Secure URLs’ setting are separate. A store can have a valid https:// base URL configured but still serve the checkout process over HTTP if the Use Secure URLs setting is disabled. This creates a situation where the cart and product pages load over HTTPS but the checkout page loads over HTTP, causing session and cookie problems that produce the error message.
In Magento 2, verify both Use Secure URLs on Storefront and Use Secure URLs in Admin are set to Yes in Stores, Configuration, General, Web, Base URLs (Secure). In Magento 1, verify both Use Secure URLs in Frontend and Use Secure URLs in Admin are set to Yes in System, Configuration, General, Web, Secure tab.
Cause 3: SSL Offload Header Not Set (Load Balancer and CDN Environments)
When TLS terminates at a load balancer, Cloudflare, or similar infrastructure, the Magento application server receives HTTP requests internally even though visitors see HTTPS. Magento does not know the original connection was HTTPS and may generate HTTP URLs, create redirect loops on checkout, or produce session errors.
Magento supports an SSL offload configuration that tells it to trust a specific HTTP header indicating the original connection was HTTPS. In Magento 2, this is configured in app/etc/env.php under the MAGE_RUN_TYPE and related settings, or via the X-Forwarded-Proto header configuration in the web server. In Magento 1, the offload header is configured in System, Configuration, General, Web, Secure, Offloader Header, where the value should be set to SSL_OFFLOADED (or X-Forwarded-Proto depending on your load balancer).
For Nginx in front of Magento, ensure the Nginx configuration passes the X-Forwarded-Proto header to the PHP-FPM backend, and that Magento is configured to trust it. Without this, Magento on a load-balanced or CDN-proxied server will have redirect loops and SSL-related errors in the checkout process even when the certificate and base URL are correctly configured.
Cloudflare users should set Cloudflare’s SSL/TLS mode to Full (Strict) rather than Flexible. With Flexible mode, Cloudflare connects to the Magento origin over HTTP while Magento is configured to use HTTPS URLs, creating the same offload header inconsistency. Full (Strict) mode connects Cloudflare to the origin over HTTPS, which is the consistent configuration.
Cause 4: Outbound SSL Connection Failures to Payment Gateways
Magento makes outbound HTTPS connections to external services: payment gateways (PayPal, Stripe, Authorize.net, Braintree), shipping APIs (FedEx, UPS, USPS), and extension API endpoints. These outbound connections use PHP’s cURL library, which validates the SSL certificate of the remote server against a CA bundle.
If the remote server’s SSL certificate has changed its certificate chain and the new root CA is not in the server’s cacert.pem file, the cURL call fails with an SSL verification error. Magento translates this as ‘there is an error processing your request’ rather than showing the underlying cURL error to the customer.
Identifying outbound SSL failures
Check var/log/exception.log and var/log/system.log. Outbound SSL failures appear as cURL error 60 (SSL certificate problem: unable to get local issuer certificate), cURL error 35 (SSL connect error), or similar. The log entry typically includes the URL that failed, making it clear which payment gateway or API is involved.
Updating the CA bundle
The CA bundle used by PHP’s cURL is configured in php.ini as curl.cainfo. The bundle should be a current cacert.pem file from curl.se/ca/cacert.pem, which is updated when major CAs add or rotate their root certificates.
Download the current cacert.pem from curl.se/ca/cacert.pem. Place it in a location accessible to the web server user. Update php.ini to point curl.cainfo to the new file. Restart PHP-FPM or the web server. Test the payment integration.
On managed hosting platforms, the system PHP may have an outdated CA bundle that you cannot directly update. Contact your hosting provider and request a PHP CA bundle update, or ask them to update the system certificate store (update-ca-certificates on Debian/Ubuntu, or update-ca-trust on Red Hat/CentOS).
Payment gateway CA chain changes
Payment gateways periodically update their SSL certificates or change their CA chain. When a gateway moves from one CA to another, stores running older server configurations that do not include the new CA’s root certificate begin seeing payment failures with SSL verification errors.
This was the cause of a documented error with Authorize.net when they changed their certificate provider: stores using older PHP environments failed because the new Authorize.net certificate chain included a root CA not in their cacert.pem. The fix was updating the CA bundle to include the current set of trusted roots.
Cause 5: Mixed Content on Checkout Pages
If the checkout process loads any resources over HTTP while the page is served over HTTPS, modern browsers block active mixed content (scripts, iframes). If a blocked script is part of the checkout process, the checkout fails, and Magento may show the generic error message to the customer rather than a meaningful SSL error.
Common sources of mixed content on Magento checkout pages: third-party payment method widgets loaded over HTTP, shipping estimation widgets with hardcoded HTTP URLs, tracking or analytics scripts inserted via third-party extensions using HTTP, and custom checkout modifications that include HTTP resource URLs.
To identify mixed content: open the checkout page in a browser with developer tools (F12), go to the Console tab, and look for mixed content warnings or errors. Each warning identifies the specific HTTP URL. Address each one by updating the resource to its HTTPS equivalent or removing it if it does not support HTTPS.
Cause 6: Session Cookie Not Configured for HTTPS
Magento uses session cookies to maintain the shopping cart and user authentication across checkout steps. When a store switches to HTTPS, session cookies should be set with the Secure flag, which instructs the browser to only send the cookie over HTTPS connections. If the Secure flag is not set and there is any HTTP access to the site, the session cookie may not be sent on HTTPS requests, causing checkout failures.
In Magento 2, this is configured in app/etc/env.php in the session storage section, or via the Magento admin under Stores, Configuration, General, Web, Session Validation Settings, Use Secure Key. In Magento 1, the session cookie settings are in System, Configuration, General, Web, Session Cookie Management.
Additionally, if the base URL is configured as HTTPS but the session starts on an HTTP page before the HTTPS redirect, the session data may not transfer correctly. Ensuring all pages redirect to HTTPS before any session data is set prevents this.
After Any SSL Configuration Change: Cache and Reindex
After making any SSL-related configuration change in Magento, clearing the cache and running a reindex are required to apply the changes. Magento aggressively caches configuration data and generated URLs. If the cache is not cleared after updating the base URL or SSL settings, the cached HTTP URLs continue to be used despite the new configuration.
- Magento 2 command line: php bin/magento cache:flush and php bin/magento indexer:reindex to clear all caches and rebuild indexes.
- Magento 2 admin panel: System, then Cache Management. Select All and click Flush Magento Cache, then Flush Cache Storage.
- Magento 1 admin panel: System, then Cache Management. Select All cache types and click Flush Magento Cache.
- Varnish: If using Varnish as a full-page cache, purge the Varnish cache separately. Magento 2’s admin cache management includes a Flush Varnish Cache button if Varnish is configured.
Frequently Asked Questions
Why does ‘there is an error processing your request’ appear after installing SSL?
The most common cause is that the Magento base URL was not updated after SSL was installed. Magento stores its base URL in the database in the core_config_data table. After installing SSL, the base URL must be updated from http:// to https:// in the Magento admin panel (Stores, Configuration, General, Web in Magento 2) and the cache must be cleared. If the base URL still points to HTTP, Magento generates HTTP links internally and the HTTPS setup produces errors.
How do I fix the error when I cannot access the Magento admin?
If redirect loops or SSL errors prevent admin access, update the base URL directly in the database. Connect to your MySQL database and run: UPDATE core_config_data SET value=’https://yourdomain.com/’ WHERE path=’web/secure/base_url’; and the same for web/unsecure/base_url if you are redirecting all HTTP to HTTPS. After the database update, clear the Magento cache by deleting the var/cache/ and var/page_cache/ directories manually, or renaming them and letting Magento regenerate them on next access.
Why do payment errors appear specifically at checkout?
Checkout payment errors related to SSL usually have one of two causes. First, the secure URL settings in Magento may not be enabled for the storefront, causing the checkout to serve over HTTP despite the certificate being installed. Enable Use Secure URLs on Storefront in Stores, Configuration, General, Web. Second, Magento’s outbound connection to the payment gateway may be failing because the payment gateway changed its SSL certificate chain and the server’s CA bundle does not include the new root CA. Check var/log/exception.log for cURL SSL errors identifying which remote URL is failing.
How do I find the Magento error logs to diagnose SSL errors?
Magento’s error logs are in the var/log/ directory in your Magento root folder on the server. The main files are exception.log (all PHP exceptions and errors) and system.log (system-level events including API calls). Access these via FTP, SFTP, or SSH. If you have SSH access, the tail command shows the most recent entries in real time. For managed hosting without SSH, use an FTP client to download the log files. The logs record the actual underlying error (cURL SSL error code, database error, etc.) behind the generic error message shown to customers.
