Standalone Step CA: unable to extend cert expiry period from default 24 hours

[rhubear25]

On Step server, /home/step/config/ca.json, the "authority" section --

"authority": {
	"enableAdmin": true,
	"provisioners": [
		{
			"type": "JWK",
			"name": "admin",
			"kid": "cnWeR0i2FVPCp7RArFDD7vdqwpPaKVWEgQgtorol3j0",
			"claims": {
				"maxTLSCertDuration": "8760h" 
			}
		}
	]
},

There is a step command --

"step ca provisioner update admin --ca-config= "
( --ca-config= defaults to $(step path) )

Its not clear whether this command in intended INSIDE the Step container, or on the client.

My ca.json file contains the "maxTLSCertDuration" I want. However the Step database contains other parameters....

"step ca provisioner list" displays completely different "JWK / admin" info.

Is the Step server I'm running on a Homelab, limited, or can I achieve this update on the Step server?

[MLuc24]

Your ca.json edit isn't being ignored by accident — with enableAdmin: true, step-ca stops reading provisioners from that file entirely. From authority/authority.go:

// ReloadAdminResources reloads admins and provisioners from the DB.
func (a *Authority) ReloadAdminResources(ctx context.Context) error {
	...
	if a.config.AuthorityConfig.EnableAdmin {
		provs, err := a.adminDB.GetProvisioners(ctx)
		...
	} else {
		provList = a.config.AuthorityConfig.Provisioners
		adminList = a.config.AuthorityConfig.Admins
	}

So the provisioners block in ca.json is the source of truth only when enableAdmin is false. You have it true, which is why the database holds different values and why step ca provisioner list shows something other than what you edited — that listing is the real configuration, and your maxTLSCertDuration: 8760h is sitting in a section nothing reads.

That also answers the container-versus-client question. step ca provisioner update has two modes, and --ca-config is the offline one that rewrites ca.json directly — which in your setup edits the ignored file again. What you want is the remote form, which talks to the CA's Admin API and writes to the database:

step ca provisioner update admin --x509-max-dur=8760h

Run it from wherever you can reach the CA and authenticate as an admin. Inside the container is fine, but only because the CA is reachable from there — it isn't a local file operation, so nothing about it requires being on the server.

For a homelab with one provisioner, the other option is simpler and worth considering: set enableAdmin: false and restart. ca.json becomes authoritative again, your existing claims block takes effect as written, and you manage the CA by editing that file. You lose remote admin management, which on a single-operator setup you probably weren't using anyway.

Either route works; what doesn't is mixing them, which is the state you're in now.

[rhubear25]

enableAdmin: false
Could you be more specific, exact full syntax & where to put this directive?

Are you talking about the Docker env directive "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=false" (true below)

environment:
      # CA Identity
      - DOCKER_STEPCA_INIT_NAME=SmallstepCA
      - DOCKER_STEPCA_INIT_DNS_NAMES=localhost,192.168.1.4
      - DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true

I'm finding Step commands prohibitively complicated. Even others are this forum are completely confused with step syntax.

I usually try to get suggestions from my Brave AI, which works well for easy stuff like python. But with niche products like Step, AI feedback is just guessing.

I have learned most of what you were saying above. I knew that ca.json was not being read, so that's why I was attempting the remote management.

PS: the command I'm trying to use for generating my TLS leaf certs is below. Is this not considered a Remote Admin command (with the "step ca"). Or does this command merely work with the Bootstrapping info to connect to the CA server?

step ca certificate 192.168.1.4 truenas.crt truenas.key --provisioner admin --san 192.168.1.4 --san truenas.local --not-after 8760h

[MLuc24]

Not that env var, no — it won't do anything for you now. All the DOCKER_STEPCA_INIT_* variables only run on a first-time setup: the entrypoint checks whether a ca.json already exists and skips initialisation entirely if it does, printing "there is no ca.json config file; please run step ca init" only in the empty case. Since your CA is already initialised, flipping DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT to false just sets a variable nothing reads. It's the switch that decided enableAdmin: true back when you first created the CA, not a switch you can keep using.

So it's the file, and you're already looking at the right place — it's the same "authority" block you pasted, where "enableAdmin": true sits right above "provisioners". Change that one word to false, restart the container, and step-ca goes back to reading the provisioner list (and your claims) out of ca.json, which means the maxTLSCertDuration you already wrote takes effect as-is. No step commands involved at all. Keep a copy of the file first, as with anything in that directory.

On your PS — step ca certificate isn't an admin command, so none of this affects it. Admin commands are the ones that manage the CA's own configuration (step ca provisioner add/update/remove, step ca admin ...), and those are what the Admin API and enableAdmin govern. Asking for a leaf cert goes through the ordinary CA endpoint using a provisioner, which is exactly what your --provisioner admin is selecting, and it works off the bootstrap info — CA URL plus root fingerprint — the same way whether remote management is on or off. That command will keep working untouched.

Worth saying though that it's also the command that will show you whether the change took: --not-after 8760h is a request, and the CA clamps it to the provisioner's max duration, so right now you're asking for a year and silently getting 24 hours back. Once the claim is actually in effect the same command should hand you a cert with the expiry you asked for, and if it doesn't, that tells you ca.json still isn't the thing being read.

And for what it's worth, your instinct to reach for remote management was reasonable — it's just that with one provisioner on a homelab CA it buys you a whole API to learn in exchange for something a text editor already did.

[rhubear25]

Thanks Man,

.... For teaching me more about Step & getting me up and running.... I've now generated a new 1 year cert.

Wow, that took a lot of learning. Normally I can do new stuff via AI. This time I really needed yourself.

Appreciate it.... Have a good week / vacation / holiday....