XiPKI

• Sign in to the Azure portal.
• Search the Marketplace for XiPKI on Ubuntu 24.04 LTS by SecureAnyCloud and select Create.
• Choose your subscription, resource group and region.
• Set the VM size. Standard_B2s (2 vCPU, 4 GB) is the recommended minimum, and the JVM heap sizes in this image are tuned for it.
• Set the authentication type to SSH public key, with username azureuser.
• Under Inbound port rules, allow SSH (22) only. Do not open the PKI ports yet.
• Select Review + create, then Create.

First boot generates your certificate authority and then proves that it works before reporting ready. Allow two to three minutes after the VM reaches Running before you connect.

az group create --name xipki-rg --location eastus
az vm image terms accept --urn sac1647283583153:xipki-ubuntu-24-04:default:latest
az vm create \
  --resource-group xipki-rg \
  --name xipki-vm \
  --image sac1647283583153:xipki-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --storage-sku StandardSSD_LRS \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open SSH only. Leave the PKI ports closed:

az vm open-port --resource-group xipki-rg --name xipki-vm --port 22 --priority 1001

ssh azureuser@<vm-ip>

The message of the day shows your certificate authority and its SHA-256 fingerprint:

XiPKI 6.7.0 on Ubuntu 24.04 (sac Azure Marketplace image) Certificate authority: CN=xipki-vm Issuing CA CA SHA-256: 31:D6:0D:32:23:87:98:93:59:19:8A:15:16:45:D7:4E:... Services: systemctl status xipki-ca xipki-gateway xipki-ocsp Prove the CA:
sudo /usr/local/sbin/xipki-pki-roundtrip.sh CA details:
sudo cat /root/xipki-credentials.txt All PKI ports are loopback-only. See the guide before exposing them.

systemctl is-active postgresql xipki-ca xipki-gateway xipki-ocsp

Expected output:

active active active active

sudo ss -ltnp | grep -E ':(8080|8082|8444|8445|5432)\b'

Every local address in the output is a loopback address. Nothing is bound to a routable interface:

LISTEN 0 100 127.0.0.1:5432 0.0.0.0:* LISTEN 0 100 [::ffff:127.0.0.1]:8080 *:* LISTEN 0 100 [::ffff:127.0.0.1]:8082 *:* LISTEN 0 100 [::ffff:127.0.0.1]:8444 *:* LISTEN 0 100 [::ffff:127.0.0.1]:8445 *:*

[::ffff:127.0.0.1] is the IPv4-mapped IPv6 form of 127.0.0.1. This is how the Tomcat connector binds loopback.

Only root can read the credentials file. It holds your certificate authority details, the enrolment credential and the database password.

sudo cat /root/xipki-credentials.txt

It contains, among other entries:

xipki.ca.name=sacca xipki.ca.alias=sac xipki.ca.subject=C=GB,O=sac,CN=xipki-vm Issuing CA xipki.ca.fingerprint.sha256=31:D6:0D:32:... xipki.gateway.requestor.user=sac xipki.gateway.requestor.password=<GATEWAY_PASSWORD> xipki.gateway.rest.url=https://127.0.0.1:8445/gw/rest/sac xipki.ocsp.url=http://127.0.0.1:8080/ocsp/

Confirm the file is protected:

sudo stat -c '%a %U:%G' /root/xipki-credentials.txt

600 root:root

Run the self test to confirm that your PKI works end to end. The test obtains your certificate authority certificate from the CA server's management interface. It enrols a fresh certificate signing request through the gateway, then cryptographically verifies that the returned certificate chains to your certificate authority. It also confirms that an unauthenticated request is refused and that an unrelated certificate authority cannot verify the certificate.

sudo /usr/local/sbin/xipki-pki-roundtrip.sh

OK ca=sacca ca_sha256=31:D6:0D:32:23:87:98:93:59:19:8A:15:16:45:D7:4E:A6:51:FA:2E:EE:6C:4F:84:B0:F9:33:F4:0F:58:BE:B6 issued_cn=rt-a-20260719215726-35841.pki.sac.internal unauth_http=401 wrongpw_http=401 ocsp=good+revoked

The output line tells you four things. A certificate was issued and verified against your certificate authority. An unauthenticated enrolment attempt was refused with HTTP 401, and an attempt with the wrong password was also refused. The OCSP responder reported good for a live certificate and revoked for one that had been revoked.

Read your enrolment credential and the gateway URL:

sudo grep -E '^xipki.gateway' /root/xipki-credentials.txt

Generate a key and a certificate signing request. The tls profile requires the common name to be a fully qualified domain name:

cd /tmp openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout myservice.key -out myservice.csr -outform DER \
  -subj "/C=GB/O=sac/CN=myservice.example.internal"

Enrol the request. The gateway serves HTTPS with a certificate issued by your own certificate authority. For that reason, curl is pointed at the certificate authority certificate instead of the system trust store:

sudo bash -c ' GW=$(grep "^xipki.gateway.rest.url=" /root/xipki-credentials.txt | cut -d= -f2-) U=$(grep "^xipki.gateway.requestor.user=" /root/xipki-credentials.txt | cut -d= -f2-) P=$(grep "^xipki.gateway.requestor.password=" /root/xipki-credentials.txt | cut -d= -f2-) curl -sS -k -o /tmp/myservice.der -w "HTTP %{http_code}\n" \
  --data-binary @/tmp/myservice.csr \
  -H "Content-Type: application/pkcs10" \
  -u "$U:$P" \
  "$GW/enroll-cert?profile=tls" '

HTTP 200

Convert and inspect the certificate you were issued:

openssl x509 -inform der -in /tmp/myservice.der -out /tmp/myservice.pem
openssl x509 -in /tmp/myservice.pem -noout -subject -issuer -dates -nameopt RFC2253

subject=CN=myservice.example.internal,O=sac,C=GB issuer=CN=xipki-vm Issuing CA,O=sac,C=GB notBefore=Jul 19 22:43:38 2026 GMT notAfter=Jul 19 22:43:38 2031 GMT

Fetch the certificate authority certificate from the gateway's public endpoint, then verify the chain:

sudo bash -c ' GW=$(grep "^xipki.gateway.rest.url=" /root/xipki-credentials.txt | cut -d= -f2-) curl -sS -k -o /tmp/ca.der "$GW/cacert" ' openssl x509 -inform der -in /tmp/ca.der -out /tmp/ca.pem openssl verify -CAfile /tmp/ca.pem /tmp/myservice.pem

/tmp/myservice.pem: OK

The cacert endpoint is deliberately public. A certificate authority certificate contains no secret, and relying parties need it to verify the certificates you issue.

Check the status of the certificate while it is still valid:

openssl ocsp -CAfile /tmp/ca.pem -issuer /tmp/ca.pem -cert /tmp/myservice.pem \
  -url http://127.0.0.1:8080/ocsp/ -noverify 2>/dev/null | head -2

/tmp/myservice.pem: good

Revoke the certificate. Revocation requires the SHA-1 fingerprint of the issuing certificate authority, as well as the certificate serial number:

sudo bash -c ' GW=$(grep "^xipki.gateway.rest.url=" /root/xipki-credentials.txt | cut -d= -f2-) U=$(grep "^xipki.gateway.requestor.user=" /root/xipki-credentials.txt | cut -d= -f2-) P=$(grep "^xipki.gateway.requestor.password=" /root/xipki-credentials.txt | cut -d= -f2-) SER=$(openssl x509 -in /tmp/myservice.pem -noout -serial | cut -d= -f2) CASHA1=$(openssl x509 -in /tmp/ca.pem -noout -fingerprint -sha1 | cut -d= -f2 | tr -d ":") curl -sS -k -o /dev/null -w "HTTP %{http_code}\n" -u "$U:$P" \
  "$GW/revoke-cert?ca-sha1=${CASHA1}&serial-number=0x${SER}&reason=KEY_COMPROMISE" '

HTTP 200

Check the status again:

openssl ocsp -CAfile /tmp/ca.pem -issuer /tmp/ca.pem -cert /tmp/myservice.pem \
  -url http://127.0.0.1:8080/ocsp/ -noverify 2>/dev/null | head -2

/tmp/myservice.pem: revoked

The management CLI runs as the xipki service user. That user owns the management client certificate the CLI authenticates with.

sudo -u xipki bash -c 'cd /opt/xipki/run/xipki-setup/xipki-mgmt-cli && printf "ca-info sacca\n" | ./bin/xipki' | head -30

Start the CLI interactively to explore:

sudo -u xipki bash -c 'cd /opt/xipki/run/xipki-setup/xipki-mgmt-cli && ./bin/xipki'

Type help for the full command list and exit to leave. Useful commands include ca-info, caprofile-info, careq-info and cacert.

Your certificate authority offers these certificate profiles: tls, tls-c, smime, ocsp, scep, tls-sm2 and tls-sm2-enc. Pass the profile you want as the profile query parameter when you enrol.

Every PKI port is loopback only in the shipped image. Expose ports deliberately, and never expose the certificate authority management port.

Never expose port 8444. That port is the certificate authority management interface. Anyone who reaches it with a valid management client certificate can reconfigure your certificate authority.

The OCSP responder (port 8080) is the usual first port to expose. OCSP responses are signed and are meant to be publicly readable, so that relying parties can check certificate status. To expose it, edit the OCSP Tomcat connector and open the port:

sudo sed -i 's|<Connector address="127.0.0.1" port="8080"|<Connector address="0.0.0.0" port="8080"|' \
  /opt/xipki/run/ocsp-tomcat/conf/server.xml
sudo systemctl restart xipki-ocsp

Then open the port in the VM's network security group:

az vm open-port --resource-group xipki-rg --name xipki-vm --port 8080 --priority 1010

For the enrolment gateway (port 8445), put a reverse proxy in front of it instead of exposing Tomcat directly. This gives you control of TLS termination, rate limiting and access logging. Restrict the source addresses in your network security group to the hosts that need to enrol. Prefer client certificate authentication over the password requestor for anything beyond testing.

Certificates issued by this certificate authority already carry an OCSP URL that points at this VM's address. Once port 8080 is open, relying parties can check status without further configuration.