Automated SSL certificate renewal for CrushFTP

CrushFTP won't update a renewed certificate on its own. CertKit will.

CrushFTP loads its TLS certificate from a Java KeyStore when the service starts. When a certificate renews, the keystore on disk is stale and CrushFTP keeps serving the old certificate until someone rebuilds the keystore and restarts the server. Every 47 days. On every CrushFTP server you run.

CertKit centralizes certificate issuance and renewal, then writes the updated Java KeyStore to the path CrushFTP already reads and restarts the service automatically via the CertKit Agent.

Start free trial Watch demo

Built for CrushFTP

The pre-built Java KeyStore template and restart script ship in your CertKit account. No scripting required.

The CertKit Agent writes the renewed certificate, private key, and intermediate chain into a Java KeyStore (.jks) at the path you set, then restarts the CrushFTP Windows service so it loads the new certificate.

You point CrushFTP at that keystore file once in the management UI. After that, CertKit overwrites the same file on every renewal and restarts the service. There is nothing to reconfigure in CrushFTP again.

How it works

 Your CrushFTP server     CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ .jks file  ◄──┘ │ │                 │    └───┘
│ [x] Written     │ │                 │
│                 │ │                 │
│ CrushFTP    ◄───┘ │ ◄───────────────┘
│ [x] Restarted     │       Verify
└───────────────────┘

CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. Your CrushFTP server does not run ACME, no open ports, no DNS credentials. It just runs the agent.

What CertKit handles

Issue certificates via ACME, centrally. Your CrushFTP servers have no ACME configuration, no open ports, no credentials to manage. One CNAME record is all they contribute.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any server.
Write a complete Java KeyStore. The CertKit Agent builds the .jks with the certificate, its private key, and the full intermediate chain, under the alias and keystore password you set, at the path CrushFTP reads.
Restart CrushFTP to load the new certificate. The deployment script restarts the CrushFTP Windows service and waits for it to return to Running, so the new certificate is live before the renewal is marked complete.
Fail safely if the service name is wrong. If the Windows service can't be found or doesn't restart, the keystore is already on disk and the script tells you to restart CrushFTP manually, rather than leaving the renewal in a half-applied state.
Verify the deployment, not just the script. After each renewal, CertKit connects to your CrushFTP TLS listener and confirms the new certificate is actually being served. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your users do.
Alert on failure. Deployment failures, restart errors, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and server. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit. Every renewal challenge after that is automatic.
Install the CertKit Agent. One command on your CrushFTP server. The agent runs as a Windows service and needs no inbound firewall rules.
Add the CrushFTP deployment script. Pick the Java KeyStore template, set the keystore path, password, alias, and your CrushFTP service name. CertKit runs it on every renewal.
Point CrushFTP at the keystore once. In the CrushFTP admin UI, set the SSL keystore to the file CertKit writes. This is the only change you make inside CrushFTP, and you only make it once.

See the full architecture →

Why not rebuild the keystore by hand?

The manual CrushFTP renewal workflow is a keytool sequence: import the renewed certificate and its chain into a Java KeyStore, copy it to the server, then restart CrushFTP so it picks up the new file. That works once. Run it on every CrushFTP server every 47 days and it becomes a source of expired FTPS and HTTPS listeners, discovered when a partner's automated transfer starts failing the TLS handshake.

Running an ACME client directly on a file-transfer server isn't a good answer either. Public CAs require HTTP-01 or DNS-01 validation. Opening port 80 on a server that faces your partners, or putting DNS provider credentials on it, adds exposure to a machine whose whole job is moving sensitive files.

CertKit issues the certificate centrally via delegated DNS validation, then the agent writes the keystore and restarts the service as one verified step, with no ACME client on the server and no keytool to run by hand.

CrushFTP is just one server that needs a certificate

Most environments have more than one place where TLS certificates live: web servers like nginx and IIS, load balancers like F5, and firewalls like Fortinet and Palo Alto. CertKit automates all of it from one account.

See all integrations

Start automating CrushFTP certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing