0

I find SSL real confusing, but anyways.

For my frontend static website, I host on S3 and distribute using CF. I just use something simple like comodo SSL to generate an SSL cert and then go through the AWS ACM process to import the cert. All good.

But I realized all my API requests of course go to a Node.js server running somewhere else in the world on Heroku (ok, probably they host on AWS somewhere :P). So with my domain name being www.domain.com and SSL certified, pointing to d12345.cloudfront.net, and API requests hitting myapp.heroku.com, do I get a separate SSL on Heroku? Heroku has a tempting auto SSL feature for paid dynos, but I don't get if I need it or if I use my existing one for www.domain.com.

2 Answers 2

2

A server certificate is used to authenticate the target of the current request. This means that when accessing www.example.com the client expects to get a certificate valid for www.example.com. When accessing example.cloudfront.net the client expects to get a certificate valid for example.cloudfront.net.

The context of the request does not matter, i.e. if the request for example.cloudfront.net was caused by an XHR from the site served by www.example.com. All what matters is the target of the current request (example.cloudfront.net).

One could have a certificate which is valid for several targets at the same time (i.e. includes both www.example.com and example.cloudfront.net). But this requires that one actually owns and manages all these domains. In case of example.cloudfront.net or example.heroku.com this is not the case since these are owned and managed by third parties.

2
  • Hm. I still don't really understand. AWS S3 has this whole thing about "static sites require cloudfront for HTTPS", even though my s3 bucket was accessible via https.. Fine, I created a cloudfront dist. Cloudfront then provides ACM to create a free SSL, even though cloudfront is accessed via https already.. But I guess that's for the domain. Now Heroku also has SSL for paid dynos, yet free hobby dynos are only accessed via HTTPS anyways... I just feel lost. Commented Jan 31, 2021 at 1:41
  • @allthewayaround: It usually depends on the domain one want to use. If one is ok with the generic domain used by the vendor (i.e. vendor brand) then one can use it. If one wants to have something more clearly associated with a brand one also needs a new certificate for this - since the certificate must match the accessed domain as I explained. Commented Jan 31, 2021 at 6:57
1

It all depends on how you want your architecture to look like.

If you want both your UI and API to be hosted on the same domain (e.g. www.domain.com), then you can use one cloudfront distribution as your CDN, and you wouldn't need any additional certificates. Your API endpoints might look something like this www.domain.com/api/v1/endpoints. Cloudfront will act as a reverse-proxy to your API hosted on Heroku. You will configure DNS so that www.domain.com points to the cloudfront distribution.

On the other hand, if you wish your API to have a separate domain, (e.g. api.domain.com), then you'll need a separate certificate for it. In this case your API endpoints might look something like this api.domain.com/v1/endpoint. Here you'll need to configure DNS entry for api.domain.com to point to your Heroku app, and you'll need to have a certificate for api.domain.com present on the app.

Another option is to get a wildcard certificate for your domain and use it across both services, but using the default certificate manager in AWS (which includes auto-renewal) seems more practical.

Finally there's no reason why you couldn't just use the default heroku endpoint, and let heroku take care of certificate renewal/generation for you. But you'll then have to start worrying about things like CORS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .