I am trying to setup ssl for my site that is hosted on netlify.
The site lives as www.qrpu.sh. It appears that setting up a custom domain always sets up a record for the Apex domain. I however don’t want the apex domain to point to netlify.
I have a service on heroku that is handling traffic to qrpu.sh and will redirect to the www subdomain as appropriate.
Is it possible to create a custom domain for only www and to set up SSL with lets encrypt on this domain
Hi there,
It is possible for you to self-serve on not having us serve both www and the bare domain:- set the primary domain as something other than www or the bare domain (such as “foo.qrpu.sh”) and then you can add www.qrpu.sh as a domain alias with no automatic redirect or hosting of the bare domain. You can change the primary domain from the “…” menu next to any entry in that list you screenshotted. You would need to point foo.qrpu.sh to netlify even if you don’t use it, to allow us to provision ssl
This is a pretty rare use case - most folks who browse don’t really pay attention to the possibility of difference between the bare domain and www so you might consider the usability of this setup for your visitors. We provide a reverse proxying feature to send selected traffic to remote services like heroku that would be a more typical and potentially cleaner solution: https://docs.netlify.com/routing/redirects/rewrites-proxies/#proxy-to-another-service
I looked into the proxying, but can’t see how to differentiate based on the host or authority of the request. Documentation only describes path based. Also it looks like proxying doesn’t work for streamed responses. The backend service uses server sent events to push messages to the client.
Ah, yeah, you can’t redirect based on things like authority or HTTP request type (but you can redirect based on hostname: see https://docs.netlify.com/routing/redirects/redirect-options/#domain-level-redirects for details). People who use that functionality “segregate” their proxy’d content on the remote service under a path that has no other content under it, so you could do something like this:
https://qrpu.sh/api/* https://remoteservice/:splat 200!
And yes, our CDN (proxying included) only handle HTTP requests, not websockets or anything else. We do handle streaming HTTP, but not for unlimited time - we couldn’t host e.g. youtube videos longer than a minute or so via proxying. I also understand that you may not want to rearchitect your backend to allow that pathing I describe, so hopefully the workaround I mentioned will work (add www as a domain alias, and have a custom domain set to a placeholder).
If that didn’t work, let me know. I will see if I can help you get it configured well, but if not, I can calso reate a special config to allow the SSL certificate to use www and not the bare domain, but it is rather inflexible, as you cannot later add additional names to the site without our help. Let me know if you’d like that (and if you want to keep the foo domain alias if so, since we’ll need to allow for that during this configuration).