Automating IoT Certificate Rotation for mTLS using SocketXP

Certificate rotation is the part of mTLS security that teams consistently underestimate. Issuing a certificate is a one-time action. Keeping that certificate current across a fleet of hundreds or thousands of devices — indefinitely, without human intervention — is an ongoing operational commitment.

The traditional answer is scripting: write a renewal bash script, deploy it via cron or a systemd timer, handle failures, push updates via OTA when certificates change, build monitoring to catch what slips through. This is significant engineering work that sits entirely outside your product.

SocketXP takes a different approach. The SocketXP agent running as a background service on each device manages the complete certificate lifecycle automatically — initial issuance, continuous expiry monitoring, and renewal — without any scripts, timers, OTA deliveries, or monitoring pipelines you have to build and maintain.

For the full PKI architecture behind SocketXP’s mTLS model, see: Scaling mTLS IoT Security: The Developer’s Guide.

The Complete Certificate Lifecycle in SocketXP

The lifecycle has two phases. The first phase happens once per device. The second runs continuously for the device’s entire operating life without any human involvement.

Phase 1 — One time, at provisioning:

  socketxp ca login  --server 
        │
        └─► BastionXP CA module issues tls_server.crt + tls_server.key
            Agent stores credentials in /var/lib/socketxp/
            Agent connects to gateway on port 9444 with mTLS

Phase 2 — Ongoing, managed entirely by the agent:

  Agent monitors tls_server.crt expiry continuously
        │
        └─► When 30% validity remains → agent contacts BastionXP CA
            CA issues fresh tls_server.crt
            Agent reconnects with renewed certificate
            Zero downtime. No operator action. No scripts.

Phase 1: Initial Certificate Issuance

The SocketXP agent must be installed and registered on the device before certificate issuance. Once the agent is running, two commands cover all certificate needs.

Server Certificate for the IoT Device

The device server certificate authenticates the IoT device to the SocketXP gateway on port 9444. Obtain it with:

sudo socketxp ca login  --server "device001.fleet.local"

The BastionXP CA module — SocketXP’s built-in private certificate authority — signs the certificate and the agent downloads two files to /var/lib/socketxp/:

tls_server.crt   ← device certificate (signed by BastionXP CA)
tls_server.key   ← device private key

The name argument (device001.fleet.local) becomes the certificate’s Common Name (CN) — the device’s unique cryptographic identity on the SocketXP platform. Each device in the fleet should receive a distinct name so its certificate identifies it individually.

From this point, the agent uses tls_server.crt for every mTLS connection to the gateway on port 9444. The gateway validates the certificate against the BastionXP CA root, confirms it has not expired or been revoked, and admits the tunnel.

User Client Certificate for Operator Access

When a developer or field engineer needs to connect to a device, they obtain a short-lived client certificate on their own machine:

sudo socketxp ca login  --client "[email protected]"

This downloads tls_client.crt and tls_client.key to /var/lib/socketxp/. The client certificate is valid for 24 hours and then expires automatically — operator access credentials have a built-in time limit without any revocation step required.

Phase 2: Continuous Automatic Renewal by the Agent

Once the initial certificates are in place, the SocketXP agent takes over the entire renewal lifecycle. No additional configuration is required.

What the Agent Does

The SocketXP agent running as a background systemd service continuously monitors the expiry date of tls_server.crt. It reads the certificate’s Not After timestamp and tracks how much validity remains relative to the total certificate validity period.

When the remaining validity falls to 30% or below, the agent automatically:

1. Contacts the BastionXP CA module through the existing mTLS tunnel
2. Requests a new certificate for the same device identity (same CN)
3. Receives the freshly signed tls_server.crt from the CA
4. Replaces the existing certificate on disk
5. Re-establishes the mTLS connection to the gateway using the renewed certificate

This happens entirely within the agent — no external script is called, no OTA delivery is needed, no systemd timer fires a renewal job. The agent manages the renewal as part of its normal background operation.

The 30% Renewal Threshold

Triggering renewal at 30% of validity remaining is a deliberate design choice that balances security and operational resilience.

Example: 90-day certificate validity

Day 0 ──────────────────────────────────────── Day 90
       │                    │              │
       │                    │              └─ Expiry: mTLS fails if not renewed
       │                    │
       │                    └─ Day 63 (70% elapsed, 30% remaining)
       │                       Agent begins automatic renewal
       │                       27 days of retry window if first attempt fails
       │
       └─ Day 0: Certificate issued, agent starts monitoring

For a 90-day certificate, renewal starts on day 63 — leaving 27 days for the renewal to complete before expiry. If the first renewal attempt encounters a transient network issue or a temporary CA unavailability, the agent retries. It has 27 days of headroom before the certificate actually expires.

The same 30% rule scales consistently across different validity periods:

The longer the validity period, the larger the retry window — giving intermittently connected devices more time to reconnect and complete renewal before expiry.

Automatic Fleet-Wide Staggering

A common concern when provisioning a large fleet in a single batch is simultaneous expiration: if all devices receive certificates on the same day with the same validity period, all certificates expire on the same day. If renewal encounters any issue on that day, the entire fleet goes offline at once.

The SocketXP agent’s continuous monitoring model handles this naturally. Because each device’s agent monitors and renews independently, any slight variation in when devices were provisioned, when they were first connected, or when their initial certificates were downloaded results in different renewal start times across the fleet. Devices do not coordinate their renewals — each agent acts on its own certificate’s 30% threshold independently.

Additionally, the agent renews the certificate slightly before the 30% threshold is reached rather than at exactly 30%, introducing further natural variation across a large fleet. The result is that renewal load is distributed across a window of time rather than concentrated on a single date — without any deliberate staggering configuration required.

User Client Certificate Lifecycle

User client certificates (issued with --client) have a 24-hour validity period and are designed to be obtained fresh for each session rather than renewed by the agent.

The workflow for operator access is intentionally lightweight:

# At the start of each session:
sudo socketxp ca login  --client "[email protected]"

# Connect to a device using the fresh client certificate:
sudo socketxp connect tcp://127.0.0.1:2222 \
  --iot-slave \
  --peer-device-id  \
  --peer-device-port 22 \
  --authtoken  \
  --gateway-port 9444 \
  --mtls \
  --cert /var/lib/socketxp/tls_client.crt \
  --key /var/lib/socketxp/tls_client.key

The 24-hour certificate expires at the end of the day without any revocation action. Tomorrow the engineer runs socketxp ca login --client again. There are no long-lived operator credentials to protect, rotate, or audit.

This design eliminates an entire class of credential management problems: there is no operator credential database to maintain, no password rotation policy to enforce, and no risk of a credential that was issued months ago being used by someone who has since left the organization.

What You Do Not Need to Build

Teams migrating from a self-managed mTLS certificate infrastructure often arrive with a set of operational tooling already planned or partially built. With SocketXP’s agent-managed certificate lifecycle, none of the following is needed for the SocketXP mTLS channel:

The single external requirement is that the device has network connectivity to reach the SocketXP gateway during the 30% renewal window. For devices with reliable connectivity, this is always satisfied. For intermittently connected devices, the renewal window provides the buffer needed for the device to reconnect and complete renewal before expiry.

Key Rotation vs. Certificate Renewal

The SocketXP agent’s automatic renewal replaces the certificate but reuses the existing private key. This is certificate renewal, not key rotation.

For most IoT deployments, agent-managed certificate renewal provides the right balance of security and operational simplicity. The private key on each device is unique per device and never transmitted — the risk of key compromise is low, and bounding it further with short certificate validity periods is the practical mitigation.

For deployments with hardware-backed keys (TPM 2.0, Secure Element), key rotation can be performed by re-issuing socketxp ca login --server with a new key generated on the hardware. The agent then uses the new key-certificate pair going forward.

Next Steps

• Scaling mTLS IoT Security: The Complete Developer Guide — hub page covering PKI architecture, BastionXP CA module, SCEP/CRL/OCSP
• How to Implement mTLS in IoT — step-by-step mTLS setup: initial certificate issuance and agent configuration
• Zero-Touch Provisioning for IoT Devices — integrating certificate issuance into the first-boot fleet onboarding workflow
• Hardware Security Modules and mTLS for IoT — TPM and Secure Element options for hardware-backed private key protection