Skip to Main Content
Customer Feedback

We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.

For technical issues or bugs please head to Support or our Developer Community. You can assign up to 20 votes in total. Thank you for your feedback.

Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.

Status Shipped
Created by Guest
Created on Nov 13, 2020

Support for Let's Encrypt certificates with automatic renewal

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?

  • Guest
    Reply
    |
    Feb 17, 2022

    Great news, that this feature is shipped. Our customer's Infrastructure Team who had the tedious job of ordering 40+ certificates yearly for their multi-site solution is thrilled to have Optimizely take care of it for them.

  • Optimizely
    Elias Lundmark
    Reply
    |
    Feb 17, 2022

    Happy to share that we've deployed a solution for this. We've replaced the previous redirect solution with a serverless solution in the CDN. Through this new service, we'll also provide free SSL certificates courtesy of our CDN provider. All new domains added to DXP Cloud Services will get access to the new service, and our support can move existing apex domains to it on request.

  • Optimizely
    Elias Lundmark
    Reply
    |
    Jan 22, 2021

    Thanks for the additional feedback, David! 217.114.85.70 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.

  • Guest
    Reply
    |
    Jan 15, 2021

    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 217.114.85.70, which seems something owned by Episerver, am I right?

    I think that what is being proposed here is that the server hosted under 217.114.85.70 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,

    Thank you!

  • Optimizely
    Elias Lundmark
    Reply
    |
    Jan 15, 2021

    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.

  • Guest
    Reply
    |
    Dec 4, 2020

    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.

  • Guest
    Reply
    |
    Dec 3, 2020

    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.