How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Let me give you a bit of context about where I'm coming from. I've been an Endpoint Consultant for the last decade and an MVP for the last year. For almost four years now, I've been working with customers to modernize their clients and transition them to a cloud-native state. While I welcome the security aspect of this change, I would like to comment on a couple of things regarding this topic. 
As the article states: "TLS certificates aren’t a one-time import — certificates expire, CA chains change, and your operational process needs to keep up." This is very true, yet it's not reflected in the product, or rather, this upcoming change. Don't get me wrong; I love the MCC. I've been implementing it for customers regularly since the standalone MCC came out of its five-year private preview. Before that, I used the ARR version. 
The fact is, "We are actively working to streamline certificate monitoring and renewal inside Microsoft Connected Cache" should have been the default mode before changing anything or setting a date. I understand that there's no money to be made by offering MCC as a service. For now, I would hold off on enforcing HTTPS. This is especially true at a point where security can mostly be assumed to come from an internal network secured by different mechanisms (from the MCC to the client). None of the other MCC-capable services have announced such a requirement, at least as far as I know. This creates unnecessary administrative overhead without providing significant security benefits. Here are a couple of points to consider:

• Delivery Optimization already performs hash validation. Nothing in the swarm protocol has changed, so even in the case of a man-in-the-middle attack, the hash of several blocks would have to be manipulated, which is unlikely. By the time the client begins downloading the content, the MCC has already received it through an encrypted connection.
• The MCC integrated in ConfigMgr is much easier to set up, and it's now easier to configure with HTTPS as well. IIS can probably just use the operating system's built-in functionality to request and maintain a valid certificate.
• You are one of the biggest contributors to open source. I think implementing ACME or something similar would not be too difficult. ACME works on Windows, so you could have used the same method for the ARR in IIS for ConfigMgr.
• Why isn't there an integration for CloudPKI? It's the one thing that could generate revenue.
• I understand that wildcards are not good practice, but asking customers to generate tens or hundreds of CSRs and track all those certificates is too much.

In short, please make sure that "Bring Your Own Certificate" at least works so that I don't have to tell my customers that their new, modern environment suddenly creates more work for them just for doing the right thing. Security, especially for admins who work with Windows 90% of the time, must be as easy as possible on Linux, or you will lose customer support. For many of my customers, MCC is a requirement, meaning that if they don't have it, they can't transition to the cloud for their endpoints. They need a reliable replacement for distribution points.