SecureAnyCloud
Deployment guide

Certimate

Overview

Certimate is an open-source, self-hosted tool that automates the full lifecycle of your SSL and TLS certificates from a single web console. It issues certificates from ACME certificate authorities such as Let's Encrypt, ZeroSSL, Google Trust Services and SSL.com, then deploys them automatically to the places that serve them: web servers, Kubernetes clusters, CDNs, WAFs, load balancers and object storage across many providers.

A visual workflow editor lets you chain issuance, deployment, renewal and notification into one automated pipeline, so certificates are replaced before they expire without any manual steps. This SecureAnyCloud image serves Certimate 0.4.27 on a hardened Ubuntu 24.04 LTS base, patched at build time, with the web console fronted by nginx on port 80.

What you get:

  • Certimate 0.4.27, a single self-contained Go binary, managed by systemd
  • The web console and REST API on loopback 127.0.0.1:8090, fronted by nginx on :80
  • Secure by default. Certimate runs as a dedicated non-root service bound to loopback and is reached only through nginx. No shared login ever ships in the image.
  • A unique administrator password generated per instance on first boot and written to a protected file on the machine, so the upstream default credential never works
  • Embedded SQLite storage, with no external database to run
  • ACME issuance from Let's Encrypt, ZeroSSL, Google Trust Services, SSL.com and more
  • Automatic deployment to 150+ targets and automatic renewal through a visual workflow editor
  • Certificate expiry monitoring and multi-channel notifications
  • certimate.service and nginx.service as enabled systemd units
  • 24/7 SecureAnyCloud support

Prerequisites

  • An active Azure subscription, an SSH key pair, and a VNet and subnet in the target region.
  • Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point, because Certimate is extremely lightweight.
  • NSG inbound rules that allow 22/tcp from your management network and 80/tcp for the web console. If you intend to solve HTTP-01 ACME challenges or serve the console over HTTPS, you also need 443/tcp.
  • Restrict 80/tcp to trusted networks in production, because it is the administrative console.

Step 1 - Deploy from the Azure Marketplace

  • Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Certimate by SecureAnyCloud, and select Create.
  • On Basics, pick your subscription, resource group, region and size.
  • Under Administrator account, choose SSH public key and paste your key.
  • Under Inbound port rules, allow SSH (22) and HTTP (80).
  • Select Review + create, then select Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:certimate-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name certimate \
  --image sac1647283583153:certimate-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open the web console port, and port 443 if you plan to use HTTPS.

az vm open-port --resource-group <your-rg> --name certimate --port 80 --priority 900
az vm open-port --resource-group <your-rg> --name certimate --port 443 --priority 910

Step 3 - Confirm the service is running

SSH in as azureuser and confirm that Certimate and nginx are active. Certimate itself binds only to loopback on 127.0.0.1:8090, and nginx publishes the console on port 80.

systemctl is-active certimate.service nginx.service ss -tlnp | grep -E ":80 |127.0.0.1:8090" | sed 's/users:.*//'

Expected output: both services report active, nginx listens on :80, and Certimate listens on 127.0.0.1:8090.

You can also confirm that the API is healthy through the nginx front end.

curl -s http://127.0.0.1/api/health

Step 4 - Retrieve the administrator password for your instance

Your instance generated a unique administrator password on first boot and stored it in a root-owned file. Read it over SSH.

sudo cat /root/certimate-credentials.txt

Expected output (the password is unique to your VM):

certimate.admin_email=admin@certimate.fun certimate.admin_password=************************ certimate.console_url=http://<your-vm-ip>/

Keep this password safe. You can change it from the console after your first sign-in (see Step 8).

Step 5 - Sign in to the web console

In a browser, open http://<your-vm-public-ip>/. Sign in with the username admin@certimate.fun and the password from Step 4.

After you sign in, you land on the dashboard. It summarizes your certificates, workflows and recent runs, with shortcuts to create a workflow, change your password and configure certificate authorities.

Step 6 - Confirm there is no default login

The image ships with no usable default credential. You can prove it from the shell. The upstream default password is rejected, and only the unique password generated for your VM authenticates.

The check below reads that password from the credentials file and calls the console through nginx.

PW=$(sudo grep '^certimate.admin_password=' /root/certimate-credentials.txt | cut -d= -f2-)
echo "upstream default 1234567890 -> HTTP $(curl -s -o /dev/null -w '%{http_code}' -X POST http://127.0.0.1/api/collections/_superusers/auth-with-password -H 'Content-Type: application/json' -d '{"identity":"admin@certimate.fun","password":"1234567890"}')"
echo "this VM's admin password -> HTTP $(curl -s -o /dev/null -w '%{http_code}' -X POST http://127.0.0.1/api/collections/_superusers/auth-with-password -H 'Content-Type: application/json' -d "{\"identity\":\"admin@certimate.fun\",\"password\":\"$PW\"}")"

Expected output: the default password returns HTTP 400 (rejected), and your per-VM password returns HTTP 200 (authenticated).

Step 7 - Build a certificate workflow

Certimate's core is the visual workflow editor. From Workflows, choose Create from blank, or start from the Standard template (apply, deploy, notify) or the Monitoring template (watch expiry and alert).

Each workflow chains an ACME issuance node, one or more deployment nodes for your targets, and notification nodes. It then runs on a schedule, so renewal is fully automated.

Before you run a workflow, add your ACME certificate authority and provider credentials under Settings and Credentials. Then reference them from the workflow nodes.

Step 8 - Manage your account

Open Settings, then Account, to change the sign-in email or rotate the administrator password. The Settings area also holds certificate authority configuration, credential persistence, diagnostics and appearance options.

Step 9 - Where your data lives

All Certimate state, including the embedded SQLite database, your ACME accounts, issued certificates and deploy target credentials, lives under /opt/certimate/pb_data, owned by the dedicated certimate service user. The first-boot service initialized this directory freshly for your VM and rotated the administrator password.

sudo ls -la /opt/certimate/pb_data systemctl is-enabled certimate-firstboot.service certimate.service nginx.service

To back up Certimate, stop the service and archive /opt/certimate/pb_data; restore by replacing the directory and starting the service again.

Support

This image is built and maintained by SecureAnyCloud with 24/7 support. For deployment help or questions about Certimate on Azure, contact the SecureAnyCloud support team listed on your Azure Marketplace offer.

Deploy on Azure

Launch Certimate on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure