@cryptotaxi247 / netdata-1 / commits / 9b5e0156c

docs: Add guidance on obtaining TLS certificates for production use (#22037)

* docs: Add section on obtaining TLS certificates for production use Add comprehensive guidance on certificate acquisition options for Netdata TLS configuration, including Let's Encrypt, commercial CAs, and internal CAs. Provides practical, actionable information focused on Netdata-specific certificate requirements. * Update src/web/server/README.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * docs: Mention full chain cert requirement and ACME file mapping Agent-Logs-Url: https://github.com/netdata/netdata/sessions/79e31843-d80e-4264-a716-a2182162c0a8 Co-authored-by: Ancairon <70198089+Ancairon@users.noreply.github.com> --------- Co-authored-by: nedi-app[bot] <bot@netdata.cloud> Co-authored-by: Fotis Voutsas <fotis@netdata.cloud> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Ancairon <70198089+Ancairon@users.noreply.github.com>

nedi-app[bot] committed Apr 6, 2026 at 08:53 UTC 9b5e0156c23217c07d963b0e30ac9c943fac5359
1 file changed +41
src/web/server/README.md
+41
@@ -249,6 +249,47 @@ openssl speed rsa2048 rsa4096
249
250 :::
251
252 +### Obtaining TLS Certificates
253 +
254 +Self-signed certificates are suitable for testing and development environments. For production deployments, you should obtain certificates from a trusted Certificate Authority (CA) to ensure proper security and avoid browser warnings.
255 +
256 +#### Certificate Acquisition Options
257 +
258 +1. **Let's Encrypt (Recommended for public-facing instances)**
259 + - Free, automated certificate authority
260 + - For HTTP-01/TLS-ALPN-01, requires public DNS plus inbound ports 80/443, or use DNS-01 if those ports aren’t available
261 + - Certificates auto-renew with proper configuration
262 + - Install using [Certbot](https://certbot.eff.org/) or other ACME clients
263 + - Certificates are issued in PEM format, compatible with Netdata
264 +
265 +2. **Commercial Certificate Authorities**
266 + - Paid certificates from providers like DigiCert, Comodo, or GlobalSign
267 + - Various validation levels (DV, OV, EV) available
268 + - Suitable for organizations requiring extended validation
269 + - Ensure certificates are provided in PEM format or convert them
270 +
271 +3. **Internal Certificate Authorities**
272 + - For enterprise environments with private PKI infrastructure
273 + - Allows complete control over certificate lifecycle
274 + - See [Using custom CA certificates with Netdata](/docs/netdata-agent/configuration/using-custom-ca-certificates-with-netdata.md) for configuration details
275 + - Requires clients to trust your internal CA
276 +
277 +#### Netdata Certificate Requirements
278 +
279 +Regardless of the source, ensure your certificates meet these requirements:
280 +
281 +- **Format**: PEM format (most common format, used by Let's Encrypt and compatible with OpenSSL)
282 +- **Full chain**: For CA-issued certificates, `ssl certificate` must include all intermediate certificates to avoid browser warnings. Let's Encrypt issues `fullchain.pem` (certificate + intermediates) and `privkey.pem` (private key) — use these directly.
283 +- **Location**: Place certificates in `/etc/netdata/ssl/` or another secure directory
284 +- **Permissions**: Certificate and key files must be readable by the `netdata` user
285 +- **Paths**: Configure the paths in `netdata.conf`:
286 +
287 +```text
288 +[web]
289 + ssl key = /etc/netdata/ssl/privkey.pem
290 + ssl certificate = /etc/netdata/ssl/fullchain.pem
291 +```
292 +
293 </details>
294
295 <details>