docs: review security documentation in all seven translations

web/messages/en/docs/security/fail2ban.json

@@ -91,7 +91,7 @@
   },
   "hardening": {
     "heading": "SSH hardening: MaxAuthTries",
-    "intro": "Lynis control <strong>SSH-7408</strong> recommends <code>MaxAuthTries 3</code> in <code>sshd_config</code>. With Fail2Ban's <code>maxretry = 2</code> on the SSH jail, a malicious client never reaches three attempts anyway — but the explicit setting satisfies the audit and adds defence in depth (e.g. if Fail2Ban is stopped for maintenance).",
+    "intro": "Lynis control <strong>SSH-7408</strong> recommends <code>MaxAuthTries 3</code> in <code>sshd_config</code>. The SSH jail uses <code>maxretry = 2</code> to trigger a ban after repeated failures, while MaxAuthTries limits attempts within a connection. The explicit SSH setting adds defence in depth, including when Fail2Ban is stopped for maintenance.",
     "installerIntro": "The installer:",
     "items": [
       "Reads the current <code>MaxAuthTries</code> value (or defaults to 6 if absent).",
@@ -125,7 +125,7 @@
   "troubleshoot": {
     "heading": "Troubleshooting",
     "neverBansTitle": "Fail2Ban runs but never bans anything",
-    "neverBansBody": "Check the auth log files actually receive entries: <code>tail -f /var/log/ssh-auth.log</code> and try a wrong-password SSH attempt from a different machine. If the log stays empty, the logger service is not running: <code>systemctl status ssh-auth-logger.service</code>. If it's active but the log is empty, check that the journald drop-in took effect: <code>journalctl --dump-catalog | head</code> — events at <em>info</em> level should be visible.",
+    "neverBansBody": "Check that <code>tail -f /var/log/ssh-auth.log</code> receives an entry after a wrong-password SSH attempt from another machine. If it stays empty, inspect <code>systemctl status ssh-auth-logger.service</code>. If the logger is active, inspect recent SSH events with <code>journalctl -u ssh.service -n 50 --no-pager -p info</code> and check whether the journald drop-in permits the <em>info</em> level.",
     "monitorEmptyTitle": "ProxMenux Monitor jail has no entries even after failed logins",
     "monitorEmptyBody": "The <code>[proxmenux]</code> jail reads <code>/var/log/proxmenux-auth.log</code>, which is written by the ProxMenux Monitor Flask app — not by a journald logger. If you don't run the Monitor, the file stays empty and the jail never fires. That's expected; the jail config is harmless. If you do run the Monitor and the log is empty, check the Flask logging config.",
     "selfBanTitle": "I banned myself",

web/messages/en/docs/security/ssl-letsencrypt.json

@@ -28,7 +28,7 @@
       "items": [
         "Auto-detected — no path to type",
         "Picks the ACME-uploaded cert if present, falls back to the self-signed default",
-        "Renewal happens through Proxmox; the Monitor follows automatically on next start"
+        "Proxmox handles renewal; the Monitor validates and loads it on the next new TLS connection"
       ]
     },
     "custom": {
@@ -143,7 +143,7 @@
   },
   "trustCa": {
     "heading": "Trust the Proxmox self-signed CA",
-    "intro1Rich": "If you prefer to keep the default Proxmox-generated certificate (no ACME), you can stop the browser warning by importing the cluster's root CA into the OS or browser trust store. The Monitor will keep auto-detecting the same <code>/etc/pve/local/pveproxy-ssl.pem</code>; the only thing that changes is that the device viewing the dashboard now recognises the issuer.",
+    "intro1Rich": "To keep the default Proxmox-generated certificate without ACME, import the cluster root CA into the OS or browser trust store. The Monitor detects <code>/etc/pve/local/pve-ssl.pem</code> as the fallback certificate. This makes the client trust its issuer; the URL must still match a name in the certificate.",
     "intro2Rich": "The CA file lives at <code>/etc/pve/pve-root-ca.pem</code> on every node. In a cluster the path is on the shared <code>pmxcfs</code> filesystem so all nodes share the same root, and a single import covers the whole datacenter. Copy it to your machine:",
     "code": "scp root@<your-host>:/etc/pve/pve-root-ca.pem ./pve-root-ca.pem",
     "thenImport": "Then import it on the client side:",