How to change Certificate on a Custom Linux Service

The aethercert Custom Linux target supports any service that reads certificate and key files. Because no product-specific activation is implied, the service's own documentation remains the authority for format, path, ownership, reload, and HA behavior.

Before you begin

Identify the exact process, systemd unit, configuration directives, chroot/container view, and service account. Record existing paths, symlinks, owner, mode, ACLs, SELinux/AppArmor labels, reload command, and rollback command.

Step-by-step certificate replacement

1. Determine whether the consumer expects separate leaf/chain/key PEMs, a leaf-first full chain, a combined bundle, PKCS#12, or a Java keystore. Do not convert by guess.

2. Verify names, dates, chain, and key match:

   openssl x509 -in certificate.pem -noout -subject -issuer -dates -ext subjectAltName
   openssl pkey -in private.key -pubout | sha256sum
   openssl x509 -in certificate.pem -pubkey -noout | sha256sum

3. Write into a root-only versioned directory, set the documented owner/mode, preserve mandatory access-control labels, then atomically switch a symlink or rename files.

4. Run the product's configuration-test command before activation.

5. Use its graceful reload if it rereads TLS material safely; otherwise perform a rolling restart across redundant nodes. Confirm the new process is healthy before updating the next node.

Product-specific considerations

Some daemons read the key as root before dropping privileges; others require their runtime account to read it. Some watch symlinks, while others resolve the target only at startup. Mounted Kubernetes/Docker files and chroots can have another view of the same host path. Document these properties for the actual service rather than applying generic chmod 644 advice to a private key.

Verify the new certificate

Check configuration/process logs, then inspect the certificate actually served using the protocol-aware client. For HTTPS:

openssl s_client -connect service.example.com:443 -servername service.example.com -showcerts </dev/null

Verify each node directly and through the public address.

Rollback

Restore the old symlink or files with their exact metadata, re-run validation, and reload/restart using the same safe sequence.

Common problems

• The service expects a different bundle format or chain order.
• The file is correct on the host but absent inside a chroot/container.
• Owner, mode, ACL, or security label prevents key access.
• A reload signal does not make this service reread certificates.

Automating certificate replacement with aethercert

The aethercert Custom Linux target writes certificate, chain, and key material to the configured paths and can run an administrator-supplied reload command. The command and paths must match the service's documented behavior.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

Sources

• OpenSSL verification command reference
• systemd service control