Would cert-manager for Kubernetes be approximately what you’re looking for? In that particular case, it’s a service that runs in a K8s cluster, that can auto-request CSRs and send them to Lets Encrypt using one of the challenge types. It takes care of managing the returned certificates, such as renewing them before expiration and registering the private keys within the K8s key store.

I presume that you’re not already using K8s, so maybe that project will help you find the keywords to describe the sort of certificate manager that you want.

I’m not currently using kubernetes but its something I’ve thought of looking into before. I’ll definitely give that a look for better terminology though!

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

eff-certbot.readthedocs.io/en/stable/using.html#d…

Example tutorial: digitalocean.com/…/how-to-create-let-s-encrypt-wi…

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: docs.ansible.com/projects/ansible/…/index.html

I’m looking for a way to both get a sub wildcard (I don’t know the exact wording but *.sub.domain.com would be an example) and push it into cloudflare. So a direct certbot install with manual distribution, while technically possible, sounds absolutely abysmal. I’d rather forget the entire idea than deal with that.

Why not handle certs on your end and just use CF for proxy? I use NPM for cert automation with CF proxying. It’s honestly ridiculous easy and I’ve had no issues.

Cloudflare doesn’t pass the cert you have through, it generates its own cert (or uses one you provide).

Depends on your config, I’m just doing DNS (proxied). So you hit my nginx and that’s where the cert is provided.

Have you actually confirmed that is the case? My understanding is that cloudflare pretty much always re-signs with their own SSL cert. and I’m fairly certain that would be absolutely required when using their DNS proxies.

I have confirmed it - it’s how I run all my services

Yes, it’s also how I run all my services. I checked just this moment, and locally my certs verified by field is Let’s Encrypt, while remotely that field is Google Trust Services

I have never personally provisioned a cert from Google. I have only ever utilized Let’s Encrypt. That leaves just one involved party that could have requested, received and presented this cert: Cloudflare.

I would recommend reconsidering how you obtain LE certs. I ended up on Certbot too because it lets you own what is a critical part of your selfhosted identity. Plus Certbot works well and it’s maintained by the EFF who also see it as a critical project. As a local script (basically) sky’s the limit regarding automation.

This is personal preference but I strongly prefer to locally control critical automations about my setup (certs, DDNS etc.)

The certs produced by Certbot are portable and you can use them with CF, local reverse proxies, or whatever other infrastructure you may need. Just need to get a copy to the proper place (securely).

I guess in the bigger scheme of things the question is whether you’re ok being tied to a particular service (like CF). I don’t, and I also don’t want to depend on the LE implementation of any particular reverse proxy (or their plugins).

PS: Oh and another tip: if you do end up using a CLI tool for certs, stick to Certbot. I’ve tried pretty much everything else and they all suck. It’s actually unbelievable how much they suck. Arcane and opaque, the lot of them, which is not something you want from a critical tool.

Certimate It is a free and open source self-hosting tool designed to automate the complete management cycle of SSL certificates, including issuance, deployment, renewal and monitoring, using a visual interface.

Oh this looks very promising, thank you!!

Tools mentioned here are good suggestions but the problem you are going to run into is that CloudFlare doesn’t support second or higher level dns zones (so a record of a.b.c.com should be in a zone of b.c.com and CF only allows c.com) on most account tiers and LE/certbot is expecting a zone to create the validation record using its plugin.

Oh… boy, that’s an angle I hadn’t considered.

Doesnt any dns challenge currently just look at domain.com to see if it can create the lower cert?

Some of the acme clients do, I don’t think certbot does though. I remember using acme.sh or something and I think it calls it a delegation domain if I remember correctly!