Hot answers tagged

9

This worked for me on the Arcustech server: Put this code in the root .htaccess file: <IfModule mod_rewrite.c> RewriteEngine On # Send would-be 404 requests to Craft RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC] RewriteRule (.+) index.php?p=$1 [QSA,L]...


7

Yii will check for the following server environment variables when determining if it’s an SSL request: HTTPS – should be set to “on”, “ON”, or “1”; or HTTP_X_FORWARDED_PROTO – should be set to “https” or “HTTPS” Apparently this is a common issue when running PHP on Nginx, since that HTTPS env variable is only an Apache convention. Here’s an article that ...


5

Update: As of the next Craft 2.6 release (post 2.6.2945), Craft has exposed an attributes database config setting that you can pass arbitrary PDO attribute key => value pairs into. So, assuming your MySQL box is setup properly to use SSL and assuming the database user that Craft is using to connect to the box can connect over SSL, then you can do ...


4

This seems missing from the other answers, so I feel the need to emphasize it here... Craft does not require .dev for local development. Your local URL can be anything you want, Craft does not care. There is no requirement whatsoever on using a .dev domain. That being said, it is recommended that you use a "dev-sounding" URL, in order to avoid the ...


3

Checkout Nitro 2, it now has full SSL support https://craftcms.com/docs/nitro/2.x/commands.html#trust


3

The easiest way to renew the certificates is nitro restart (specifically on the nitro-proxy container) which is detailed here. Nitro uses Caddy Server as a reverse proxy that runs in its own container and handles generating and terminating local certificates and forwards to the site container to the sites port. Also the creator of Caddy chimed in on the ...


3

While self-update worked for you, that command is used for updating nitro itself. This may have the side-effect of updating your container, but if nitro is already up-to-date it may not do anything. However, the documentation lists multiple commands that are used to update your containers and environment: nitro update updates containers to their latest ...


3

The fix was to delete the content of the /cpresources folder and that did the trick.


3

So, removing the cache settings for CSS and JS in my nginx config fixed this. # CSS and Javascript location ~* \.(?:css|js)$ { expires 1M; access_log off; } Also, once I got into the admin area after adjusting this, resaving certain entries flushed the twig template cache.


3

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version Your local OpenSSL setup is trying to connect with an older, insecure TLS 1.0 protocol, which Github (and a lot of other sites) no longer support. If you update it to use TLS 1.2, the error will go away. If you're on something like MAMP/WAMP, etc. then updating to the latest ...


3

The second one will force SSL no matter which page you're on, including any control panel requests, which is what you're after. As mentioned in the docs, make sure that goes above Craft's default rewrite code. The only other thing you'll want to do is change the site URL in Craft itself; you can do that in Settings -> General so Craft knows to spit out ...


3

Yea Google bought .dev a few years back and now chrome forces https on all .dev domains. I switched to using .test which has been reserved. So far, so good. https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd


2

ok - just figured it out after reading Brandon's answer here Asset URLs not HTTPS The missing piece was to set the url setting of the asset source to root relate e.g. /uploads/images Clear the cache and all sorted!


2

An addition on this, probably for later versions of Craft than @brandonkelly's answer. You also need to be careful where Asset definitions are made in the CP - specifically, under Settings>Assets>Volumes>yourAssetsName. the default or practice at some point was to have urls of the form: @web/your/resource/path however, as of Craft 3.1, a red-lettered ...


2

So... just to be clear. This /style.css is a static asset, it's not sitting in the craft/templates folder, right? Assuming that's the case, something is definitely wrong if https is taking 2 seconds to load it. Sounds like something with your server is misconfigured. How are you measuring this, exactly?


2

This is how our default .htaccess with https redirect and forced www. for all our projects looks like. So if you have the url example.com you'll get redirected to https://www.example.com. <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !^/(...


2

tl;dr: In my case, adding AllowOverride All back in to httpd.conf fixed the issue. I was having the same issue on my staging server. I noticed that, in addition to /admin throwing a 404, all of my site's subpages were 404-ing. This cause me to try the unrouted index.php url for a subpage (mysite.com/index.php?p=subpage) and it worked! Note, this wasn't ...


2

You could try something like '@assetBaseUrl' => $_SERVER['HTTPS'] ? 'https://site1.domain.org/files' : 'http://site1.domain.org/files' which checks for a secure request.


1

Someone may have a better answer but what just worked for me was: nitro self-update Followed by a Docker reboot. See the docs on updating.


1

Update to the latest SEOmatic; the issue you're describing is a case where SEOmatic operates the same as Craft CMS does in terms of returning a root URL without a trailing slash, but we added a fix to SEOmatic 3.3.18 anyway.


1

SSL isn't currently available in Nitro–though it is on the roadmap for development. See github.com/craftcms/nitro/issues/10.


1

For better practice, you should never use ".htaccess" file. Especially your problem can be easily solved by modify Apache configure file. You should be able to find an Apache configure file somewhere in your /etc folder. On my server its /etc/httpd/conf/httpd.conf. Then just find the code <VirtualHost *:80> ... your server setting ServerName ...


1

After much head scratching it wasn't an SSL issue. Litespeed had recently been installed on the shared server but was misconfigured. It appears the allowed header size default value was modified during the installation of LiteSpeed which caused the issue. We've now restored the default value and the functionality of the website appears to have come ...


1

move these lines RewriteEngine On # Send would-be 404 requests to Craft RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !^/(favicon\.ico|apple-touch-icon.*\.png)$ [NC] RewriteRule (.+) index.php?p=$1 [QSA,L] to the end of the file


1

Most likely the PHP curl version that's on your box is trying to connect to the endpoint using an older SSL protocol (TLS 1.0, 1.1, etc.) and the endpoint requires something higher (TLS 1.2, 1.3, etc.). http://blog.techstacks.com/2010/03/3-common-causes-of-unknown-ssl-protocol-errors-with-curl.html The command line version of curl is probably using a newer ...


1

If you are using Laravel Valet, the newest version takes care of that. You may either change the domain with valet domain test, or better: automatically secure your project it with valet secure. It's very smooth.


1

I'd give Patrol plugin a try, just activate secure connections.


1

It turned out not to be Craft's fault, indeed: On the server, the HTTP_X_FORWARDED_PROTO environment variable was erroneously set to https in the reverse proxy – an issue that my hosting provider had to resolve. (As a quick fix, the following line in index.php did the trick, too:) apache_setenv('HTTP_X_FORWARDED_PROTO', 'http'); Thanks to @brad-bell ...


Only top voted, non community-wiki answers of a minimum length are eligible