Automated SSL certificate renewal for EZproxy

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

EZproxy loads its TLS certificate from a set of numbered files in its ssl directory when the service starts, and a file named active decides which number is live. When a certificate renews, those files are stale and EZproxy keeps serving the old certificate until someone pastes the new one into the admin page, activates it, and restarts the service. Every 47 days. For every library, campus, and consortium proxy you run.

CertKit centralizes certificate issuance and renewal, then writes the updated .crt, .key, and .ca files into the EZproxy ssl directory and restarts the service automatically via the CertKit Agent.

Start free trial Watch demo

Built for EZproxy

Built with the University of St. Thomas. The PEM template and restart script are documented in the EZproxy deployment guide.

The CertKit Agent writes the renewed certificate, private key, and intermediate chain as three PEM files under one certificate number in the EZproxy ssl directory (00000099.crt, 00000099.key, 00000099.ca), then restarts the EZproxy service so it loads the new certificate.

You point the active file at that number once. After that, CertKit overwrites the same three files on every renewal and restarts the service. Nothing to paste into the admin page, no new certificate entries piling up, and no Restart EZproxy link to remember.

The restart interrupts proxied sessions for a few seconds. Set a deployment window overnight and users never notice. Works with self-hosted EZproxy on Windows and Linux. If OCLC hosts your EZproxy, they manage the certificate for you.

How to install an SSL certificate on EZproxy

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

Generate a certificate signing request in EZproxy. Log in to /admin, open Manage SSL (https) certificates, and click Create New SSL Certificate. Fill in country, unabbreviated state, organization, and email, then the certificate name and Subject Alternate Name. A wildcard certificate for Proxy by Hostname needs EZproxy 6.1 or later. Click Certificate Signing Request.
Submit the CSR to your certificate authority. Copy everything from BEGIN CERTIFICATE REQUEST through END CERTIFICATE REQUEST. When asked for a server type, choose Apache. Don't delete the request while you wait, since the certificate only applies against the CSR that created its key.
Paste the issued certificate into EZproxy. Back on the SSL management page, open the CSR entry, paste the server certificate (not the intermediate), and click Save. Then paste the intermediate chain into the box at the bottom of the Certificate Details page and save again.
Activate the certificate. On the Certificate Details page, type ACTIVE in the box and click Activate. EZproxy updates the active file in its ssl directory to the new certificate number.
Restart EZproxy and verify. The certificate is read at service start, so the old one stays live until you click Restart EZproxy on the admin page or run net stop ezproxy and net start ezproxy. Reload the login page over https and confirm the new certificate is served.

Every one of these steps is manual, and EZproxy 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, twelve times a year. Miss one and every student, faculty member, and remote patron gets a browser warning on the login page and loses access to every database behind it.

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

How it works

 Your EZproxy server      CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ ssl\      ◄───┘ │ │                 │    └───┘
│  .crt .key .ca  │ │                 │
│ [x] Written     │ │                 │
│                 │ │                 │
│ EZproxy     ◄───┘ │ ◄───────────────┘
│ [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 EZproxy server does not run ACME, no open ports, no DNS credentials. It just runs the agent.

From an operational perspective, CertKit is easy to deploy and manage. The ability to configure unique and specialized certificates is key to replacing our manual certificate processes.

Laura Thomas, Senior Central Systems Administrator, University of St. Thomas

What CertKit handles

Issue certificates via ACME, centrally. Your EZproxy server has no ACME configuration, no open ports, no credentials to manage. One CNAME record is all it contributes.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on the server.
Write the three files EZproxy reads. The CertKit Agent writes the server certificate to .crt, the private key to .key, and the intermediate chain to .ca, all under the certificate number your active file points at.
Restart EZproxy to load the new certificate. The deployment script restarts the EZproxy 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 restart doesn't land. If the service can't be found or doesn't come back, the files are already on disk and the deployment is marked failed with the reason, rather than left in a half-applied state.
Verify the deployment, not just the script. After each renewal, CertKit connects to your EZproxy login port 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 patrons 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 EZproxy server. The agent runs as a Windows service (or a Linux daemon) and needs no inbound firewall rules.
Add the EZproxy deployment. Choose the PEM Cert+Key+Chain format, set the three destinations to a numbered name in the EZproxy ssl directory, and add the restart script from the EZproxy deployment guide. CertKit runs it on every renewal.
Point EZproxy at the files once. Set the number in the active file to the one CertKit writes. This is the only change you make inside EZproxy, and you only make it once.

See the full architecture →

Why not run certbot on the EZproxy server?

The common workaround is certbot on the proxy box with symlinks from the ssl directory into /etc/letsencrypt/live and a cron job to restart EZproxy. It works until it doesn't. Public CAs need HTTP-01 or DNS-01 validation, so the server either exposes port 80 or holds DNS provider credentials, on a machine whose whole job is authenticating your users to licensed content. The restart hook is a second thing to wire up, nobody is told when it stops firing, and on Windows the whole arrangement is awkward from the start.

CertKit issues the certificate centrally via delegated DNS validation, then the agent writes the files and restarts the service as one verified step, with no ACME client on the server and nothing to paste into the admin page.

EZproxy is just one server that needs a certificate

A campus has more than one place where TLS certificates live: web servers like IIS and Tomcat, self-hosted apps like GitLab, file transfer servers like CrushFTP and FileZilla Server, the NPS servers behind campus Wi-Fi, and firewalls like Fortinet and Palo Alto. CertKit automates all of it from one account.

See all integrations

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