Security Azure

Certimate on Ubuntu 24.04 on Azure User Guide

| Product: Certimate on Ubuntu 24.04 LTS on Azure

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. The cloudimg image serves Certimate 0.4.27 on a hardened, fully patched Ubuntu 24.04 LTS base, with the web console fronted by nginx on port 80.

The image is secure by default. Certimate runs as a dedicated non root service bound to loopback and is reached only through nginx, and no shared login ever ships in the image. A unique administrator password is generated for your instance on first boot and written to a protected file on the machine, so the upstream default credential never works. Backed by 24/7 cloudimg support.

What is included:

  • 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
  • A unique administrator password generated per instance on first boot, no default login
  • Embedded SQLite storage, 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 via a visual workflow editor
  • Certificate expiry monitoring and multi channel notifications
  • certimate.service and nginx.service as enabled systemd units
  • 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point; Certimate is extremely lightweight. NSG inbound: 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 will also want 443/tcp. Restrict 80/tcp to trusted networks in production, since 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 cloudimg, 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). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name certimate \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open the web console port (and 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 Certimate and nginx are active. Certimate itself binds only to loopback on 127.0.0.1:8090; 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.

The certimate and nginx services reporting active, with nginx listening on port 80 and the Certimate server bound to loopback on 127.0.0.1:8090

You can also confirm the API is healthy through the front:

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.

The Certimate sign in page served through nginx on port 80, with the username and password fields and the Certimate 0.4.27 build shown in the footer

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

The Certimate dashboard after sign in, showing certificate and workflow counters, quick shortcuts and the recent workflow runs table

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).

The upstream default credential returning HTTP 400 rejected while the unique per VM administrator password returns HTTP 200 authenticated, proving no default login ships in the image

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, then runs on a schedule so renewal is fully automated.

The Certimate create workflow page offering a blank workflow, file import, and the Standard and Monitoring visual workflow templates for automated certificate management

Before running 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.

The Certimate account settings page where you change the administrator sign in email and password, with the settings navigation for certificate authority, persistence and diagnostics

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 initialised 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

The first boot log showing Certimate initialising a fresh data directory and rotating the administrator password, the enabled systemd units, the first boot sentinel and the healthy API endpoint

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 cloudimg with 24/7 support. For deployment help or questions about Certimate on Azure, contact the cloudimg support team listed on your Azure Marketplace offer.