Certificate-based VPN authentication rests on the client holding a private key the gateway trusts, and on the gateway validating the certificate correctly, both of which are attackable. Theft: a client certificate and its private key are exported from the Windows/macOS certificate store, lifted from a VPN client's configuration or profile, or recovered from backups and images; with them, the attacker authenticates as that client. Validation bypass: a gateway that does not properly check the issuing CA, validity window, revocation, or the certificate-to-identity binding can be satisfied with a self-signed, expired, or otherwise illegitimate certificate.
# steal a client certificate + key from a client you have access to
# Windows: export from the cert store (if marked exportable) or dump with mimikatz/crypto APIs
# files: VPN client profiles, .p12/.pfx, .ovpn embedded certs, backups
openssl pkcs12 -in client.pfx -nodes -out client.pem # extract cert+key
# reuse it to authenticate the VPN
openvpn --config client.ovpn --cert client.crt --key client.key
# validation bypass: present a self-signed/wrong-CA cert where the gateway fails to verify
Exploitation notes#
- Theft is the common path: hunt for
.pfx/.p12,.ovpnwith embedded keys, and client profiles on compromised endpoints, in backups, and in images; an exportable private key authenticates as its owner. - The certificate often maps to a specific user/device identity on the gateway, so a stolen cert may also satisfy device-posture checks, not just authentication.
- Validation-bypass flaws (ignoring the CA, validity, revocation, or the identity binding) let an attacker-generated certificate authenticate; test whether the gateway accepts a self-signed or wrong-CA client cert.
- Combine with password brute force where the VPN uses certificate plus password; a stolen cert handles one factor.