I recently changed the domain for a Rails app I have running on Heroku. I redirected the original to the new one, and for the last couple of months have been running SSL on both. I tried to remove SSL from the original domain since all it does is redirect.
I did everything I thought I should:
Turned off SSL in the app with config.force_ssl = false in production.rb
Changed DNS ALIAS and CNAME to point to "myapp.herokuapp.com"
Removed the SSL endpoint and certs
If I go to myapp.herokuapp.com, everything is fine, but if I go to myapp.com, or www.myapp.com it automatically tries to take me to the secure version of the site, https://myapp.com, and I get the standard security error warning from my browser.
Am I missing something? Is it a caching issue? Does it just take time for the DNS change to kick in? I've tried on a few machines/browsers, and the issue is consistent across all of them.
Worst case, I can definitely add the SSL Endpoint back on, but it seems like overkill.
config.force_ssl = true enables Strict Transport Security header(HSTS) with max-age of one year. See this issue. Such header forces browsers that support it to contact the server over HTTPS for one year. This is to prevent attacks in which man in a middle downgrades HTTPS connection to HTTP.
Moving out of HTTPS for production sites that were served with HSTS is not very easy. You should keep your site served over HTTPS and return HSTS header with max-age=0 to reset the one year setting. The problem is to decide for how long you need to keep HTTPS. To be absolutely sure that all clients are switched, you should do it for one year. You may decide to do it for a shorter period, but at the risk of breaking the site for clients that are visiting infrequently.
In addition to what Jan said, here is what I did to do the trick.
In application_controller.rb :
before_filter :expire_hsts
[...]
private
def expire_hsts
response.headers["Strict-Transport-Security"] = 'max-age=0'
end
In production.rb
config.force_ssl = false
Clear the cache of your web browser and that's it !
Related
I'm trying to set up https on my backend app on heroku as a subdomain like this (for example):
https://api.mydomain.com
and I'm really confused by all the conflicting online docs I've found. Also, I'm rather green on all this SSL stuff. This app will be a backend for just data serving. My front end right now is https on OpenShift under my domain and it's working fine. Here is what I've done:
I have a "hobby" dyno ($7/month) on my heroku app, which I read that I need to
enable this stuff.
I have a cloudflare account which serves up my domain for the openshift front-end on https.
I bought my domain from GoDaddy -- so right now it simply points to the cloudflare name servers.
I setup the subdomain: api.mydomain.com on heroku (settings tab). It came back and said that my "DNS Target" is api.mydomain.com.herokudns.com. It also says "Domain: Your app can be found at http://api.mydomain.com".
I clicked "Configure SSL" > "Automatically configure using Automated Certificate Management" and it comes back saying to:
"update your DNS settings to our secure domain"
Not really sure what that means, to be honest. I tried to go back to cloudflare and add a DNS Record (DNS tab). Like so:
Type: CNAME
Name: api <--is this right?
Value: api.mydomain.com.herokudns.com <-- what do I put here?
But this doesn't work. How do I know? I type
heroku certs:auto and it comes back 'failing'. Also tried value: mydomain.com.herokudns.com without the 'api' in front. I'm really confused and the docs aren't much help. Can anybody help me?
I have found a simpler solution. The fix was mentionned in Cloudflare's tutorial.
The trick is to take your standard heroku app address (ex: myapp.herokuapp.com) INSTEAD of the xxx.herokudns.com displayed in heroku's SSL interface
Then, to make your custom subdomain (ex: api.foodomain.com) point to it, simply add a CNAME record in Cloudflare's DNS
CNAME api myapp.herokuapp.com
And it should work (it did for my case).
OK, in case some other poor tired programmer comes here.
Cloudflare and Heroku don't get along. Use your SSL from cloudflare. Here's how:
disable automatic certification on heroku: heroku
certs:auto:disable
Delete your domain on heroku and start over
Add the (sub) domain again on heroku
type heroku domains to see what the REAL domain is now -- without ACM enabled it will probably go back to ...herokuapp.com instead of ...herokudns.com
Set that one up in cloudflare (DNS tab) under CNAME like so:
CNAME | yoursubdomainname | yourdomainname.com.herokuapp.com
set up Page Rules in cloudflare to be like so:
http://yourdomainname.com/ => Always use https
on Crypto tab use Full SSL.
Wait an hour or so to make sure these all take effect.
Hope that helps someone.
I am trying to set custom domain for my Firebase app.
Firebase hosted url : https://inventory-app-726af.firebaseapp.com/
Custom Domain: inv.agsft.com
I have followed all instructions as part of setting custom domain but after verification step when I click on finish button, status will always be "Needs Setup".
I am managing DNS through cloudflare (https://www.cloudflare.com/) and I am following Quick setup option.
Any pointers to resolve it?
I had the same problem, I was able to resolve it by toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records
It started working right away.
The proper solution, ie without disabling Cloudflare for the site, is to use Full SSL for your domain/subdomain.
You can either choose Full SSL for all your domain entries, or set up a Page Rule for a specific subdomain, in your case, use "inv.agsft.com/*"
Source: https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3, which in turn points to https://support.cloudflare.com/hc/en-us/articles/115000219871-Why-does-Flexible-SSL-cause-a-redirect-loop-
Had the same issue and this solved the redirect issue. Firebase will however still report the domain as "Needs setup", for that I have no solution, but it does not affect the functionality of the hosting.
For the people that is using Namecheap, This configuration worked for me.
To avoid any kind of ssl issues when using firebase hosting and cloudflare you have to check to following points:
You don't need to toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records unless you don't want the cloudflare ssl certificates and want to just use the firebase ssl certificates (look to this carefully because you will loose the protection that cloudflare provides to your site in case you decide to use only the clouflare DNS)
If you "keep the cloud orange" it will not causes any problem to your firebase hosting.
Add the firebase IP's to cloudflare following the instructions provided by firebase hosting and remove any other A record from your domain/subdomain that you are setting up
To ensure you have a end-to-end encryption (using both firebase ssl as well as cloudflare ssl), make sure that your cloudflare crypto options is set to "Full":
Use a page rule likes in case that you want your root domain to receive all trafic:
In your firebase hosting setup, do the same:
p.s: Look that the message "Needs setup" is still there but the app is running without any problem.
p.s2: the majority problems regarding cloudflare and firebase is that firebase ssl can take several hours to start to work and you keep seeing a message like "your connection is not private". It happens not beucase cloudflare is messing our proxy out but because firebase ssl is still not fully propagated.
I hope it help others :)
In my case I did the same that Brennen did:
toggling the DNS Status on cloudflare from DNS and HTTP Proxy (CDN) to just DNS on the two A records.
But just start working when I:
Delete the domain from firebase. (click on the : points select delete domain)
refresh the firebase site
Added again in Quick Setup. I already had the A record added in Cloudflare so I didn't added again.
After that automatically the status added was connected.
Remember: Before testing, clean your browser cache.
When I run dig -t txt +noall +answer inv.agsft.com there are no TXT records showing. Since those are required to verify your ownership of the domain, Firebase Hosting will not continue the setup beyond step one.
Update: since the next step requires you to map A records to the IP addresses of Firebase hosting, I ran the relevant dig too:
$ dig -t a +noall +answer inv.agsft.com
inv.agsft.com. 299 IN A 104.18.56.240
inv.agsft.com. 299 IN A 104.18.57.240
Those are not the addresses I'd expect for Firebase Hosting, so it looks like either you haven't correctly entered the A records, or they have't propagated yet.
When I change my setting like below, it started to work again.
Redirect loop fixed:
For GoDaddy this adding the following solved it for me:
TYPE:A
NAME:#
VALUE: your ip_1
TYPE:A
NAME:#
VALUE: your ip_2
June 2020
Just wanted to share what was successful for me. It was a combination Brennen and Lisbel's answer.
Step 1: Toggle off your DNS status to get a grey cloud (as shown in the earlier answer)
Step 2: Delete the domain from firebase
Step 3: Add it back with Quick Steup
It should be connected after these steps!
I had the same issue. Here's how I fixed it:
1) Cick the View button on the problematic domain (in the Hosting section next to where it says Needs Setup).
2) Change the 'Setup mode' from Quick Setup to Advanced and follow the 3 steps
2a) Open your domain provider's settings (I'm using Google Domains) and add the TXT record it's giving you.
2b) Wait about 4-12 hours for verification
2c) Add the provided A records into your domain provider's settings
This is not a quick process, but it should be working about 5 minutes after you complete step 2c.
Toggling DNS mode didn't work for me. So I tried following approach and it worked for me.
Add CNAME record pointing to {firebase-project}.firebaseapp.com or {firebase-project}.web.app, you could add A record and try.
ADD TXT record as firebase ask you
Verify from firebase (this will show as needs setup, also it didn't go away although this worked)
If new domain/subdomain doesn't works check your browser developer tools network tab. If there are lots of 301 happening then go to cloudflare page rules. Add newdomain.com/* or subdomain.newdomain.com/* then add settings select SSL and set it to full as follows.
Then it will work as expected.
Working as of 11st May 2022 without need to toggle DNS and HTTP Proxy (CDN).
Steps:
Go to Cloudflare Dashboard.
Select SSL/TLS.
Select Overview.
Select Full option for SSL/TLS encryption mode.
After that, refresh your website that previously have issue to access.
Now the website can access successfully.
I'm trying to use Liferay for http and https
if I include in portal-ext.properties:
company.security.auth.requires.https=true
web.server.protocol=https
Will be working ok with https but in http is showing incorrect themes due is trying to load https://domain.com/theme
If I remove this two lines is working ok for http but not for https.
What can I do?
IMHO mixed mode, e.g. offering http as well as https never gives you what you expect: You expect security from https, but you always risk leaking session information, e.g. being vulnerable to session-hijacking attacks (ala Firesheep). My actual advice would be to go https only if you do https for security. Read on if that's not an option for you, but don't complain when you find information leaking (this is not dependent on Liferay, but for any web-based environment)
What is the exact problem that you have with the themes? (images/css through http?) Which version of Liferay are you using?
Before you specify more, you might want to configure your theme's "virtual path", this will rewrite all the URLs referring to your theme. It's typically used to serve static resources through a webserver or cdn, but it works with any kind of URL. Simply using a protocol-relative URL should work (I love this mostly unknown http feature):
Add this to your theme's liferay-look-and-feel.xml:
<look-and-feel>
<theme id="my" name="My Theme">
<virtual-path>//domain.com/myTheme</virtual-path>
</theme>
</look-and-feel>
note that the URL omits the protocol part, http: or https:, thus the browser will use the same protocol that the whole page is loaded with.
Edit: corrected the xml. Will investigate if there's a problem with protocol-relative URLs in themes.
Edit 2: Something is weird. It seems, virtual-path does not work like this, but I recall it did earlier. Do you add domain.com as cdn.host.http or cdn.host.https? (this would be concatenated)
On related stuff, please check if you're running Apache in front of your appserver. In this case you might forward some traffic for the portal (e.g. in the virtual host for http) but not forward the traffic in the https virtual host.
I have purchased an ssl certificate, I have enabled the SSL setting in the settings and I have changed both config files to go to https but when I visit http://bit.ly/TCkEBv the first page is https the rest are not. How can I fix this?
I realize this is an old thread but considering the recent google SSL-everywhere indexing changes, i figured it was relevant. The following example will make OC use https in all links. You have to change 3 characters in system/library/url.php. They deleted this on the forums which is understandable, but we have ran it for a week of production traffic on mixed SSL multistores with no issues.
WARNING: Your mods may be different - run through them all in a test after enabling this...especially any redirect managers. Here is the tweak for 1.5.6:
Open store/system/library/url.php and find $url = $this->url; in an IF statement somewhere near line 18. Change it to $url = $this->ssl; and there ya go.
PS: Also there is a vastly untested method to send the https-preferred as a header using $response->addHeader('Strict-Transport-Security: max-age=31536000'); but i am unsure of best spot to put it besides index.php. Also, although it works in test, unsure of all-server implications. Header controller seems logical, but not all OC areas use header controller :). Experiment with best placement for that....just dont do it in the $url replicator even if it seems like it works.
As per the forum thread, this is not actually a bug just the way that the cart is set up - that is most pages are not set as HTTPS and will revert to HTTP once you click on a non HTTPS link
Let's say you have a Domain called example.org
Instead of changing the code, in Apache, you could do this...
In addition to your Domain-SSL.conf, you can copy that configuration to Domain.conf and edit it to use port 80 instead of 443
Then, add this line in the Server definitions at the top, right before DirectoryIndex...
Redirect / https://example.org
This will simply redirect every request back to the SSL configuration, adding the https:// in front of every link. No code changes required to OC.
This has been working on my busy production server for several years without a single problem.
My wildcard certificate expires in three weeks and I've just renew it and installed the new certificate, so that my IIS has two now.
I have currently more than 30 sites running and I would like to update them one by one to use the updated certificate. Though I dont see a parameter for appcmd set site which allows me to specify which certificate to use. I really would hate to have to delete the old certificate and re-add all sites asap which means my sites would be without SSL for a few minutes.
Seems like there were no other possibilities, I decided to go ahead and update them manually as quickly as possible. When entering the "Bindings" popup for the first website, it warned me (as usual with https bindings) that multiple sites were detected. I ignored the warning and set the new certificate for the first website. That also updated the https bindings on all the other sites apparently. I have checked with various online SSL checkers and the sites all seems to be updated now. Phew.