How It Works

The update workflow

Platform creates a certificate update or deployment task
          ↓
Persistent connection notifies certone
          ↓
Compare platform versions with local records
          ↓
Download when needed; validate certificate, private key, and validity
          ↓
Deploy to files / Synology DSM / IIS
          ↓
Run the corresponding checks and activation steps
          ↓
Save results and report to the platform

CertOne initiates an outbound Socket.IO connection to receive notifications. Ordinary deployments do not require an inbound listener for CertOne. The runtime must be able to establish HTTPS/WebSocket connections to the platform. The application itself provides the website's HTTPS port.

CertOne deploys certificates. The platform handles certificate requests, domain validation, and issuance. Prepare certificates in the platform and associate them with a deployment node first. CertOne does not automatically write nginx site configuration or create IIS websites.

The platform returns the certificates associated with the node. The agent compares each version and downloads only new or changed certificates. Default synchronization requires no certificate IDs in local configuration. New associations are discovered on the next push or synchronization. Unbinding stops synchronization but retains deployed files and DSM entries; remove them only after confirming they are no longer used.

Versions and cache

The program separately records:

• Downloaded version: Certificate material is completely saved locally.
• Deployed version: A particular target successfully completed its application operations.
• Verification status: The target's configured activation check has passed.

When versions, deployment configuration, and output contents are unchanged, unnecessary downloads and reloads are skipped. Damaged file outputs can be restored from a complete cache. If the local cache is damaged too, certificates must be fetched again.

A manually initiated platform deployment task can request redeployment of the same version. An unchanged certificate version therefore does not guarantee that a manual push will skip reloading.

Periodic reconciliation and reconnection

In addition to real-time notifications, version checks occur in these situations:

Situation	Behavior
Program startup	Reconcile after connecting
Reconnection	Recheck the latest valid certificate versions
Continuous operation	Reconcile approximately hourly by default, with up to 5% timing jitter: about 60–63 minutes
Deployment failure	During continuous operation, retry during subsequent checks, usually about a minute later
Network failure	Reconnect with increasing, randomized delays, capped at approximately one minute
Explicit authentication rejection or disabled node	Stop automatic retries and log the reason; correct the problem and restart

Retries do not guarantee that certificates remain valid indefinitely. Extended outages can prevent renewed certificates from being deployed. Continue monitoring expiration dates and platform alerts.

Failure recovery

File deployment retains backups and recovery records. If validation or reload fails, the agent attempts to restore old files and invokes rollback when needed. After rollback, the previous deployed version is retained and the target is marked for retry. Incomplete recovery produces an explicit error.

Automatic recovery covers certificate files and configured rollback operations. Custom scripts that modify databases or external systems must handle their own recovery. Scripts should be safe to repeat so retries do not duplicate operations or cause other side effects.

Synology and IIS have their own deployment workflows; see their respective guides.