Built for Citrix NetScaler
The pre-built NetScaler deployment template ships in your CertKit account. No scripting required.
A NetScaler binds a named SSL certificate-key pair to load balancing virtual servers,
services, and Citrix Gateway. When a certificate renews, the files under
/nsconfig/ssl go stale and every binding keeps serving the old certificate
until someone uploads the new files, updates the certkey, and saves the configuration.
Every 47 days.
On every appliance you manage.
CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your NetScaler appliances automatically via the CertKit Agent over SSH, refreshes the certkey pair in place, and saves the config.
The pre-built NetScaler deployment template ships in your CertKit account. No scripting required.
CertKit renews your NetScaler certificate for you. On every renewal it uploads the new
certificate and private key over SCP, runs update ssl certkey so the pair
refreshes in place, and saves the running configuration. Every virtual server, service,
and Citrix Gateway bound to that certkey serves the new certificate immediately. No
per-vserver rebinding, no service restart.
The pre-built NetScaler template ships with your CertKit account. Point CertKit at your appliance once and it handles every renewal after that. If you want to see or adjust exactly what runs, the full deployment script is right there in your account.
The manual process, if you want to do it yourself:
/nsconfig/ssl over SCP. Point at the wrong path and the install fails
with "cannot find file or folder".
save ns config, or the renewal disappears on the next reboot.
Then repeat on every appliance that doesn't share HA config.
Every one of these steps is manual, and NetScaler 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 MPX, VPX, and SDX you run. Miss one and Citrix Gateway greets remote workers with an expired certificate.
At 47 days, automation is the only sustainable way to run NetScaler certificates. Here's how CertKit does it.
Your network CertKit ACME CA ┌───────────────────┐ ┌──────────────────┐ ┌─────────────┐ │ ┌─────────────┐ │ │ │ │ │ │ │Deploy Agent │◄─┼─────┤ Issue & Renew │◄──►│ │ │ └──┬────┬─────┘ │ │ Certificates │ │ │ │ │ │ SSH/ │ │ ┌───┐ └─────────────┘ │ │ │ SCP │ └───────────┬────│DNS│ │ ▼ ▼ │ │ └───┘ │ ┌──────────────┐ │ │ │ │ NetScaler │ │ │ │ │ [x] Uploaded │ │ ◄───────────────┘ │ │ [x] Updated │ │ Verify │ └──────────────┘ │ └───────────────────┘
CertKit issues and renews certificates centrally in the cloud using delegated DNS validation. You create a one-time CNAME record; CertKit handles every ACME challenge after that.
The deploy agent is a small service you run on a Windows host inside your network. It makes an outbound HTTPS connection to CertKit to pull each renewed certificate, then connects to the NetScaler management address (NSIP) over SSH on your LAN to upload the files and refresh the certkey pair. The appliance never talks to CertKit or the public internet directly, never runs ACME, needs no port 80 open, and never stores DNS credentials. One deploy agent can reach every NetScaler and other appliance on that network, so there's nothing to install on the appliances themselves.
Using CertKit to manage our public-facing SSL certificates has been an excellent decision. The platform is user-friendly, certificates are easy to deploy, and the automation agent streamlines the entire certificate lifecycle, eliminating concerns around shortening certificate validity periods.
Chris Austin, IT Engineer, Buckman
/nsconfig/ssl, next to the appliance's existing SSL files.
update ssl certkey over SSH, so every virtual server,
service, and Citrix Gateway bound to the pair serves the new certificate the moment
the update lands. No per-vserver rebinding, no restart, no dropped sessions.
save ns config so the
renewal survives a reboot.
ssh-keygen and add the public key to the
NetScaler user's authorized keys (/nsconfig/ssh/authorized_keys for
nsroot). A dedicated automation account is better practice than nsroot.
Answering ACME challenges from the appliance itself is fragile. HTTP-01 means maintaining responder policies for the challenge path on every domain's virtual server. DNS-01 means storing DNS provider credentials on the device that terminates TLS for your applications, which is a privilege escalation waiting to happen.
Scripting the renewal yourself has its own sharp edges: SSH automation against the NSIP,
the domain check that rejects an update when the subject changed, keeping
/nsconfig/ssl in sync across HA nodes, and the save ns config
everyone forgets until a reboot rolls the certificate back. We built and tested the
deployment so you don't have to. CertKit issues the certificate via
delegated DNS validation, then the agent
handles the upload, the certkey update, and the save as one verified step, with
no ACME client on the appliance.
Most networks have more than one place where TLS certificates live: F5 load balancers, firewalls like Fortinet, Palo Alto, and SonicWall, plus the web servers behind them. CertKit automates all of it from one account.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.