After installing SSL on some of the sites on multi-site server, I am facing issue with non-ssl site.
When user accidentally visit non-ssl site with https, browser shows domain mismatch error. When user ignore warning and click on proceed to site, its shows the content of ssl site but URL still shows the non-ssl site's URL.
Also for some of the non-ssl site the google crawl wrong URL which contain path of ssl site.
Let me explain the scenario. I have 1 server which have 5 sites A, B, C, D and E. Out of five 2 (Say C and D ) are secured with SSL.Both the sites are working properly without any issue. Now the problem with non-ssl sites ( Say A, B and E ). Here whenever user visit any of the site with https ( https://www.A.com) browser (chrome) shows error "Your connection is not private" and when I click on "Advanced" button, here browser says "This server could not prove that it is www.A.com; its security certificate is from C.com". and when I click on "Proceed" the next screen show content of C.com but URL is still A.com.
Some one please check and help.
Thanks,
Related
Hello I have a problem with an IIS 8.5 server where I have a 3.8 joomla. the problem is that I have installed the certificate and every time I enter the page only the sign of the certificate appears for a moment and then disappears I have configured the firewall and the URLs have also changed the .htacces and nothing seems to be a clear solution .
And there are times when I get a 403.3 error when I activate the ssl request in the ISS.
firstly, check if the https connection was established by checking the certificate
Chrome:- Press F12; click on security and view certificate; ALso check if the padlock is available.
If the padlock is not visible but https is shown on the address bar, then this seems to be an issue with mixed content. In short http links (images, codes) are served over https .
I am using cloudflare's "flexible ssl" as an intermediary between client and my site.
After setting this up, I went to the browser and tried accessing my site via https:
https://example.com/login
and everything works. I fill in my login info and log in successfully and am not on http://example.com . I manually enter https://example.com/* where * is many other pages and it all works fine.
Now I want to redirect all requests to use the seemingly working https. So i go to my cloudflare account on their website and create a page rule : http://example.com/* to always use https.
Now I go to example.com/login and successfully redirected to https://example.com/login, I fill in my log in information and submit the login form , the page refreshes and I am back to https://example.com/login with an empty login form.
Anyone know what the problem is or how to help troubleshoot?
I am using laravel as a framework for the site and apache as the webserver.
create a page rule : http://example.com/* to always use https
Noted. Be aware that CloudFlare does this by accepting every HTTP request on http://example.com/* and returning a 301 redirect to the equivalent HTTPS request. The browser completes the redirect by sending a GET request to the HTTPS URL.
I fill in my log in information and submit the login form
Check the login form source carefully and check what URL the login form is submitted to. My guess is that the form is submitted to http://example.com/login or something similar. CloudFlare will accept the POST request to http://example.com/login and return a 301 redirect to https://example.com/login -- which your browser will complete as a GET request and hence not sending the login data.
So your best solution is to make sure that your login form POSTs to the correct HTTPS URL not to the HTTP URL.
That's my best guess anyway.
how to help troubleshoot?
Ensure that you are using different log files to distinguish between HTTP and HTTPS requests on your server.
Some other suggestions:
Get a Let's Encrypt SSL certificate and put that on your site so that the communication between CloudFlare and your site is all SSL. https://letsencrypt.org/
Ensure that HSTS is turned on for all of your HTTPS requests so that the browser will know not to send any requests to any HTTP URLs.
Create a development server where you can test all of this working with HTTPS between the browser and the web server without CloudFlare. Once you've got it all working in HTTPS mode without CloudFlare then you can try it with CloudFlare and you should get essentially the same results. Your problem is with the HTTP -> HTTPS switch, not specifically with CloudFlare.
Suppose I visit a web page www.example.com and is successfully loaded into my browser.
When this page is loaded, we can see the certificate information www.example.com by clicking on padlock icon (on left side of address).
The certificate includes the information like owner/organisation, connection status, certificate verified by, cookies set by the page and so on.
Is there any way to get this information programmatically from the browser like by using javascript/Ajax or any other language.
I found this link very helpful:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/How_to_check_the_secruity_state_of_an_XMLHTTPRequest_over_SSL
I have a Drupal 7 site running on an Apache webserver on server A with IP # a.2.3.4. This site A can be accessed and allows login using server A specific DNS.
Recently, this site has been put behind a corporate proxy server B (IP # b.5.6.7) which uses F5 for all proxy redirects. Lets call this site B.
Issue: I can access and login to site A - IP # a.2.3.4 without any issue. However, when I access site B (IP # b.5.6.7), I can access the site but i cannot login. I get ACCESS DENIED error on the login page after I hit SUBMIT.
Observation:
Site A creates session cookies in the browser where as Site B cookies are not created.
Any help?
I've set up an SSL site on server 2012 using CCS and SNI. When attempting to navigate to it over a non-SSL link (http), the site throws a 404 error.
How can I get it to show the "This site requires SSL" message?
You need to add HTTP to your bindings in IIS.
Instead of showing "This site requires SSL" you should redirect your user to the equivalent SSL page (e.g. http://twitter.com/about would redirect to https://twitter.com/about).
It is bad for both end-users and SEO to display a message with a message asking the user to change the URL. If you look at different websites on the Web you can notice that this is automatic and doesn't require any action from the user.