How to Enable SSL Certificate or HTTPS on Magento 2

An SSL certificate is essential for a Magento 2 store because an ecommerce website handles considerably more sensitive information than an ordinary content website. Customer accounts, passwords, checkout details, addresses, payment information, session cookies, and communication between the browser and server all need to be protected while travelling across the network. Enabling HTTPS encrypts that communication and helps prevent attackers from intercepting or modifying traffic between customers and your store.

However, installing the certificate on the server is only the first part of the process. Magento 2 also needs to know that the storefront should use HTTPS, the Admin should use HTTPS, static files should be delivered securely, and HTTP requests should be redirected appropriately. If those pieces are not configured together, you can end up with redirect loops, broken CSS and JavaScript, mixed content warnings, inaccessible Admin pages, or checkout problems.

This guide explains how to enable an SSL certificate and HTTPS properly on Magento 2, including Magento configuration, command-line configuration, reverse proxies, static content, cache, redirects, HSTS, mixed content, and post-migration testing.

What Does HTTPS Do for a Magento 2 Store?

HTTPS uses TLS to establish an encrypted connection between the customer’s browser and your Magento server. The SSL certificate is part of the authentication process that allows the browser to verify that it is communicating with the expected domain rather than an impersonating server.

Although people commonly say “SSL certificate,” modern HTTPS connections use TLS (Transport Layer Security) rather than the older SSL protocols. The terminology remains common because SSL certificate is still widely used to describe the digital certificate associated with an HTTPS website.

If you want to understand what happens underneath HTTPS rather than treating the certificate as a simple browser padlock, it is useful to understand the technical details of TLS/SSL. The distinction becomes particularly important when troubleshooting certificate chains, protocol negotiation, or server-side TLS configuration.

For an ecommerce store, HTTPS protects more than the checkout page. Ideally, the entire Magento storefront and Admin should operate through HTTPS rather than switching between HTTP and HTTPS depending on the page.

Adobe’s current Commerce documentation strongly recommends serving production store pages through a secure protocol and provides separate settings for secure storefront and Admin URLs.

Before Enabling HTTPS: What You Need

Before changing Magento’s URL configuration, make sure the server-side HTTPS setup is actually working.

You should have:

• A registered domain pointing to the correct server or load balancer.
• A valid SSL/TLS certificate covering the hostname customers will use.
• The certificate and intermediate chain correctly installed.
• HTTPS configured on the web server, CDN, or load balancer.
• Port 443 available where required.
• Magento administrator access.
• Server or command-line access if you need to modify infrastructure or run Magento CLI commands.
• A recent backup before making configuration changes.

The certificate should be tested independently before changing Magento’s base URLs. If https://yourdomain.com does not already establish a valid secure connection, changing Magento’s URLs first can make troubleshooting unnecessarily difficult.

It is also worth checking the certificate’s chain rather than looking only at whether a browser displays a padlock. A valid certificate depends on a trust relationship that involves the certificate authority and intermediate certificates. This is where understanding the certificate chain of trust becomes useful when diagnosing certificate warnings.

Step 1: Confirm That HTTPS Works Before Changing Magento

Open your Magento domain directly using HTTPS:

https://yourdomain.com

At this stage, the important question is whether the server can successfully establish the secure connection.

Check that:

1. The certificate matches the domain.
2. The certificate is within its validity period.
3. The browser does not report certificate warnings.
4. The page is actually being served through HTTPS.
5. Static resources such as CSS, JavaScript, images, and fonts can also be retrieved.
6. There is no unexpected redirect loop between HTTP and HTTPS.

If HTTPS itself is not working, fix the web server, CDN, load balancer, or certificate configuration before modifying Magento.

This separation is important because an SSL certificate problem and a Magento URL configuration problem can produce very different symptoms.

Step 2: Configure Secure URLs in Magento 2 Admin

Once HTTPS is functioning correctly at the server level, log in to the Magento Admin panel.

Go to:

Stores → Settings → Configuration → General → Web

Magento provides separate configuration areas for ordinary Base URLs and secure Base URLs. Adobe’s current documentation identifies the Secure Base URL as the HTTPS address used for the Commerce installation and provides separate options for enabling secure storefront and Admin URLs.

Expand:

Base URLs (Secure)

You should see fields including:

• Secure Base URL
• Secure Base Link URL
• Secure Base URL for Static View Files
• Secure Base URL for User Media Files

For a typical installation, your secure base URL should look similar to:

https://www.example.com/

or:

https://example.com/

Use the exact hostname you intend customers to use. If your store is configured for www.example.com, do not randomly switch the secure URL to example.com during the migration unless your canonical domain and server redirects are also configured accordingly.

Adobe specifies that the secure base URL should use the https:// scheme and end with a trailing slash.

Step 3: Enable Secure URLs on the Storefront

Inside Base URLs (Secure), locate:

Use Secure URLs on Storefront

Set this option to:

Yes

This tells Magento to generate storefront URLs using HTTPS.

This setting is more important than simply redirecting HTTP traffic at the web-server level because Magento itself generates URLs throughout the application. Product pages, category pages, customer pages, forms, checkout URLs, media references, and other application-generated links need to understand that HTTPS is the preferred protocol.

Adobe documents this setting as the control that causes storefront URLs to begin with https when secure protocol is enabled.

Step 4: Enable Secure URLs in the Magento Admin

Next, locate:

Use Secure URLs in Admin

Set this to:

Yes

This ensures that administrative pages are also accessed through HTTPS.

Protecting only the storefront while leaving the Admin on HTTP creates an unnecessary security weakness. Magento administrators authenticate into a highly privileged interface, so credentials and authenticated sessions should not be transmitted through an unencrypted connection.

Adobe’s current configuration documentation explicitly provides a separate Use Secure URLs in Admin setting and recommends secure protocol usage for both storefront and Admin.

If you are managing an ecommerce website, the broader principles covered in how to secure a website are also relevant here because HTTPS is one component of a larger security architecture rather than the entire security strategy.

Step 5: Check the Secure Static and Media URLs

This step is easy to overlook.

Magento does not only generate page URLs. It also needs to reference static assets and user media such as:

• CSS
• JavaScript
• Images
• Fonts
• Theme resources
• Product images
• Other media files

Magento’s configuration includes separate fields for Secure Base URL for Static View Files and Secure Base URL for User Media Files. Adobe documents these as the secure locations used for static resources and user media.

For a standard installation, Magento’s placeholders normally handle these paths relative to the secure base URL. Do not change Magento’s placeholders simply because they look unfamiliar.

The important thing is to verify the generated storefront after HTTPS is enabled. If the page loads without styling or JavaScript, inspect the browser’s Network panel and determine whether the static resources are still being requested through HTTP.

Step 6: Save the Configuration and Clear Magento Cache

After changing the secure URL settings, click Save Config.

Magento can continue serving previously cached configuration and page information, so do not assume that saving the setting means every request immediately reflects the change.

From the Magento installation directory, you can check cache status with:

bin/magento cache:status

If necessary, clear the cache with:

bin/magento cache:clean

or:

bin/magento cache:flush

Adobe explains that cache:clean removes cached items from enabled Commerce cache types, while cache:flush purges the cache storage itself.

For a production store, understand which cache layers are involved before flushing everything. Magento may be behind Varnish, a CDN, a reverse proxy, or another caching layer, so an old HTTP page can continue to appear even after Magento’s own cache has been cleared.

Step 7: Redirect HTTP Traffic to HTTPS

Changing Magento’s secure URL does not remove the need for an HTTP-to-HTTPS redirect.

Customers, search engines, old bookmarks, external links, and crawlers may still request:

http://example.com

You want those requests to reach:

https://example.com

with an appropriate permanent redirect.

For Adobe Commerce on cloud infrastructure using Fastly, Adobe provides a Force TLS feature that redirects unencrypted requests to their TLS equivalents.

On other hosting environments, the redirect may be implemented in Nginx, Apache, a load balancer, CDN, or another edge service.

The important architectural rule is that you should have one clear HTTPS destination, not a chain such as:

HTTP
 ↓
HTTPS
 ↓
HTTP
 ↓
HTTPS

Redirect chains increase latency and can create confusing migration problems.

Step 8: Be Careful With Reverse Proxies and Load Balancers

Magento installations increasingly operate behind load balancers, CDNs, or reverse proxies.

A typical architecture might look like:

Customer Browser
       |
      HTTPS
       |
CDN / Load Balancer
       |
      HTTP
       |
Magento Application

The internal HTTP connection does not automatically mean the customer’s connection is insecure. The important question is whether Magento correctly understands the original client protocol.

If the proxy terminates HTTPS but Magento believes the visitor arrived over HTTP, Magento can generate incorrect HTTP URLs. That can lead to redirect loops, insecure links, or mixed-content warnings.

Magento provides an Offloader Header configuration for identifying the protocol between the client and load balancer. Adobe states that X-Forwarded-Proto is the default used by most Commerce installations, although the correct value depends on the infrastructure.

Do not copy a proxy configuration from another Magento installation without checking your actual architecture. The correct header and trusted-proxy behavior depend on how traffic reaches your application.

Step 9: Fix Mixed Content After Enabling HTTPS

One of the most common Magento HTTPS problems is a page that technically loads through HTTPS but still requests resources through HTTP.

For example:

https://example.com/product.html

may request:

http://example.com/static/frontend/theme/style.css

or:

http://cdn.example.com/image.jpg

The browser may block the resource or upgrade some requests automatically.

Open Chrome DevTools and inspect the Console and Network tabs. Look for requests containing http:// and identify whether they originate from Magento configuration, theme files, extensions, CMS content, JavaScript, CSS, or third-party services.

This is where a guide on fixing mixed content warnings on HTTPS websites becomes directly relevant. The underlying principle is the same for Magento: the page may be secure while one or more resources are still being requested through an insecure protocol.

Do not simply replace every http:// string in the Magento installation. Some URLs may be internal configuration values, development references, third-party integrations, or content that requires more careful handling.

Step 10: Regenerate Static Content When Necessary

Magento stores generated static resources in directories such as pub/static, and production deployments can require static content deployment after changes.

If the storefront displays symptoms such as:

• Missing CSS
• Broken JavaScript
• Missing images
• Incorrect theme layout
• 404 errors for static resources
• Old asset URLs

then the problem may not be the certificate itself. Magento’s generated static files or cache may still reflect an earlier configuration.

Adobe documents the static-content deployment process and explains that production-mode installations require static view files to be written to the Commerce filesystem.

A common deployment command is:

bin/magento setup:static-content:deploy

Do not run production deployment commands blindly on a live store. The correct deployment process depends on your Magento version, application mode, deployment architecture, languages, themes, and hosting environment.

If your deployment process already builds static assets on a separate build server, follow that process rather than generating files manually on production.

Step 11: Understand Magento Static Content Signing

Magento can append a deployment version to static resource URLs.

For example:

/pub/static/version123456/frontend/...

This mechanism helps browsers recognize that a static resource has changed and should be downloaded again.

Adobe recommends keeping static content signing enabled because it helps invalidate browser caches when static resources are deployed.

This matters after HTTPS migration because a browser can otherwise continue using cached versions of CSS or JavaScript that were generated before the configuration change.

If you have corrected HTTPS settings but the storefront still appears to load old resources, investigate static content deployment and cache invalidation before modifying application code unnecessarily.

Step 12: Consider HSTS, but Do Not Enable It Too Early

Magento provides an option for HTTP Strict Transport Security (HSTS) after secure URLs are enabled.

HSTS tells compatible browsers to use HTTPS for a domain rather than allowing ordinary HTTP connections.

This can strengthen HTTPS enforcement, but it should not be the first step in a migration.

Before enabling HSTS, verify that:

• The primary domain works through HTTPS.
• Important subdomains have been considered.
• Redirects work correctly.
• Static assets work through HTTPS.
• API endpoints work through HTTPS.
• Checkout works correctly.
• Admin works through HTTPS.
• Third-party integrations have been tested.
• Certificate renewal is reliable.

Magento’s current documentation exposes HSTS and Upgrade Insecure Requests under the secure web configuration after secure URLs have been enabled.

HSTS should reinforce a working HTTPS architecture rather than be used to cover up an incomplete migration.

Step 13: Understand Magento’s “Upgrade Insecure Requests” Setting

Magento also provides an Upgrade Insecure Requests option.

When enabled, Commerce can upgrade insecure HTTP requests to HTTPS. Adobe documents this setting as a way to convert unsecured requests received from the browser to the secure protocol.

This can be helpful when migrating a store with legacy HTTP references, but it should not replace fixing the original URLs.

Consider the difference:

Old image reference
       ↓
HTTP
       ↓
Browser upgrades request
       ↓
HTTPS

versus:

Correct image reference
       ↓
HTTPS
       ↓
Browser loads secure resource

The second approach is cleaner because the application itself is generating the correct URL.

Step 14: Test the Magento Storefront

After enabling HTTPS, do not stop after checking whether the homepage displays a padlock.

A Magento store has many dynamic components that need to be tested individually.

At minimum, test:

• Homepage
• Category pages
• Product pages
• Search
• Customer registration
• Customer login
• Password reset
• Shopping cart
• Checkout
• Payment gateway
• Shipping calculation
• Contact forms
• Product images
• JavaScript interactions
• Account dashboard
• Order history
• Admin login
• Admin dashboard

The checkout deserves particular attention because it combines customer sessions, forms, payment integrations, JavaScript, API calls, cookies, and redirects.

A certificate can be completely valid while one of these components is still generating HTTP URLs.

Step 15: Test the Magento Admin Separately

Do not assume that because the storefront works, the Admin is correctly configured.

Open your Magento Admin URL through HTTPS and verify that:

• The login page loads securely.
• CSS and JavaScript load.
• Login succeeds.
• The dashboard displays correctly.
• Forms work.
• Images and icons appear.
• Configuration pages load.
• Extensions function correctly.
• Session behavior remains stable.

Adobe’s documentation treats secure storefront and secure Admin URLs as separate configuration controls, so both need to be verified after the migration.

If the Admin suddenly redirects repeatedly or becomes inaccessible after changing the secure configuration, check the base URL, proxy configuration, cookie settings, and server-level redirects rather than immediately changing the certificate.

Common Magento 2 HTTPS Problems and Their Solutions

What If Magento Shows a Mixed Content Warning After SSL Installation?

Do not immediately reinstall the SSL certificate.

First determine what resource is causing the warning.

Open DevTools and inspect the exact HTTP request. If it points to a Magento static file, investigate the secure static URL and generated assets. If it points to a CMS image, inspect the stored content. If it points to an extension, investigate that extension. If it points to a CDN, inspect the CDN configuration.

This approach is much more efficient than repeatedly changing Magento’s main URL.

It also prevents a common mistake where an administrator assumes that a browser warning means the certificate itself is invalid.

Magento 2 HTTPS and Cookies

HTTPS should also be considered when reviewing session and cookie security.

Magento stores session-related information that should not be exposed through ordinary unencrypted connections. Once HTTPS is enabled across the storefront and Admin, review the store’s secure cookie behavior as part of the migration rather than treating URL configuration as the only security control.

This becomes particularly important if the store has custom authentication, third-party login, payment integrations, or extensions that create their own cookies.

The goal is not simply to make the browser display HTTPS. The application should consistently operate under the security assumptions created by an HTTPS deployment.

Should Every Magento Page Use HTTPS?

For a modern production ecommerce store, using HTTPS across the entire storefront is the better approach.

There is little practical reason to maintain a mixed HTTP/HTTPS Magento storefront when the store already has a valid certificate.

Adobe specifically recommends transmitting production Commerce pages through a secure protocol and supports secure URLs for both the storefront and Admin.

Using HTTPS throughout also simplifies:

• Canonical URL management
• Browser security
• Cookie protection
• Payment integrations
• Third-party services
• API communication
• Search-engine crawling
• Application development

The old practice of securing only login or checkout pages is no longer a sensible architecture for a modern ecommerce store.

Magento 2 HTTPS Configuration From the Command Line

For administrators who prefer CLI configuration or need to automate deployments, Magento provides secure installation and configuration parameters.

Adobe’s installation documentation specifies the secure options:

--use-secure=1
--base-url-secure=https://yourdomain.com/
--use-secure-admin=1

These parameters configure HTTPS for the storefront and Admin during installation or configuration.

For an existing production store, however, do not blindly rerun installation commands. Determine whether you are changing configuration on an existing environment, deploying through source control, or rebuilding an installation.

Magento’s configuration paths also expose the secure settings through configuration values such as:

web/secure/base_url
web/secure/use_in_frontend
web/secure/use_in_adminhtml
web/secure/enable_hsts
web/secure/enable_upgrade_insecure
web/secure/offloader_header

Adobe publishes these configuration paths in its current reference documentation.

HTTPS, SSL Certificate, and TLS Are Not the Same Thing

The terms SSL, TLS, HTTPS, and SSL certificate are often used interchangeably, but they refer to different parts of the system.

An SSL/TLS certificate is a digital certificate associated with a domain.

TLS is the cryptographic protocol used to secure the connection.

HTTPS is HTTP transmitted over a secure TLS connection.

So when you “enable SSL” in Magento, what you are really configuring is Magento to use HTTPS over TLS.

The terminology is still useful because hosting panels, Magento documentation, certificate providers, and administrators commonly use the phrase SSL certificate even though modern deployments use TLS.

If you are researching the underlying technology, OpenSSL is also worth understanding because it is widely used as a toolkit for implementing and testing cryptographic protocols and certificate operations.

What Happens If You Do Not Enable HTTPS Properly?

A partially completed HTTPS migration can cause more than a browser warning.

You may encounter:

• Customer login failures
• Redirect loops
• Broken checkout
• Missing CSS
• Missing JavaScript
• Insecure resource warnings
• Incorrect canonical URLs
• Duplicate HTTP and HTTPS URLs
• Payment integration failures
• Session problems
• Incorrect redirects
• Admin access problems

For an ecommerce business, these failures can directly affect revenue.

A customer who cannot complete checkout because JavaScript is blocked does not care whether the SSL certificate itself is technically valid. From their perspective, the store is broken.

That is why HTTPS migration should be treated as a deployment project with testing rather than a single configuration checkbox.

Magento 2 HTTPS Migration Checklist

Before considering the migration complete, verify the following:

• SSL/TLS certificate is valid for the production domain.
• Intermediate certificates are correctly installed.
• HTTPS works directly before Magento configuration changes.
• Secure Base URL uses HTTPS.
• Secure Base Link URL is configured correctly.
• Use Secure URLs on Storefront is enabled.
• Use Secure URLs in Admin is enabled.
• Static view URLs are secure.
• Media URLs are secure.
• HTTP redirects to HTTPS.
• Reverse proxy protocol detection is correct.
• CDN configuration has been checked.
• Magento cache has been cleared where necessary.
• Static content has been regenerated where required.
• No mixed-content warnings remain.
• Homepage works.
• Product pages work.
• Search works.
• Customer login works.
• Cart works.
• Checkout works.
• Payment gateway works.
• Admin works.
• Third-party integrations work.
• HSTS is enabled only after HTTPS has been fully tested.

Final Thoughts

Enabling an SSL certificate on Magento 2 is not simply a matter of installing a certificate and changing one URL. A properly secured Magento deployment requires coordination between the certificate, web server, Magento base URLs, storefront configuration, Admin, static assets, CDN, reverse proxy, redirects, cache, and application-generated URLs.

The safest sequence is to establish working HTTPS at the infrastructure level first, configure Magento’s secure base URLs, enable secure storefront and Admin URLs, configure HTTP-to-HTTPS redirects, clear the appropriate caches, regenerate static content when necessary, and then test the complete customer journey.

Pay particular attention to the problems that do not appear on the homepage. Checkout scripts, payment integrations, customer sessions, API requests, CDN assets, and older CMS content can continue using HTTP even after the primary Magento URL has been changed.

Magento’s current documentation provides explicit configuration for secure base URLs, secure storefront and Admin access, HSTS, insecure-request upgrades, and reverse-proxy protocol detection.

Most importantly, do not treat the browser’s HTTPS indicator as the final test. A secure Magento store is one where the certificate, TLS connection, Magento application, generated URLs, static resources, customer sessions, checkout process, and supporting infrastructure all operate consistently over HTTPS.

Once that complete chain has been verified, HTTPS becomes part of the store’s architecture rather than simply another setting in the Magento Admin.

Frequently Asked Questions

Does Magento 2 require an SSL certificate?

Magento 2 can technically be configured without HTTPS in certain environments, but a production ecommerce store should use HTTPS. Adobe recommends secure protocol usage for production Commerce pages and provides dedicated secure URL settings for the storefront and Admin.

Where do I enable HTTPS in Magento 2?

Go to Stores → Settings → Configuration → General → Web → Base URLs (Secure). Set the Secure Base URL to your HTTPS address and enable Use Secure URLs on Storefront and Use Secure URLs in Admin.

Why is Magento still showing HTTP URLs after installing SSL?

Installing the certificate does not automatically rewrite every URL generated or stored by Magento. Check secure base URLs, CMS content, extensions, static resources, CDN configuration, caches, and reverse-proxy settings.

Why does Magento redirect endlessly after enabling HTTPS?

A redirect loop commonly occurs when Magento believes the request is HTTP while the reverse proxy or load balancer has already terminated HTTPS. Check the offloader header configuration and make sure Magento receives accurate protocol information. Adobe documents X-Forwarded-Proto as the default offloader header used by most Commerce installations.

Why does my Magento website lose CSS after HTTPS migration?

Check whether CSS and JavaScript resources are being requested over HTTP. If the URLs are correct, investigate generated static files, cache, and static-content deployment. Adobe documents setup:static-content:deploy as the mechanism for deploying static view files in production environments.

Should I enable HSTS immediately?

No. First make sure the entire store, Admin, subdomains, APIs, redirects, certificates, and third-party integrations work reliably over HTTPS. HSTS should reinforce a correctly configured HTTPS deployment rather than compensate for incomplete migration.