After long server downtime: cannot connect to CA

[flippsOvvu]

Hello,

my server suffered a long downtime. Certificates cannot be renewed, because they are already expired.

I use a scheduled SystemD service with command
step ca renew --force [filename].crt [filename].key

default.json for the client is:

{
  "ca-url": "https://[address]",
  "fingerprint": "[fingerprint]",
  "root": "[path]"
}

I know they can't be renewed because of the CA's policy, but trying to just overwrite using
step ca certificate [name] ***.crt ***.key
also fails, because the CA itself presents an expired certificate to the client, when it tries to connect.

(I used
sudo openssl s_client -showcerts -connect [IP]:443
to confirm this)

Exerpt from the CA's log:

Jan 09 21:14:02 cert-auth step-ca[638]: 2026/01/09 21:14:02 /usr/local/go/src/net/http/server.go:3638: http: TLS handshake error from [IP:port]: remote error: tls: bad certificate
[...]
Jan 07 08:37:05 cert-auth step-ca[638]: time="2026-01-07T08:37:05+01:00" level=warning duration=2.781026ms duration-ns=2781026 error="cahandler.Renew: authority.authorizeRenew: The request lacked necessary authorization to be completed: certificate expired on 2026-01-07 00:07:54 +0000 UTC" fields.time="2026-01-07T08:37:05+01:00" method=POST name=ca ott=[...] path=/renew protocol=HTTP/1.1 referer= remote-address=[IP] request-id=78c6bf9f-d74e-4841-bda2-9176d788c64c size=140 status=401 user-agent="Smallstep CLI/0.28.6 (linux/amd64)" user-id=
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Serving HTTPS on :443 ...
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 X.509 Root Fingerprint: [fingerprint]
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Additional configured hostnames: [additional names]
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Root certificates are available at https://[name]:443/roots.pem
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 The primary server URL is https://[name]:443
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Config file: [path]
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Community Discord: https://u.step.sm/discord
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Documentation: https://u.step.sm/docs/ca
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Starting Smallstep CA/ (linux/amd64)
Jan 07 08:35:26 cert-auth step-ca[638]: 2026/01/07 08:35:26 Building new tls configuration using step-ca x509 Signer Interface
Jan 07 08:35:25 cert-auth step-ca[638]: badger 2026/01/07 08:35:25 INFO: Replay took: 16.193594ms
Jan 07 08:35:25 cert-auth step-ca[638]: badger 2026/01/07 08:35:25 INFO: Replaying file id: 0 at offset: 385702
Jan 07 08:35:25 cert-auth step-ca[638]: badger 2026/01/07 08:35:25 INFO: All 1 tables opened in 8ms
Jan 07 08:35:22 cert-auth systemd[1]: Started step-ca.service.

Regarding the log entry: Jan 07 08:37:05 ...: the "client" trying to renew was the CA itself, so that already failed.

I suppose I need to make the CA renew the certificate it presents on TLS-connections. How do I do this?

Thanks in advance and kind regards.

[tashian]

Hmm. The server TLS certificate for step-ca is signed when the CA starts up and you don't need to renew it. It auto-renews internally. step-ca should never present an expired certificate to the client. If it does, that sounds like a bug.

[flippsOvvu]

The server was shut down ungracefully by powerloss.

I rebooted the CA's host which solved the issue for me.

Forgot to mention that I use the CA in conjunction with a Yubikey.

Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Serving HTTPS on :443 ...
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 X.509 Root Fingerprint: [...]
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Additional configured hostnames: [...]
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Root certificates are available at [...]:443/roots.pem
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 The primary server URL is [...]:443
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Config file: [...]
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Community Discord: https://u.step.sm/discord
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Documentation: https://u.step.sm/docs/ca
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Starting Smallstep CA/ (linux/amd64)
Jan 13 08:05:54 cert-auth step-ca[629]: 2026/01/13 08:05:54 Building new tls configuration using step-ca x509 Signer Interface
Jan 13 08:05:54 cert-auth step-ca[629]: badger 2026/01/13 08:05:54 INFO: Replay took: 2.254µs
Jan 13 08:05:54 cert-auth step-ca[629]: badger 2026/01/13 08:05:54 INFO: Replaying file id: 0 at offset: 616789
Jan 13 08:05:54 cert-auth step-ca[629]: badger 2026/01/13 08:05:54 INFO: All 1 tables opened in 15ms
Jan 13 08:05:52 cert-auth systemd[1]: Started step-ca.service.
-- Boot [...]--
Jan 13 08:05:41 cert-auth systemd[1]: step-ca.service: Consumed 24min 13.960s CPU time, 54.3M memory peak, 0B memory swap peak.
Jan 13 08:05:41 cert-auth systemd[1]: Stopped step-ca.service.
Jan 13 08:05:41 cert-auth systemd[1]: step-ca.service: Deactivated successfully.
Jan 13 08:05:41 cert-auth step-ca[638]: badger 2026/01/13 08:05:41 INFO: Force compaction on level 0 done
Jan 13 08:05:41 cert-auth step-ca[638]: badger 2026/01/13 08:05:41 INFO: [Compactor: 173] Compaction for level: 0 DONE
Jan 13 08:05:41 cert-auth step-ca[638]: badger 2026/01/13 08:05:41 INFO: LOG Compact 0->1, del 2 tables, add 1 tables, took 19.770986ms
Jan 13 08:05:41 cert-auth step-ca[638]: badger 2026/01/13 08:05:41 INFO: [Compactor: 173] Running compaction: {level:0 score:1.73 dropPrefixes:[]} for level: 0
Jan 13 08:05:41 cert-auth step-ca[638]: badger 2026/01/13 08:05:41 INFO: Storing value log head: {Fid:0 Len:32 Offset:616757}
Jan 13 08:05:41 cert-auth step-ca[638]: 2026/01/13 08:05:41 error closing the key manager: error closing yubikey: the Smart card resource manager is not running
Jan 13 08:05:41 cert-auth step-ca[638]: 2026/01/13 08:05:41 shutting down ...
Jan 13 08:05:41 cert-auth systemd[1]: Stopping step-ca.service ...
[...]

Highlight:
Jan 13 08:05:41 cert-auth step-ca[638]: 2026/01/13 08:05:41 error closing the key manager: error closing yubikey: the Smart card resource manager is not running
This suggests the CA was not able to access the yubikey after the hard shutdown (?).