custom domain webhosting / https:// with Back4App; Proper HowTo?

[tal...@gmail.com]

Hi all, wanted to get advice from Back4App and the community about two issues I really need help with to fully complete migration of our (kloseby.me) webapp/site from Parse.

1) Custom domain webhosting DNS configuration: Back4App says to create CNAME records for BOTH your domain and subdomains (kloseby.me and www.kloseby.me) to point to the Back4App one (kloseby.back4app.io). But with domains (kloseby.me) you HAVE to create an A record, not a CNAME one (as far as I know you cannot create an A record for a main/apex domain), and that A record HAS to point to an IP address, not another domain/subdomain (please see: https://www.name.com/support/articles/205516858-Understanding-DNS-record-types and GoDaddy documentation: https://au.godaddy.com/help/add-an-a-record-19238).

We have tried to workaround this using GoDaddy's URL forwarding service, but with 'masking' enabled the 'iframe'-based redirect conflicts with Back4App's 'clipjacking' http:// request response security header. Using 'masking' of the url kloseby.back4app.io so the world sees kloseby.me instead results in the iframe not being displayed, so the response is just a blank page. If we turn off 'masking' the world sees us as 'kloseby.back4app.io' instead of kloseby.me or www.kloseby.me which is not the best of solutions.

Setting up a CNAME record to our www. subdomain is fine/easy (except for https:// requests, which is outlined in 2 below); but we really, really need proper Back4App IP addresses to utilize for an A record to our domain kloseby.me. With the correct IP addresses we will be able to turn off URL forwarding/redirect, set up both an A and CNAME record and get the responsive performance we are expecting (Back4App please help, this was easily done in Parse when they offered custom webhosting, all the necessary DNS configurations were provided).

2) Likewise there is an issue with anyone trying to connect to our domain (kloseby.me and www.kloseby.me) using https:// . In order to do so the Back4App server our webapp resides on MUST have our SSL certificate resident. So, we need to upload it to Back4App, just like we did for installing on Parse. Since you are running nodeJS servers, there is lots of documentation on installing a SSL certificate, once you have one (ours) in hand: https://www.namecheap.com/support/knowledgebase/article.aspx/9705//installing-a-ssl-certificate-on-nodejs . Since you already are running a nodeJS https:// service I would imagine it is a case of pointing to our domain's certificate and not the Back4App one.

Apologies for the length message, and thanks in advance for everyone's help!

Steve

[Alexis L.]

Hello Steve,

Have you found a working solution? I'm looking to route web request to my domain, and just like you, an A Record is mandatory.

Have a nice day,

-A

[casag...@back4app.com]

Hello,

Thanks for letting us see your point of view. However it's not possible to apply your workaround since the Node is not the last layer for the connection. The correct place for that would be in the Load Balancer. The problem is, the Load Balancer is shared: you don't have a specific one for you, making it impossible to save your SSL certificate. 

That can be done though, if you subscribe to a Dedicated Plan, since it has separated Load Balancers for each user and your workaround could be implemented.

If you have any more questions please contact us here, on the online chat or even emailing us on comm...@back4app.com.

Best! 

[Alexis L.]

I'm surprised multi-tenancy isn't possible on your load-balancers? It's standard stuff these days (even nginx does that out of the box)

I don't deny the certificate must be installed on that layer, just saying that one (or more) load balancer per website isn't economically viable at all. You should have a serious talk with your IT guy ;)

[casag...@back4app.com]

Hello Alexis,

I think you got me wrong. Let me explain to you:

We use AWS ELB for our configurations. That way the current AWS configuration is to have 1 certificate per ELB. Our Shared Hosting plans use the same ELB, so the same certificate will be used by every user within it. 

When the user subscribe to the Dedicated Plan, he uses a new ELB and an exclusive CNAME just for him.

The possible workaround (If you're not able to use the Dedicated Instance yet) you may use a reverse proxy. The provider (CloudFlare, for example) will get you a free plan to use your CNAME.

Anyway we're working hard so all our subscribed users (Paying users) have it soon.

Best! 

[Alexis L.]

SNI support is a known problem for AWS ELB, albeit Amazon has circulated for years 'we're looking at it'. So, again, I'm not saying there's other ways if you stick with AWS only, what I'm saying is that the cost of management of thousands of ELBs, belonging to thousands of different customers, doesn't make much sense to me (money wise). Even with 5 minutes sanity-check per ELB, how long would that take...

But I'm not b4a, so what would I know.

Cheers.