How certree handles untrusted input and what it does not protect against.

If you discover a security vulnerability, please report it through GitHub Security Advisories. Do not open a public issue for security reports.

certree is an analysis and visualization tool. It processes untrusted certificate data from files, remote TLS connections, HTTP URLs, and stdin. Its security design focuses on safe handling of that untrusted input.

SSRF (Server-Side Request Forgery). When fetching certificates from URLs (AIA, CRL, OCSP, or --batch sources), certree blocks requests to private and loopback IP ranges by default. DNS resolution happens inside the transport's DialContext hook, preventing DNS rebinding attacks. The --allow-private-networks flag disables this protection for enterprise environments where internal PKI endpoints are expected.

Input size limits. PEM parsing, file reads, and batch source files are bounded by hard size limits to prevent memory exhaustion from malicious input. Individual source lines in batch files are length-limited and validated for shell metacharacters and path traversal.

Redirect following. HTTP redirects are capped at a fixed limit to prevent redirect loops. Cross-scheme redirects from HTTPS to HTTP are blocked to prevent transport-security downgrade attacks. HTTP URLs are automatically upgraded to HTTPS before fetching.

TLS connection safety. Remote connections use Go's standard crypto/tls with system-default cipher suites and protocol versions. No insecure TLS configurations are exposed.

Private key handling. When parsing PEM data, certree silently skips private key blocks. Private keys are never loaded, stored, or logged.

Production TLS verification. certree is an analysis tool, not a TLS library. Do not use certree's validation results to make trust decisions in production systems. Use Go's crypto/tls or your platform's TLS stack for that.

Trust store integrity. certree reads the system trust store and optional custom bundles. It does not verify that the trust store itself has not been tampered with. Trust store integrity is the responsibility of the operating system.

Denial of service via CPU. Parsing deeply nested or intentionally malformed ASN.1 structures may consume significant CPU. certree relies on Go's crypto/x509 parser, which handles most edge cases, but adversarial inputs may still cause slow parsing. Use timeouts (--connect-timeout) and context cancellation for untrusted sources.

certree uses a minimal set of dependencies. Security-relevant ones:

• golang.org/x/crypto -- OCSP request building and PKCS#12 parsing
• crypto/tls, crypto/x509 (stdlib) -- TLS connections and certificate parsing

All dependencies are tracked in go.mod with checksums in go.sum. Dependabot keeps dependencies updated automatically.

All release binaries are checksummed (SHA-256) and signed with cosign using keyless OIDC-based signing. Each archive includes an SPDX SBOM generated by syft.

Verify a release:

sha256sum -c checksums.txt
cosign verify-blob --certificate checksums.txt.pem --signature checksums.txt.sig checksums.txt

certree never logs private keys, passwords, or personally identifiable information. Certificate metadata (subject names, serial numbers, fingerprints) appears in logs at debug and info levels. OCSP and CRL endpoint URLs appear in debug logs during revocation checking.

See also: Architecture, Contributing, CLI Reference.