What this does
Parses an OpenVPN .ovpn client configuration file, entirely in your browser, and flags the specific directive choices that quietly weaken it: a deprecated cipher like BF-CBC, a legacy digest like MD5 or SHA1, missing tls-auth/tls-crypt, compression left enabled (the VORACLE attack), a missing remote-cert-tls server check, and disabled key renegotiation.
Why a config that connects fine can still be weaker than it looks
OpenVPN has been around since 2001, and its defaults have shifted considerably since — many of the directive choices this tool flags were once completely normal and still work today without any error or warning from OpenVPN itself. A config generated years ago, or copied from an old tutorial, connects and passes traffic exactly like a hardened one would; the difference only shows up in what happens if it's compromised or attacked, not in whether it works day to day.
FAQ
Why does a missing tls-auth or tls-crypt only get a medium severity?
It doesn't break confidentiality on its own — TLS still protects the actual tunnel. What it loses is a layer that authenticates the control channel with an HMAC before the TLS handshake even starts, which is what lets a hardened server silently drop unauthenticated packets instead of responding to them at all. Without it, the server still responds to any TCP/UDP probe on its port, making it visible to port scanners and certain denial-of-service attempts that a keyed HMAC would otherwise filter out for free.
Is comp-lzo always a VORACLE risk, even on a trusted network?
The VORACLE attack requires an attacker able to inject chosen plaintext into the compressed stream and observe the resulting ciphertext size — realistic when a VPN carries a victim's web browsing (the classic scenario is a malicious page causing the browser to send attacker-chosen data over the tunnel). If the tunnel only ever carries traffic the client fully controls, the practical risk is lower, but the fix (disable compression, or migrate off it) costs nothing and removes the question entirely.
Does this tool check the actual PEM certificate or key content?
No — it only detects whether a <key> block is embedded in the file at all, as a reminder to treat that file as a credential. It doesn't parse, validate, or check the strength of the certificate or key material itself; that would require full X.509/PEM parsing, a different scope than a configuration-directive audit.
Why is auth sha1 flagged but not treated as broken like MD5?
SHA1 has known theoretical weaknesses and is being phased out across the industry, but breaking it for the specific HMAC construction OpenVPN uses is far harder than the collision attacks that broke SHA1 for signatures — it's dated, not broken. MD5 is flagged more severely because it's cryptographically broken outright and has been for years.
Is this tool meant for server configs too, or just client .ovpn files?
It's scoped to client configuration files — the ones ending in .ovpn that get distributed to end users. A server config uses different directives entirely (server, push, client-config-dir), and checking "no remote directive" the way this tool does would be the wrong check for a server, which listens rather than connects out.
Try it yourself
For the full reasoning behind each of these settings, see OpenVPN Security Best Practices. Setting up WireGuard instead? WireGuard Config Validator covers the same ground for a .conf file.