during some customer sites transfers from the old server to the new cleavr setup, I witnessed an issue with sites without SSL Certificate.
Basesetup
Created customer website without SSL with Cleavr. (Due to the DNS Settings not yet changed).
Migrated everything (DB, Setup,…)
Moved DNS Settings to the new server.
Now starts the issue
Due to no SSL and all Browsers automatically changing the URI to the https Version, we get a not wished for beahaviour.
The https Version shows an error, because Domain and the allegadly Certificate do not match. Nginx by default choses the first Website for https if none is configured.
With multiple clients on the same server, this is a big violation of customer and data privacy.
Solutions
Cleavr gives a possibility to create a default placeholder Site on each Server and move it up into first position for NGINX. So th
Or Cleavr creates themselvs a placeholder for each server for domains and https version which are not yet setup.
I would be very interested in your opinion on this and i am available to test all solutions with you.
That’s definitely not the behavior we want to happen. It should be hitting the catch-all record and returning a 404. We’ll look closer into and see why that isn’t being respected.
I have one server with mixed https (let’s encrypt and custom ssl) and http sites.
Works without any problems. I remember me there is a problem if you create a website with ssl and you try run the same site without ssl on a later moment.
And I forgot I have so many test locations on all my server without ssl. So it has to be something different @Houbsi
But i still have the issue, when i completely create a new Website and also a new subdomain without SSL in the beginning. So a clean install if you will.
But the problem i’m getting is still there.
Otherwise, all sites are provisioned with cleavr and none where added manually. Just some rewrite rules for cms systems have been altered.
I still can’t figure out how or what is the root of this issue from my end.
Steps i tried:
Created a Website with SSL and removed it.
Created a Website without SSL and tried it.
We have so many sites on our servers and I tried to check all the configurations with the default stuff.
But most of the details of SSL and so forth is on cleavrs specific configurations.
So I hope they still can check this again and maybe tell another point of view for this issue.
We’ve not actually been able to reproduce the issue Mike brought up.
I re-tested the same thing today: created a site without SSL, added a DNS Record, deleted the site and re-created the site with SSL Enabled.
Do you’ve any idea on how the Alias got deleted? Are the sites with SSL issues all related to domain alis? If we can re-produce the issue, we’re always ready and happy to work for a fix/improvements.
Can you also let me know the site and server you’re getting errors via PM?
I deleted the alias from the site settings myself but forgot to remove the A-Record for it. When accessing the alias url, i was redirected to the most currently created site on the same server.
In this case there is no SSL involved i think.
So to reproduce:
create site
add alias
add A-Record for alias
Site is accessible via alias url (cleavr start up screen)
EDIT:
As I can’t leave the customer’s site of api.ams.tax in the state it is right now (not having ssl), i will have to install ssl soon.
Could you please have a look at what is probably causing the redirect and tell me when I can reinstall the ssl certificate for the redirect to disappear?
Would be very much appreciated!
one more hint:
Accessing the site via http://api.ams.tax works as expected but with https it does not.
EDIT 2:
I installed a new SSL certifacate for api.ams.tax now. So you can not test the behaviour with this domain anymore.
I found the problem was that, I believe, Nginx will load the first site alphabetically in the /etc/nginx/sites-enabled directory that has an SSL certificate installed if you have set up a non-SSL site that redirects to a secure URL for that site. For example, we had a site starting with a that had SSL, so it was being used first before the catch-all record.
We were able to fix this by setting up a “default” site and changing its symlink to _default to /etc/nginx/sites-enabled, thereby having it read first, but I would imagine you could do the same by changing the catch-all symlink to _catch-all too.
Can you please let us know how your setup was that led you to the error you faced?
Like: provisioned a server, created sites without ssl, created a site with ssl, now visiting a site without ssl redirected to the site with https version.
I had provisioned a server as a WordPress server. I created a WordPress site on it with a domain starting with akasha and registered an SSL certificate for it. This site worked fine - we were able to access it securely and encountered no issues with it.
Some time later, I created a WordPress site with a domain starting with white, but due to the DNS not pointing to the server at that stage, I couldn’t register an SSL certificate for it. However, this site had been configured to redirect to the HTTPS address for the site, so when accessing it through the non-HTTPS address, it redirected to the HTTPS address, and at this point, we were served the akasha site (after receiving a security notice saying that the secure certificate was not for the domain white... but for akasha...).
My understanding is that, in the absence of a server block in Nginx matching the domain name and port of the request, it defaults to going to the first available server block (as per this article). Because akasha was the first server block within the /etc/nginx/sites-enabled folder, this was the one used as a default.
As mentioned, once we created a site and changed its symlink to _default in /etc/nginx/sites-enabled, this became the first server block and thus it is displayed instead of akasha if a non-SSL site is accessed in HTTPS, so we opted to make this site a “holding” page.
