2

Preconditions

  1. Ubuntu 18.04 DigitalOcean droplet
  2. Nginx 1.1.4
  3. MariaDB 10.1.34 (MySQL 15.1)
  4. PHP 7.1 (Using FPM)
  5. Redis server 4.0.11

Steps to reproduce

  1. Download Magento 2.2.5 via Composer
  2. Install Magento 2.2.5 via CLI using existing database
  3. Install SSL certificate. (At this point the website is functioning properly).
  4. Enable https on magento frontend and admin.
  5. Execute setup:upgrade,setup:di:compile,indexer:reindex,cache:flush and setup:static-content:deploy in that order.

Expected result

  1. Frontend is displayed without any security warnings.
  2. Admin is displayed without any security warnings.

Actual result

  1. Frontend is displayed without any security warnings.
  2. Admin is stuck in 301/302 redirect loop
  3. I can see in the headers that the SSL certificate is recognised as valid.

Notes

I have this problem running 2.2.5 with nginx and redis, no varnish, all on a single digitalocean droplet.

I have read that it can be to do with cookie configuration and set cookie_path to "/" and cookie_domain to both ".example.com" and "example.com", neither of which have produced successful results. I have made changes to the default nginx config provided by magento as suggested above but that wasn't successful either. The nginx config file for my website is as follows:

upstream fastcgi_backend {
         server  unix:/run/php/php7.1-fpm.sock;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        index  index.php index.html index.htm;
        server_name  example.com www.example.com;

        set $MAGE_ROOT /[web_root]/magento;
        set $MAGE_MODE production;

        access_log [path_to_access].log;
        error_log [path_to_error].log;

        include /[web_root]/magento/nginx.conf.sample;

        return 301 https://$server_name$request_uri;
}

server {
        listen 443 ssl;
        index  index.php index.html index.htm;
        server_name example.com www.example.com

        ssl_certificate /path/to/ssl.crt;
        ssl_certificate_key /path/to/ssl.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers [ssl_cipher];
        ssl_session_cache    shared:SSL:10m;
        ssl_session_timeout 24h;
        keepalive_timeout 300s;

        set $MAGE_ROOT /[web_root]/magento;
        set $MAGE_MODE production;

        access_log /path/to/access.log;
        error_log /path/to/error.log;

        include /[web_root]/magento/nginx.conf.sample;
}

Edit

I raised this as an issue on github and was advised that I should set the unsecure base url to https, then remove the 301 redirect from my nginx config. I've done this, restarted the server and re-deployed magento to ensure everything is completely fresh. Deleted browser cache and disabled caching in code inspector prior to visiting website and admin page still returns a redirect loop.

Edit #2

I looked at app/etc/env.php and noticed that, alongside the usual base, media, static etc. entries that are found within the system>web>... entry in env.php, there was another entry at the bottom of the file with just the base urls, both set to http.

Although they are duplicate entries, I didn't want to delete them because I'm not sure why magento has created them (I've never manually edited the env.php file for this instance). Instead, I just updated every value which began "http://" with "https://...".

Now I can access the admin panel, but the configuration options for secure URLs in Stores>Configuration>General>Web>Url Options are greyed out and the frontpage no longer redirects to https, though there is no mention of http anywhere in the config file.

I guess that it is greyed out because I'm running in production mode, but I want to make as few changes as possible to the system because it's so close to functioning.

2
  • 1
    If any configuration is added to env.php - it's not available for editing from the admin. You can remove it from env.php and add it to core_config_data (if you don't have). Commented Aug 14, 2018 at 4:20
  • Thanks I assumed that was the case. Just seeing incorrect values in the greyed out boxes made me panic a little :P.
    – Muckee
    Commented Aug 14, 2018 at 14:28

2 Answers 2

4

Try the following query:

SELECT * FROM `core_config_data` WHERE path = 'web/secure/use_in_adminhtml' ;

if path

web/secure/use_in_adminhtml

has value of

null

Update the value to 1 using the following query

UPDATE `core_config_data` SET `value`=1 WHERE path = 'web/secure/use_in_adminhtml';

Hard refresh the page and it will work

3
  • If you read through the discussion on the linked github issue, you will see that this did not work in my case.
    – Muckee
    Commented May 11, 2019 at 20:12
  • 3
    I had to run this from the command line - magento config:set web/secure/use_in_adminhtml 1 Commented Dec 6, 2019 at 2:16
  • 1
    For me, it was cd <root> then php bin/magento config:set web/secure/use_in_adminhtml 1, but definitely no need to deal with MySQL commands. Thank you guys!
    – DaWe
    Commented Jun 15, 2021 at 13:05
2

Solution #1: Resolve incorrect database entries

Ensure that all values are properly set within the core_config_data database table.

Search for unsecure_base_url and ensure that the value of the table entry includes the https:// prefix.

In my case, there was a duplicate entry for the base URL in my env.php file, so I had to manually alter both entries.

I did not remove the 301 redirect, as suggested.

After modifying the database, the pages loaded properly, but the http version would not redirect to https.

Solution #2: Use https in admin pages

Added this solution for anyone who wishes to answer the question, "How to resolve the redirect loop so that all pages redirect to https?", found in doublesharp and dawe's comments on this question.

Whilst logged into a terminal, connected to the host system as the Magento filesystem user, execute the following CLI commands:

bash cd /path/to/magento/root/directory

bin/magento config:set web/secure/use_in_adminhtml 1

or

php bin/magento config:set web/secure/use_in_adminhtml 1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.