Why centralise your certificates
certbot does one thing very well: renewing the certificate of the server it runs on. As soon as you manage several servers, a shared wildcard certificate or client sites, each machine becomes a deadline to watch separately, and a silent failure is only discovered when the browser shows its warning.
On top of that, the lifetime of public certificates is getting shorter year after year, which multiplies renewals. Centralising issuance, deployment and monitoring in one place, with a history and alerts, is the safest way to never let a certificate expire again.
What Certimate brings
- Visual workflows — request, deployment and notification chained in one workflow, scheduled for renewal.
- DNS-01 and HTTP-01 — wildcard and multi-domain certificates through DNS-01 at more than 70 providers, including Cloudflare, OVHcloud and Hetzner.
- Several authorities — Let's Encrypt, ZeroSSL, Google Trust Services, SSL.com; RSA or ECC keys.
- More than 160 deployment targets — SSH, cPanel, Nginx Proxy Manager, Proxmox VE, Kubernetes, CDNs and cloud services.
- PEM, PFX and JKS formats — for nginx, Apache, IIS or a Java application.
- Alerts — email, Telegram, Slack, Discord, Matrix or webhook on every failure and before expiry.
Certimate, certbot and Nginx Proxy Manager
Scroll the table
| Certimate | certbot | Nginx Proxy Manager | |
|---|---|---|---|
| Web interface | Yes, visual workflows | No, command line | Yes |
| Several servers | Yes, SSH and API deployment | No, one per server | No, its own hosts |
| Wildcard through DNS-01 | Yes, more than 70 providers | Yes, through plugins | Yes |
| Failure alerts | Yes, multi-channel | No, to be scripted | No |
| Reverse proxy | No | No | Yes, that is its job |
| Run history | Yes | Local log | Partial |
Prerequisites
An Ubuntu 24.04 VPS with 512 MB of RAM and Docker installed is enough: Certimate uses about twenty megabytes. Plan a subdomain for the console (for example certs.example.com) pointing to the VPS, and nginx as a reverse proxy. For the workflows, keep at hand an API token from your DNS provider and SSH access to the servers that will receive certificates.
Install Certimate with Docker Compose
Prepare the directory and the password
Create the application directory and a
.envfile holding a randomly drawn administrator password.mkdir -p /opt/certimate && cd /opt/certimate printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 16)" > .env chmod 600 .envWrite the compose file
Create
compose.yaml. On the first start only, the command appliesADMIN_PASSWORDto the factory account before starting the server; the marker prevents it from later overwriting a password changed in the interface. The port is published on the loopback only: only nginx reaches it.services: certimate: image: certimate/certimate:v0.4.36 restart: unless-stopped ports: - "127.0.0.1:8109:8090" environment: ADMIN_PASSWORD: ${ADMIN_PASSWORD:?ADMIN_PASSWORD requis} entrypoint: ["sh", "-c"] command: - >- if [ ! -f /app/pb_data/.admin-seeded ]; then ./certimate superuser upsert [email protected] "$$ADMIN_PASSWORD" && touch /app/pb_data/.admin-seeded || exit 1; fi; exec ./certimate serve --http 0.0.0.0:8090 volumes: - certimate-data:/app/pb_data volumes: certimate-data: {}Start and check
Start the stack. Certimate applies its migrations at startup, then the health probe must answer.
docker compose up -d docker compose ps curl -fsS http://127.0.0.1:8109/api/health
Never leave the factory password active
The image ships an [email protected] account with the password 1234567890, documented in the project README. A console exposed with these credentials hands anyone your DNS tokens and SSH keys. The command above replaces it before the server even listens; if you run the image another way, change it before publishing the domain.
Publish the console over HTTPS behind nginx
Add a server block that proxies to the loopback. To bootstrap, use a certificate obtained once with certbot; Certimate can then renew its own like the others.
server {
listen 443 ssl;
server_name certs.example.com;
# ssl_certificate / ssl_certificate_key: your current certificate
location / {
proxy_pass http://127.0.0.1:8109;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}Open https://certs.example.com, log in with [email protected] and the password from the .env file, then change the email and password in the account settings.
First workflow: a wildcard certificate through DNS-01
Under Access, create a Cloudflare access (or OVHcloud, Hetzner…) with an API token limited to DNS edit permission on the zone concerned. Under Workflows, create a workflow: a request node with example.com and *.example.com, DNS-01 challenge, Let's Encrypt authority and ECC key.
Run the workflow by hand: Certimate creates the TXT record, waits for it to propagate, obtains the certificate and stores it under Certificates with its expiry date. The DNS-01 challenge needs no open port on target servers, and it is the only one that allows a wildcard.
Deploy over SSH to your nginx servers
On each target server, create a dedicated account that can only write to the certificate directory and reload nginx:
useradd -m -s /bin/bash certdeploy
install -d -o certdeploy -m 750 /etc/ssl/certimate
echo 'certdeploy ALL=(root) NOPASSWD: /usr/sbin/nginx -t, /usr/bin/systemctl reload nginx' > /etc/sudoers.d/certdeployIn Certimate, add key-based SSH access to this account, then an SSH deployment node after the request: paths /etc/ssl/certimate/example.com.pem and .key, command sudo nginx -t && sudo systemctl reload nginx. Point the ssl_certificate and ssl_certificate_key of your vhosts to these files.
Scheduled renewal and alerts
Enable the workflow's scheduled trigger (one run a day is enough: Certimate only renews when expiry gets close) and add a notification node to Telegram, Slack or email. Every run keeps its log: when something fails, you know whether the DNS challenge, the authority or the deployment broke, and you know it before expiry.
Security and backup
Certimate's database holds your DNS tokens, SSH keys and private keys: treat the console like a vault. Strong password, HTTPS only, tokens and SSH accounts with the strict minimum of rights. Back up the volume regularly, and encrypt the archive before copying it off the VPS:
cd /opt/certimate
docker compose stop
docker run --rm -v certimate_certimate-data:/data -v "$PWD":/backup alpine \
tar czf /backup/certimate-$(date +%F).tar.gz -C /data .
docker compose startOne-click Certimate on ServOrbit
From the Marketplace in your client area, Certimate installs on an Ubuntu 24.04 VPS in one click: official container, administrator password generated and applied before the first start, data volume and nginx reverse proxy over HTTPS on your domain or on the VPS's free subdomain. The password is shown in your client area, on the application's page.
