I uploaded my Rails application to Heroku, bought a domain name mysite.com on Site5 and pointed it to my Heroku application URL. I can normally access my site on Heroku when I type www.mysite.com and everything works.
The problem is that before my site opens, I receive a warning that the certificate for this website is invalid and that some other site is pretending to be my site. This looks bad if a customer comes to my site and sees that warning and needs to accept their information "will be at risk". How can I avoid this message?
Here is the screenshot how it looks in Safari:
Heroku provides a wildcard SSL certificate covering all herokuapp.com subdomains. This will only be valid, of course, when accessing your app via its herokuapp.com subdomain.
If you need SSL for your custom domain, you need to acquire your own certificate for that domain and pay Heroku ($20/mo) to use that certificate for your application.
If you don't need SSL, verify your code isn't redirecting HTTP to HTTPS requests. This isn't something Heroku normally does by itself; any forced-secure transit is most likely coming from your application.
See Heroku KB: SSL Endpoint
Related
I am trying to verify the server domain for Apple Pay. I have placed apple-developer-merchantid-domain-association.txt as per the Apple pay instruction and I can access this file with that URL as well.
But when i am going to verify the domain it shows me following Error:
Domain verification failed. Unable to access verification file on server. Confirm that the file is in the correct location, proxies and redirects are not enabled, and the documented Apple Domain Verification IP addresses can access your server.
I don't know what's wrong in configuration.
By the way, This Website is hosted on AWS behind Load balancer.
Wo Got solution of it:
It sounds weird but it worked. Earlier we were using the amazon provided SSL from ACM. And Apple was not able to verify the domain because of SSL related issue. After that we taken new SSL from GoDaddy and setting up on server and it solved our issue.
Seems like Apple was not able to verify domain from the free SSL provided by the AWS.
I have my site and the hosting was on GoDaddy and I changed it to CloudFlare .. Previously, you could access the Via site just writing example.com or www.example.com
But after changed the Hosting, the site does not open and you must enter www
By saying you changed your site from Godaddy hosting to Cloudflare, what do you mean?
Plus, there are a few possible cases in which this could happen.
The SSL Certificate configuration you have active on the site. I do not mean Cloudflare Native certificate (This might not be a reason that would occur always)
Your .htaccess configuration (There should be something that is redirecting your site)
Kindly check these and see if it helps
I've got a site that was originally running on a non-heroku server that I moved to heroku. The site was using a bare domain before (example.com). Heroku requires non-bare domains (www.example.com) as per this article: https://devcenter.heroku.com/articles/apex-domains
My question is: I have a bunch of links out there currently like this: https://example.com which throw a browser error now that I am using non-bare domains.
This excerpt from heroku confirms the error is widespread.
SSL
Traffic routed over SSL behaves, at the DNS level, identical to unencrypted traffic and suffers from the same naked domain limitations.
However, applications requiring SSL encryption should use the ALIAS/ANAME configuration on the root domain. Subdomain redirection will cause a browser error when the root domain is requested over SSL (i.e. https://example.com).
How can I redirect people to the right domain without them experiencing a browser error?
EDIT:
I emailed heroku and this was their response:
I'm afraid only the ALIAS/ANAME style records will be able to reference an SSL endpoint at the apex and from my understanding Namecheap do not support those record types. We have a few examples for various providers here. But if your domain provider doesn't support ALIAS/ANAME we can only recommend you switch to another provider that does. A URL redirector doesn't work for SSL, the CNAME type breaks email, and raw A records can break after only a few minutes.
So I moved providers from Namecheap to Cloudflare, CNAME'd instead of redirected, and everything now works as expected.
If you don't have an SSL endpoint provisioned then your visitors will get a 'certificate mismatch' error as Heroku will serve their default herokuapp.com certificate. You can't redirect https without a valid certificate as browsers first check the validity of the certificate. If you're moving to Heroku and want to respond to those requests you will need a valid certificate, SSL endpoint provisioned and a DNS provider that supports using CNAMEs on Apex records.
I pushed a Spree Rails app to Heroku and I see it's using ssl withhttps:// and has a yellow padlock in the browser. Clicking on this shows "Identity verified" and the Certificate Information says Issued To: *.herokuapp.com
This is great. With no configuration or expense at the Heroku end, my app is using SSL with a valid looking certificate. Ok it's a yellow rather than green padlock but hey, not bad for free.
I'm sure this is a stupid question..but how can I run another Rails app on Heroku with a verified certificate without paying for the SSL add-on and purchasing my own certificate?
The TLS/SSL connection your browser is establishing is due to the fact the you are connecting to your app via appname.herokuapp.com. This is standard and will automatically work for any app you create out of the box. Heroku provides SSL encryption as you may be sending sensitive information to the server and it is better practice to encrypt data that you may not necessarily deem sensitive, but your client may. All reputable providers (SAS, Web Hosts, Email Providers) will have a wildcard SSL certificate installed to the base domain (*.herokuapp.com) as it is a single certificate that is relatively inexpensive and will secure all the sub-domains automatically.
That being said Apps are SSL-enabled already and can be accessed simply by using https, e.g., https://appname.herokuapp.com, but you would want to go with the SSL endpoint option when you want to establish the trusted relationship with your clients. Both ways are as secure as the other, but with the wildcard SSL (also referred to as a shared SSL certificate) the trust is established between the client via their browser and Heroku not your App/Site. With the SSL signed to your domain.com the clients can connect to your domain and not the Heroku sub-domain and see your site's information in the connection information on the browser. If your site is needing disambiguation from Heroku then is when you will want to proceed with an SSL setup outside the default.
As for what SSL type and issuer to use I would not recommend https://www.startssl.com/ as they do not offer SSLs with high browser ubiquity as they are not fully signed by an external root authority. Comodo and the consumer standard Rapid/GeoTrust are the best choices as far as assurance, recognition, and easy of use and concerned. You only need a DV (domain validated) SSL and they can be had for a few domains a month.
More on this and the Heroku SSL configuration can be found here
I recently spent some time setting this up. It can be done using CloudFront and a proxy to Heroku. This is probably best used for small projects but seems to be working great so far! See my post here:
http://ksylvest.com/posts/2014-05-06/setup-free-ish-ssl-tls-on-heroku-for-ruby-on-rails-or-any-other-framework
A few things have changed since this question was first answered, notably the advent of Let's Encrypt and new Heroku SSL endpoints, which together make it possible to add SSL for free. I've created a gem to generate and add certificates automatically: https://github.com/KMarshland/heroku-ssl. Once you've added heroku_ssl to your gemfile, you can simply run:
rake heroku_ssl:update_certs
Alternatively, if you don't want to use the gem, you can do these tasks manually:
1. Generate the SSL Certificate
Follow the instructions in https://github.com/unixcharles/acme-client to generate your certificates. You'll need to register your email, authorize the domain, and then finally get your certificates. When authorizing the domain, if you only have one server running, you can simply stick the authorization file in your public folder; if not, you'll either have to set up a dedicated controller and route or add a text record to your DNS zone file.
2. Add the certificate to Heroku
After downloading your certificates, you can either use Heroku's web interface or just run
heroku certs:update fullchain.pem privkey.pem
3. Configure your DNS
You need to set a CNAME record in your DNS zone file that points to [yourdomain].herokudns.com. The DNS zone file specifies what urls get mapped to what servers on the domain name you own. If your site is already pointed to your Heroku app, there will already be a CNAME record; you just need to change where it points to. If not, you'll need to add a new line:
[subdomain] [TTL] IN CNAME [yourdomain].herokudns.com.
I have an SSL wildcard for my rails site through DNSimple, and have deployed to Heroku.
I have smoothly functioning full-site SSL for all subdomains of my site, except for when I enter my site name without a subdomain into a browser for the first time.
Although my Heroku settings redirects http://mysite.com to https://www.mysite.com, the browser pops up a security warning first, because the SSL certificate for *mysite.com requires a subdomain.
Is there a way to redirect from no subdomain to with subdomain before checking for the security certificate?
This is a substantial issue, as it's unreasonable to require/expect first time visitors to type in www before the site name.
you can use subdomain redirection: https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords#subdomain-redirection
but I think only with the www form, as it warns:
Requests made directly to naked domains via SSL (i.e.
https://mydomain.com) will encounter a warning when using subdomain
redirection. This is expected and can be avoided by only circulating
and publicizing the subdomain format of your secure URL.