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 to install an SSL certificate on CrushFTP

The manual process, if you want to do it yourself:

Get the renewed certificate, private key, and chain. From your CA or an ACME client running somewhere with validation access.
Convert it to the format CrushFTP needs: a Java KeyStore. Bundle the certificate, key, and intermediates into a PKCS12 with openssl, then keytool -importkeystore it into a .jks with the alias and password CrushFTP expects.
Replace the keystore on the server. Copy the new .jks over the file your SSL settings point at.
Restart CrushFTP. The keystore is read at service start, so the old certificate stays live until the restart lands.
Verify. Confirm the HTTPS and FTPS listeners serve the new certificate, then repeat on every CrushFTP server.

Every one of these steps is manual, and CrushFTP won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, on every server. Miss one and a partner's automated transfer fails the TLS handshake.

At 47 days, automation is the only sustainable way to run CrushFTP certificates. Here's how CertKit does it.

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 run ACME on the file server?

Running an ACME client directly on a file-transfer server isn't a good answer. 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: other transfer servers like FileZilla Server, keystore-based servers like Tomcat, web servers like nginx and IIS, self-hosted apps like GitLab, 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