Let's Encrypt implements a protocol, or, if you prefer, an API called ACME, which is being standardized at IETF. This allows you to make software-based requests for certificates. You can implement an ACME client or adapt an existing one to make requests for certificates on behalf of your customers.
There are a lot of clients, several dozen of them already. There isn't necessarily a client that's specifically oriented toward provider integration, but one of the lightweight clients like acme.sh might be a good fit because it will work well with external scripting.
I think caddy supports automagically combining multiple domains on LetsEncrypt certificate requests. It is possible to set it up as a proxy just to get certificates but be aware of rate limit issues, especially if a domain expires or otherwise becomes invalid.
I was trying to use it temporarily as the simplest way to get a multi-domain LetsEncrypt cert on Windows, but ran out of time attempting to convert the resulting certificate format into something I could take back to IIS.
I recently came across fly.io (possibly on HN) which looks like it may help here, at least in the interim while you're a small startup. To note they do it for you similar to how Cloudflare would do it - you route your site through them - so it may not be what you're looking for.
The way I was going to do it personally was have customers point to a domain I control which then CNAMEs to the DNS record fly.io provides me. Not that I don't trust them or anything, but because I don't trust anyone completely :P In serious it was more to avoid any brand confusion.
At least that way I could in the worst case scenario cobble something together that replaces it in the event of a sunset or the likes
For NGINX and Apache it's a shell script away. The dehyrated shell client is Let's Encrypt/ACME compatible. It can read from a domains.txt file listing individual certificates per line. There's a hook.sh that you can modify to get dehydrated to deploy the script.
All you'd have to do is get whatever script you currently use to provision the custom domains, to add the domains.txt and run dehyrated --cron.
valME.io, the blogging site I developed, has been doing this for years [1]. A user can provide their own SSL cert if they want but typically I just set them up via Let's Encrypt and then it does its automatic renewal process. If you're on a VPS, it's straight-forward to setup one of many ACME client alternatives [2]. If you're on shared hosting, it will depend on the hosting provider (some might even have it integrated if they use an administrative tool like Virtualmin).
How are they managing the content not specifically served over https? Do the scrap and download it, rewrite urls at their storage and re-serve back over https?
Most browsers will give a mixed-content warning, but still serve images.
Edit: found a reference[0] on the tumblr help site:
>Keep in mind that enabling the option for a theme that wasn’t developed to support SSL may cause “mixed content” errors. If your blog looks weird after you turn SSL on, some resources that the theme needs to render itself may not be getting loaded.
>If you're a theme developer and you'd like to ensure your themes support SSL, make sure that any externally hosted resources such as Cascading Style Sheets (CSS) or Javascript files are served either using HTTPS or a protocol-relative URL. If these files aren’t available over HTTPS, consider uploading them at the Theme Customization page (In your blog settings, click “Edit HTML” and then “Theme assets”).
Does Tumblr actually allow the embedding of arbitrary images? I've never knowingly seen a Tumblr blog embed external ones; they always seem to be Tumblr-hosted.
I have a platform where my customers can use their own domain. But I am not sure of an easy (automated) way of doing this using LetsEncrypt.
There was a post awhile back that explained how Etsy does it (https://codeascraft.com/2017/01/31/how-etsy-manages-https-an...)
But it was wwaayy too much for a small startup like me.
I can think of a manual way of course.