Describe the challenge you're encountering and your desired outcome. Be as detailed as possible.
For technical issues please head to Support or our Developer Community.
You can assign up to 10 votes in total. Thank you for your feedback!
Let's encrypt is becoming the industry standard for certificates. It's free, secure and more and more customers are using it.
I know this isn't supported out of the box in Azure, but shouldn't a hosting service like DXP support this?
Thanks for the additional feedback, David! 220.127.116.11 is indeed our current redirect service that handles apex to subdomain redirects. Which in its current state doesn't support Let's Encrypt but it is something that we want to fix.
The solution will take some time but we'll keep this idea updated on our progress.
I understand there is a limitation regarding the way everything is setup with Cloudflare, but it doesn't change that usually, when configuring a domain for a new client under DXP, we are being asked to add an A record pointing to 18.104.22.168, which seems something owned by Episerver, am I right?
I think that what is being proposed here is that the server hosted under 22.214.171.124 should have a mechanism to automatically request TLS certificates from Let's Encrypt based on a known list of domains which points on it. Afterwards, it is a easy as making HTTP ACME challenges to the server.
Hope it helps,
Hi Sigve, thanks for clarifying (and apologies for the delay)! The issue here isn't really certificate related - the certificate issued by Cloudflare actually includes the apex domain. The issue is rather because we use what Cloudflare refers to as a "CNAME setup" https://support.cloudflare.com/hc/en-us/articles/360020348832-Understanding-a-CNAME-Setup. This allows us to use the customers domain in Cloudflare without having authorative DNS in the Cloudflare zone.
The limitation of this is that we can only point to Cloudflare using CNAMEs - and by RFC-2181 https://tools.ietf.org/html/rfc2181, an apex domain cannot be a CNAME - it must be an A or AAAA record. Hence we rely on our own redirect service to handle an apex domain to subdomain redirect - and we unfortunately cannot use Lets Encrypt in our redirect service as the underlying operating system is not a first-class citizen of certbot.
We do hope to solve this in the future. But in the meanwhile, you can actually solve the redirect anyway you'd like as you're not forced to use our redirect service. I.e. you can point www.domain.com to DXP and our Cloudflare setup, and then redirect domain.com to www.domain.com any way you'd like.
If my understanding is correct the free certificate provided does not support "naked-domains". Ex: https://www.domain.com will work, but https://domain.com results in a certificate error. This is a big issue for one of our customers that we are moving to DXP at the moment. All the links "out in the wild" (google results etc) points to the naked-domain of this customer. As of now the solution is to provide our own certificate to handle the naked-domain.
I would like to use a certificate from Let's encrypt for this, or better yet, change cloudflare's certificates with Lets encrypt certificates so it becomes the default provided one thus supporting naked-domains from the start. And because Lets encrypt certificates expires every 3 months automatic renewal is needed.
Hi Sigve, thanks for the very interesting feedback. Can you elaborate on what you mean with "supported" and for what use case you need this? There are free certificates provided already via the CDN we've embedded in DXP.