Certificate automation (Digicert and LetsEncrypt)

[G0nz0uk]

Hello,

With regards to Digicert automation then yes I'd love some help Tom.

https://docs.digicert.com/en/trust-lifecycle-manager/enroll-and-manage-certificates/digicert-trust-assistant/digicert-trust-assistant-admin-guide/post-processing-actions-and-scripts/custom-scripts.html

https://github.com/digicert/product-solutions

I built 2 test Ubunut VMs 1 with Apache and the other with NGinx and as these are well know applications when Digicert scans it (same for LetsEncypt) they detect these applications as they run their post scripts against them that are in the links above. When the certificate is automatically renewed it installs it and restarts the service.

Digicert by defaults locates the certificates which is good start, but doesn't know your MCP server so doesn't know what to do, we can look at the examples in the link to build one I guess for your MCP?

Thanks

[hermanekt]

Hi @G0nz0uk - thanks for the links, that gives a clear shape for what a useful integration would look like.

Quick triage of what already works in v1.24 and what's still missing:

Already supported in v1.24:

• Hot-reload of TLS material - Settings → TLS & Network Security accepts tls_cert_file / tls_key_file paths. After cert renewal, hitting the "Restart needed" banner reloads the new files via systemd (or the docker container restart). No code change needed for that part.
• Settings UI uploads for cert + key (max 100 KB, stored 0600). The renewal scripts don't strictly need the UI - dropping new PEMs in place via filesystem works just as well.

What we'd add for proper Digicert / Let's Encrypt automation:

A small set of post-renewal hook scripts in deploy/cert-hooks/ that:

1. digicert-post-install.sh - matches the contract from the Digicert custom-scripts docs you linked. Symlinks the new cert+key into the tls_cert_file / tls_key_file paths from config.toml, then sends SIGTERM to the MCP service (systemd or PID 1 in container).

2. letsencrypt-deploy-hook.sh - certbot deploy-hook that does the same plumbing. Picks up RENEWED_LINEAGE from certbot's environment.

3. Detection - the install script could probe for digicert-trust-assistant or certbot and offer to wire the right hook.

The Apache / Nginx detection trick from the Digicert docs works well here too - we can ship a digicert-trust-assistant plugin contribution that recognizes zabbix-mcp-server (by service name + open port + JSON-RPC probe).

Realistically this is half a day of script-writing plus a CI pass on AlmaLinux + Ubuntu (the two distros the existing installer supports). I'll open a tracking issue and slot it in for v1.25 unless you want to draft the scripts and PR them - either path works for me.

(For v1.24 itself the connectivity bug from #19 is fixed - separate thread.)

[hermanekt]

Quick update on this thread - v1.29 ships a wizard step that addresses the Let's Encrypt half of the original ask without us shipping certbot integration ourselves.

The Client Wizard (/wizard) gained a Step 5: reverse-proxy / TLS that generates a paste-ready config block from your [server].public_url for whichever HTTP frontend you run:

• Caddy - one-line reverse_proxy directive; Caddy auto-fetches and renews Let's Encrypt certs on first request, no extra tooling.
• Nginx - 443 server block with proxy_buffering off (needed for SSE), 600s read timeout, X-Forwarded-Proto/For headers, and a 80->443 redirect block. Pair with certbot --nginx for renewal.
• Apache - VirtualHost with mod_ssl + mod_proxy_http + ProxyTimeout 600 + RequestHeader X-Forwarded-Proto, plus a 80->443 redirect VirtualHost. Pair with certbot --apache.

Walkthrough: https://github.com/initMAX/zabbix-mcp-server/blob/main/docs/OAUTH.md#do-i-need-a-tls-certificate

For Digicert / commercial CAs, the same vhosts work as long as you point SSLCertificateFile / ssl_certificate / Caddy's tls /path at the cert files; renewal is whatever script your CA gives you. The MCP server itself supports hot-reload of [server].tls_cert_file via Settings -> TLS in the admin portal, so a renewed file does NOT require a service restart.

Full certbot-as-a-built-in is still not on our roadmap (it would duplicate what Caddy / nginx + certbot already solve well), but the wizard step gets you to the same place in a couple of clicks.

[hermanekt]

Heads-up: the Let's Encrypt half of this discussion ships in v1.30 (just released): https://github.com/initMAX/zabbix-mcp-server/releases/tag/v1.30

sudo ./deploy/install.sh request-tls --hostname mcp.example.com --email you@example.com

Wraps certbot certonly (auto-detects standalone vs webroot), symlinks fullchain + privkey into /etc/zabbix-mcp/tls/, idempotently writes tls_cert_file + tls_key_file into config.toml, installs a deploy hook that re-applies privkey perms (0440 root:zabbix-mcp) and reloads the service after each renewal, and enables certbot.timer. Re-runnable any time you rotate or add a hostname. Live-tested on a Rocky 9 deployment.

Leaving this thread open for the DigiCert / commercial-CA half - that flow is different (CSR generation + manual upload + ICA bundle), so if anyone needs it please add a comment with the specific workflow you'd like (manual upload via the admin portal? CSR generator? request-tls --provider digicert?). We'll prioritise based on actual demand.

[G0nz0uk]

We will definitely need to use the Digicert method. I'm experienced enough in their platform yet as we have only just got it, I think it would similar to LetsEncrypt though as an agent sits on the server and talks back to their cloud portal. Their platform finds the location of the currently installed certs which is good, but can't detect the application as it's not a common one. We tried to click renew certificate which failed so we have option a support ticket with them.