You have support for https only on domain without www

how did you do that. I've only ever been able to get cf working on www

this is my situation:
http://www.example.com ->point to cloudflare
http://example.com ->redirect to http://www.example.com
https://www.example.com ->doesn't work
https://example.com ->work because it doesn't use cloudflare but the certificate installed on my domain.
I don't use cloudflare dns service (full service), but I use partial dns:
https://support.cloudflare.com/hc/en-us/articles/203685674-Full-DNS-setup-versus-Partial-CNAME-setup
I think this is applicable on full service,too (if you don't use the certificate provided by cloudflare)

I had to stop using cloudflare because they only really support www and
using their ssl certificate

Yes, but you can use the domain without www for secure connections. I think for example to:
Pre-login:
http://www.example.com/login
Post request to
https://example.com/login and https://example.com

I've seen an e-commerce system using for example https only for cart, login and payment and it switch between the two domains based on http or https request

A login page on http posting to https is insecure. You should not do this - period.

Hello PhilETaylor, this is what I mean:
http://doc.prestashop.com/display/PS16/Setting+a+shop's+URL

@bettinz Doesn't mean its right. Doesn't mean its best practice. Doesn't mean its secure!

Do you research (start in google) and you will see hosting a login page on http and posting to https is highly frowned upon by those of us that know better.

"Critical Mistake 1: Non-HTTPS Login pages (even if submitting to a HTTPS page)."
https://blogs.msdn.microsoft.com/ie/2005/04/20/tls-and-ssl-in-the-real-world/

"Your login form posts to HTTPS, but you blew it when you loaded it over HTTP"
https://www.troyhunt.com/your-login-form-posts-to-https-but-you/

There is simply no reason to run ANY of your site on http - its 2016 - you should implement https everywhere... there is no reason not to, and a million reasons to.

A few things:

1) Technically www.example.com is a subdomain of example.com so it is correct that applications treat this as requests for two different domains; this is generally why most well configured sites enforce www. prefixes or remove them through .htaccess rules.

2) As Phil pointed out, this isn't secure by any measure. When there is any endpoint in the chain that does not enforce HTTPS connections, it compromises the entire operation's security.

3) It's a bad idea in general to only use HTTPS on some pages of your site and HTTP on others. The entire site should be one way or the other (preferably HTTPS, especially if you're collecting customer data in any form).

Some ideas:
If www.site.tld is the website, and https://site.tld/login is the login page, the form is already in an https page. I don't understand why you're talking about mix http/https.
I also don't understand why it's different from the actual option to enable https only for administrator: when I write http://www.site.tld/administrator there is automatically a redirect to https://www.site.tld/administrator.

This issue wasn't about activate ssl for some website parts (it was a last minute idea in my first message). The issue was about to use https for a domain, and http for another. I don't understand why https://secure.domain.tld and http://www.domain.tld is so strange. Many sites have a subdomain with https for customer area and login things (register, password reminder, etc).
It's a waste of resources to use https for all site: if I've a blog and I login on frontpage, why do I need https for index page and articles page?
It's perfectly accepted to use http://www.domain.tld for the website and https://domain.tld for login page. Again, the login form is already on login page, so it's not http->to ->https. We're login inside https page.

It's a waste of resources to use https for all site

/facepalm - stop living in the 1990s!

Some bedtime reading for you.

• https://www.maxcdn.com/blog/ssl-performance-myth/
• https://www.keycdn.com/blog/https-performance-overhead/
• https://moz.com/blog/enabling-https-without-sacrificing-web-performance
• https://istlsfastyet.com/
• https://googlewebmastercentral.blogspot.co.uk/2014/08/https-as-ranking-signal.html
• http://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https

one more to read
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

@andrepereiradasilva that was the one I was trying to find before when trying to explain that passwords over http wrong :) thanks - I'll bookmark it now.

This clearly states Google Chromes expection for the future:

another one https://istlsfastyet.com/

thats already in my list above:)

Thank you guys, I have something to read ?

I am closing this