I'm running smallstep CA in my homelab. While it's nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh.
Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid certificate, e.g. router/firewall/appliance web interfaces. Out of the box, the limit for traditionally issued certificates using the CLI is very low, too.
The default prevents expired certificates to be renewed. If your homelab does not offer a couple of nines behind the comma, you'll pretty much have to intervene on a regular basis UNLESS you adjust the defaults. You can't set the max duration to years, months or days but only hours:
As for the "hours" max interval, this is the result of a design decision in Go's time duration library, dealing with the quirks of our calendaring system.
It's because units up to hours are of a fixed size, but days in most places are only 24h for ~363/365 days of the year, with some being 23h and some being 25h.
(This is ignoring leap seconds, since the trend is to smear those rather than surface them to userspace.)
For what it's worth, I've had quite a bit of success using ACME for devices that don't natively support it by using a sidecar service.
Basically, running the ACME flow on a Linux system and then having it programmatically update the cert/key for the service that needs it. Have done this for my NAS, printer, router, etc.
This is what I do as well. I use acme.sh on one linux server to generate a cert with a few SANs on it, then copy that cert to things like opnsense/truenas/etc either using ssh or their api if there is one.
Downside is that you have to provide root/admin access to copy the key material and also to restart the services. A big no-no for me, even in my homelab.
Yes the default certificate duration is so small as to be useless as a default. It's a pain to set the expiration in hours, but it does still allow you to set months or years of duration. You just have to calculate out how many hours those months or years are.
Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid certificate, e.g. router/firewall/appliance web interfaces. Out of the box, the limit for traditionally issued certificates using the CLI is very low, too.
The default prevents expired certificates to be renewed. If your homelab does not offer a couple of nines behind the comma, you'll pretty much have to intervene on a regular basis UNLESS you adjust the defaults. You can't set the max duration to years, months or days but only hours:
If the goal of hour homelab is to design/test/experiment with a fault-tolerant high availability k8s infra, e.g. for your job, it's great.CAVE: macOS enforces duration limits even for trusted enterprise CAs, e.g. Safari won't accept your 1000 days certificate anymore.