Automated SSL certificate renewal for Juniper SRX

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

A Juniper SRX keeps certificates in the Junos PKI store, and an IPsec VPN's IKE policy references one by certificate-id as its local-certificate. When a certificate renews, the PKI entry goes stale and the tunnel keeps authenticating with the old certificate until someone loads the new one, updates the IKE policy, and commits. Every 47 days. On every firewall you manage.

CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your SRX firewalls automatically via the CertKit Agent and the Junos REST API, and binds it to the IKE policy behind the VPN you choose.

Start free trial Watch demo

Built for Juniper SRX

The pre-built SRX IPsec VPN deployment template ships in your CertKit account. No scripting required.

CertKit renews your SRX certificate for you. On every renewal it loads the new certificate, key, and CA chain into the Junos PKI store, binds the certificate to the IKE policy behind your IPsec VPN in a single commit, and cleans up the superseded one. No CLI sessions, no manual PKI loads, no forgotten commit.

Deployments don't drop traffic: established IKE security associations keep using the previous certificate until their next rekey or reauthentication, so the tunnel picks up the new certificate on its own schedule instead of bouncing.

How to install an SSL certificate on a Juniper SRX

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

Generate a key pair and certificate request. Run request security pki generate-key-pair certificate-id my-cert, then request security pki local-certificate generate-certificate-signing-request with your subject and domain name — or create the CSR and key externally with OpenSSL.
Submit the CSR to a certificate authority. Purchase a certificate or use a free ACME CA, then wait for the signed certificate file to come back.
Configure a CA profile and load the chain. Create a ca-profile under security pki for the issuing CA, commit, then run request security pki ca-certificate load for each intermediate in the chain. Without the CA profiles, certificate validation fails.
Load the certificate. Copy the signed certificate to the device (/var/tmp is the usual spot) and run request security pki local-certificate load certificate-id my-cert filename /var/tmp/cert.pem, including the key file if it was generated externally.
Bind it to the IKE policy and commit. Run set security ike policy my-policy certificate local-certificate my-cert and commit. On devices running iked, local-certificate is a list that appends rather than replaces, so delete the stale entry in the same commit — then confirm with show security ike security-associations after the next rekey.

Every one of these steps is manual, and Junos 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 SRX you manage. Miss one and the next IKE rekey fails to authenticate — and the tunnel to your branch or partner site stays down.

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

How it works

 Your network            CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│  ┌─────────────┐  │     │                  │    │             │
│  │Deploy Agent │◄─┼─────┤  Issue & Renew   │◄──►│             │
│  └──┬────┬─────┘  │     │   Certificates   │    │             │
│     │    │ Junos  │     │                ┌───┐  └─────────────┘
│     │    │ REST   │     └───────────┬────│DNS│
│     ▼    ▼        │                 │    └───┘
│ ┌──────────────┐  │                 │
│ │ Juniper SRX  │  │                 │
│ │ [x] Loaded   │  │ ◄───────────────┘
│ │ [x] Bound    │  │       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 SRX over the Junos REST API on your LAN — HTTPS on port 3443 by default — to load the certificate into the PKI store and update the IKE policy. The firewall 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 SRX and other appliance on that network, so there's nothing to install on the firewalls themselves.

Our MSP works extensively with SonicWall. With certificate lifetimes getting shorter, we needed a solution to keep our clients' SSL VPN connections secure without overburdening our team. The team at CertKit delivered. They helped us develop a streamlined deployment method for SonicWall that makes certificate management simple and efficient. Even better, we're able to control the deployment window, preventing disruptions to our clients during the workday. I highly recommend CertKit to any organization struggling with certificate management.

Will Hoy, Owner, Norman Alan

What CertKit handles

Issue certificates via ACME, centrally. Your firewalls have no ACME configuration, no open ports, no public DNS credentials. One CNAME record is all your domain contributes.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any device.
Load the certificate, key, and chain over the Junos REST API. The CertKit Agent stages the files under /var/tmp with owner-only permissions, loads them into the PKI store, and removes the temporary files when the deployment finishes — even when it fails.
Create CA profiles automatically. Each intermediate CA in the chain needs a ca-profile before Junos will accept it. CertKit creates the missing ones under content-addressed certkit_ca_ names and reuses any profile that already holds the same CA, so nothing is duplicated.
Bind to the IKE policy in a single commit. CertKit resolves the VPN you name to its gateway and IKE policy, then binds the new certificate and removes stale certkit_ entries in the same commit — on devices running iked, local-certificate is a list that appends, so a naive update leaves the old certificate in play.
Keep tunnels up. Established IKE security associations keep the previous certificate until their next rekey or reauthentication, so the deployment itself never drops the tunnel.
Use deterministic, prefixed names. CertKit names each certificate certkit_ plus an ID and thumbprint, so the same renewal is never loaded twice and its certificates are easy to spot in show security pki local-certificate.
Clean up old certificates. After the new certificate is bound, CertKit deletes the superseded certkit_ entries from the PKI store. If Junos rejects a delete because the certificate is still in use, it's skipped rather than forced.
Verify the binding, not just the script. After the commit, CertKit re-reads the committed configuration and fails loudly if the IKE policy doesn't list the new certificate — or still lists a stale one.
Alert on failure. Load failures, commit 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 device. 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.
Enable the REST API and create a user. Run set system services rest https on the SRX (port 3443 by default) and create a Junos user with PKI, file, configuration, and VPN privileges — a super-user class login works. A dedicated automation account keeps the audit trail clean.
Install the CertKit Agent. One command on any Windows host with HTTPS reachability to the SRX. The agent runs as a background service and needs no inbound firewall rules.
Add the SRX deployment script. The pre-built template is in your account. Set the REST address, the Junos credentials, and the name of your IPsec VPN. CertKit runs it on every renewal.

See the full architecture →

Why not run ACME on the SRX?

Junos has no ACME client for VPN certificates, and giving a perimeter security device what ACME needs is a bad trade anyway: DNS provider credentials on the firewall are a privilege escalation waiting to happen, and opening port 80 to the public on the device that anchors your tunnels is worse.

Scripting the renewal yourself has its own sharp edges: CA profile bookkeeping before any load will succeed, orphaned key pairs that fail the next load with "key file already exists", and iked's appending local-certificate list that quietly keeps the old certificate bound next to the new one. 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 load, the binding, and the cleanup as one verified step, with no ACME client on the firewall.

SRX is just one part of your network edge

Most networks have more than one place where TLS certificates live: load balancers like F5 BIG-IP and Citrix NetScaler, web servers, and other firewall vendors like Fortinet, Palo Alto, SonicWall, and Cisco Firepower, plus the Aruba ClearPass cluster handling network access control. CertKit automates all of it from one account.

See all integrations

Start automating SRX 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