setting up an SSL site with multiple bindings in IIS 8.5 - ssl

I am hoping you can help. I have 5 websites that run off the same .net code base and have different themes based on the url.
For example, http://site1.mydomain.co.uk is set up so that it does a http redirect to https://site1.mydomain.co.uk and I have the main SSL IIS entry as mydomain.co.uk with a wildcard SSL certificate and bindings for https://site1.mydomain.co.uk.
The issue I have though is when I put the http redirect on one of the other urls, all of them change to the last one entered. If that makes sense?
So, let's say I have just finished the site1.mydomain.co.uk entry and now move onto site2.mydomain.co.uk. I create the https://site2.mydomain.co.uk binding in the main mydomain.co.uk IIS record and then put a http redirect on http://site2.mydomain.co.uk so that it redirects to https://site2.mydomain.co.uk.
If I then go and check the previous record, site1.mydomain.co.uk the redirect has now changed to https://site2.mydomain.co.uk which is not what I wanted. Why is it doing this and how can I prevent this?

Is there any chance you're using the same folder in the filesystem for all 5 websites?
In IIS, the HTTP Redirect settings are stored in a web.config file in the folder you're serving from, so if you were serving all 5 sites from the same folder then they would all have the same settings, i.e. changing the settings for one of them would change it for all of them.
That being said, I strongly recommend that you use URL Rewrite to do http to https redirects. Doing the redirect in this way is compatible with having 5 sites served from the same folder. You can install it from here (WARNING: the install requires an iisreset, i.e. a brief downtime for your site): http://www.iis.net/downloads/microsoft/url-rewrite
After installing URL Rewrite, you can create a rule to do the redirect. Stack Overflow won't let me post the screenshot here, so I uploaded it to here: http://postimg.org/image/4s4vjajs3/cf4f5c08/
Also, if you're using a wildcard certificate, then doing the redirect in this way might remove your need for having 5 different websites.

Related

How to change the http into https for my domain name?

I recently bought a domain name at OVH for an app I hosted on Heroku. I then paid for the dynos in order to set an automatic SSL certificate.
Everything seems to me working fine:
Domain Status Last Updated
─────────── ─────────── ────────────
mpjrigot.eu Cert issued 2 minutes
mpjrigot.fr Cert issued 2 minutes
But my URL is still in HTTP. What am I missing?
EDIT
I'm using React.js for this app
I also have a Ruby on Rails back but for nom i'm keeping that on the heroku.app, works fine
2nd EDIT
Using react-https-redirect, force-https or react-ssl-redirect...
Basically, chrome tells me that "this is not a safe space", and that this is a fake https that might want to steal the user's passwords and stuff
So I got an SSL that is set on my HerokuApp,
I got a domain on OVH that points to the IP of the app
But the http isn't secure somehow
I really think I missed something obvious as I'm new to this...
You can add HTTPS to your app with the following methods.
Method1 (Recommended)
Since, you're using rails for the backend, you can configure your rails app to always use HTTPS.
in your production.rb add
config.force_ssl = true
More Info: https://help.heroku.com/J2R1S4T8/can-heroku-force-an-application-to-use-ssl-tls
ActionDispatch SSL: https://api.rubyonrails.org/v6.1.4/classes/ActionDispatch/SSL.html
Method2 (Easy Setup)
You can also signup for cloudflare's free plan and easily setup https redirects with cloudflare's 'Always Use HTTPS' or 'Automatic HTTPS Rewrites' feature.
The 'Always Use HTTPS' feature will redirect all http requests on your site to https address.
The 'Automatic HTTP Rewrites' feature will change the HTTP links on your site to HTTPS links.
More Info here:
Always use HTTPS: https://blog.cloudflare.com/how-to-make-your-site-https-only
Automatic HTTPS: https://www.cloudflare.com/website-optimization/automatic-https-rewrite/
Cloudflare's SSL: https://www.cloudflare.com/ssl/
cloudflare dashboard
What am I missing?
Heroku provides a certificate, so you should be able to access your application using https://. However it does not redirect HTTP requests to HTTPS for you:
Redirects need to be performed at the application level as the Heroku router does not provide this functionality. You should code the redirect logic into your application.
Exactly how you do that depends on the language and libraries or framework that you are using. Several common examples are listed in the link I provided above.
If you edit your question to tell us what technology you have used to build your application I'll be happy to add those details to this answer. In case you are using Scala, please see How to disable HTTP requests on Heroku and/or auto-redirect to HTTPS?
solution
I eventually read about Heroku needing a specific host that takes in the address they tell you to point to when setting a domain name...
So I switched to Gandi for my domain name and set the ALIAS to point to said adress
Works like a charm

Unable to log in to admin area after installing SSL certificate on Drupal

We have recently installed an SSL certificate to our fairly old version of Drupal. The front end of it works well, however, we are now unable to log in to the admin area. We put this problem on our servers who claims the website now goes into a continuous redirect look, causing the site to crash. here is what they said.
"I have taken a further look at this and we can see some pages have specific rules in place that are forcing them to use HTTP this is then causing an issue with the redirect to HTTPS, this is essentially creating a loop as the Site goes to the HTTP which gets redirected to HTTPS, which the page then redirects back to HTTP and so on. You will need to review the content of the site and to remove the redirect(s) to HTTP for any pages that have this, alternatively, we can remove the redirect to HTTPS (However this defeats the purpose of having the SSL Certificate then). Please let me know if you would like me to remove the HTTPS redirect."
The same problem can be found here at stack overflow. However, the answer is very vague considering it's a change to the .htaccess file.
Any thoughts?
put this line at the en of settings.php
$conf['https'] = TRUE;

Prevent http page from redirecting to https page

I have a website (userbob.com) that normally serves all pages as https. However, I am trying to have one subdirectory (userbob.com/tools/) always serve content as http. Currently, it seems like Chrome's HSTS feature (which I don't understand how it works) is forcing my site's pages to load over https. I can go to chrome://net-internals/#hsts and delete my domain from Chrome's HSTS set, and the next query will work as I want without redirecting to an https version. However, if I try to load the page a second time, it ends up redirecting again. The only way I can get it to work is if I go to chrome://net-internals/#hsts and delete my domain from Chrome's HSTS set after each request. How do I let browsers know that I want all my pages from userbob.com/tools/ to load as http? My site uses an apache/tomcat web server.
(Just FYI, the reason I want the pages in the tools directory to serve pages over http instead of https is because some of them are meant to iframe http pages. If I try to iframe an http page from an https page I end up getting mixed-content errors.)
HTTP Strict Transport Security (or HSTS) is a setting your site can send to browsers which says "I only want to use HTTPS on my site - if someone tries to go to a HTTP link, automatically upgrade them to HTTPS before you send the request". It basically won't allow you to send any HTTP traffic, either accidentally or intentionally.
This is a security feature. HTTP traffic can be intercepted, read, altered and redirected to other domains. HTTPS-only websites should redirect HTTP traffic to HTTPS, but there are various security issues/attacks if any requests are still initially sent over HTTP so HSTS prevents this.
The way HSTS works is that your website sends a HTTP Header Strict-Transport-Security with a value of, for example, max-age=31536000; includeSubDomains on your HTTPS requests. The browser caches this and activates HSTS for 31536000 seconds (1 year), in this example. You can see this HTTP Header in your browsers web developer tools or by using a site like https://securityheaders.io . By using the chrome://net-internals/#hsts site you are able to clear that cache and allow HTTP traffic again. However as soon as you visit the site over HTTPS it will send the Header again and the browser will revert back to HTTPS-only.
So to permanently remove this setting you need to stop sending that Strict-Transport-Security Header. Find this in your Apache/Tomcat server and turn it off. Or better yet change it to max-age=0; includeSubDomains for a while first (which tells the browser to clear the cache after 0 seconds and so turns it off without having to visit chrome://net-internals/#hsts, as long as you visit the site over HTTPS to pick up this Header, and then remove the Header completely later.
Once you turn off HSTS you can revert back to having some pages on HTTPS and some on HTTP with standard redirects.
However it would be remiss of me to not warn you against going back to HTTP. HTTPS is the new standard and there is a general push to encourage all sites to move to HTTPS and penalise those that do not. Read his post for more information:
https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/
While you are correct that you cannot frame HTTP content on a HTTPS page, you should consider if there is another way to address this problem. A single HTTP page on your site can cause security problems like leaking cookies (if they are not set up correctly). Plus frames are horrible and shouldn't be used anymore :-)
You can use rewrite rules to redirect https requests to http inside of subdirectory. Create an .htaccess file inside tools directory and add the following content:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Make sure that apache mod_rewrite is enabled.
Basically any HTTP 301 response from an HTTPS request indicating a target redirect to HTTP should never be honored at all by any browser, those servers doing that are clearly violating basic security, or are severaly compromized.
However a 301 reply to an HTTPS request can still redirect to another HTTPS target (including on another domain, provided that other CORS requirements are met).
If you navigate an HTTPS link (or a javascript event handler) and the browser starts loading that HTTPS target which replies with 301 redirect to HTTP, the behavior of the browser should be like if it was a 500 server error, or a connection failure (DNS name not resolved, server not responding timeout).
Such server-side redirect are clearly invalid. And website admins should never do that ! If they want to close a service and inform HTTPS users that the service is hosted elsewhere and no longer secure, they MUST return a valid HTTPS response page with NO redirect at all, and this should really be a 4xx error page (most probably 404 PAGE NOT FOUND) and they should not redirect to another HTTPS service (e.g. a third-party hosted search engine or parking page) which does not respect CORS requirements, or sends false media-types (it is acceptable to not honor the requested language and display that page in another language).
Browsers that implement HSTS are perfectly correct and going to the right direction. But I really think that CORS specifications are a mess, just tweaked to still allow advertizing network to host and control themselves the ads they broadcast to other websites.
I strongly think that serious websites that still want to display ads (or any tracker for audience measurement) for valid reasons can host these ads/trackers themselves, on their own domain and in the same protocol: servers can still get themselves the ads content they want to broadcast by downloading/refreshing these ads themselves and maintaining their own local cache. They can track their audience themselves by collecting the data they need and want and filtering it on their own server if they want this data to be analysed by a third party: websites will have to seriously implement thelselves the privacy requirements.
I hate now those too many websites that, when visited, are being tracked by dozens of third parties, including very intrusive ones like Facebook and most advertizing networks, plus many very weak third party services that have very poor quality/security and send very bad content they never control (including fake ads, fake news, promoting illegal activities, illegal businesses, invalid age rating...).
Let's return to the origin of the web: one site, one domain, one third party. This does not mean that they cannot link to other third party sites, but these must done only with an explicit user action (tapping or clicking), and visitors MUST be able to kn ow wherre this will go to, or which content will be displayed.
This is even possible for inserting videos (e.g. Youtube) in news articles: the news website can host themselves a cache of static images for the frame and icons for the "play" button: when users click that icon, it will start activating the third party video, and in that case the thirf party will interact directly with that user and can collect other data. But the unactivated contents will be tracked only by the origin website, under their own published policy.
In my local development environment I use apache server. What worked for me was :
Open you config file in sites-availabe/yoursite.conf. then add the following line inside your virtualhost:
Header always set Strict-Transport-Security "max-age=0". Restart your server.

Pointing GoDaddy DNS to GitHub page uses http over https

I have my DNS settings as shown in the image
DNS Setting along with an additional CNAME with host www and value as my GitHub page. Next I setup a CNAME entry in my GitHub page with an apex entry to my domain. The issue I face is that whenever I visit my domain with an https protocol, it shows a warning that the connection is not secure. I get the following in Chrome:
NET::ERR_CERT_COMMON_NAME_INVALID
How do I fix this? I have both https and http access for my domain.
UPDATE: Github introduced custom domain support for HTTPS on May 1, 2018.
If you are using GoDaddy and want to upgrade to HTTPS, do the following:
Go to DNS settings for your site in your GoDaddy account.
Remove all existing A records.
Open a terminal and do dig +noall +answer <YOUR-USERNAME>.github.io. You should see a table listing 4 slightly different IP addresses:
On GoDaddy, create 4 new A records, each one pointing to one of the IPs. For host use # and set the TTL to a low user-defined value (if you are in a hurry).
Go to your page repository settings on Github, and clear the custom domain name and save. Wait a while (minutes).
When executing dig +noall +answer <YOUR-CUSTOM-DOMAIN> yields the 4 IP addresses that you entered in the A records, go back to the Github repository settings and re-enter and save your custom domain name (which you just cleared) in the custom domain cell.
Optionally, check the box Enforce HTTPS. But make sure that https://<YOUR-DOMAIN>is responsive first.
Make sure you have a CNAME record in your DNS settings also. Host should be www and it should point to your <YOUR-USERNAME>.github.io.
Make sure there is a file in your website repository named CNAME containing the name of your custom domain (in my case ulfaslak.com).
Reference
EDIT: Please see answer below by Arturo Herrero: https://stackoverflow.com/a/50203412/462015
GitHub pages does not support HTTPS for custom domains.
The only work around for doing so is to use an SSL provider as the middle man, such as Cloudflare. However, this would involve pointing your DNS name servers at Cloudflare's, which takes some time and complicates things.
If you want HTTPS support using GitHub pages you'll have to use GitHub's provided URL instead of your custom domain.
Another great option for static sites if you want custom domain name HTTPS is Amazon Web Services. You could set up an S3 bucket for your static website, configure CloudFront to distribute the static content, point your domain name at the CloudFront distribution, and use a free SSL certificate from Amazon's cert manager. This option comes out to less than $1/Month with a low-traffic website. A great in depth tutorial for that would be here.
I hope this answered your question! GitHub pages is a great hosting option, and it's not the end of the world if you decide to forget about HTTPS.
Custom domains on GitHub Pages gain support for HTTPS since May 01, 2018
https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

htaccess redirect to shared SSL

Apologies if this is a duplicate, but I couldn't find a question fitting my exact circumstances.
I am redesigning a site, part of which will require SSL coverage. I have set up SSL with our hosting provider, but this is shared SSL. Whereas our current site is at www.companyname.com, the secure server is at companyname.genericssl-host.com.
I believe the best way to proceed is to simply shift all the web files onto the secure server, whether they need to be secure or not, then redirect www.companyname.com to there. However, the provider informs me that if I do that, the URL in the browser address bar will still read companyname.genericssl-host.com once the redirect completes, and that I would need to edit the htaccess file to make it read good ol' www.companyname.com again.
What does the htaccess file need to contain in order to do this?
Not sure what your hosting provider is referring to, but changing it back to "www.companyname.com" defeats the purpose of using SSL at all. What shows up in the browser's address bar is:
what host the browser is going to send a request to
what URI it will request
the query string if there is any
If you change it back to www.companyname.com, it's going to send a non-SSL request to that host, which defeats the purpose of redirecting it to SSL in the first place.
You need to buy a certificate for *.companyname.com and install if on a host specific to your server.