If possibile, it is suggested to request an additional authentication in addition to a client certificate.
This could protect you in case of certificate loss.
Additional authentication could be configured server side in two ways:

OpenVPN is commonly used to route all traffic or only some subnets through the VPN tunnel. This is
implemented adding wide scope routing rules.
A rogue DHCP server able to push more specific routes could be able to take precedence on the routing
table and route your traffic outside the VPN.
To prevent this kind of attacks it is suggested to configure your DHCP client to ignore classless static
routes.
A rogue DHCP couls also push a subnet mask for an extremely large subnet, so all the traffic could be
routed on the local network and not in the VPN.
This issue has not an easy solution, it depends by your OS, for example in Linux you can use advanced routing
and multiple routing table (see https://www.agwa.name/blog/post/hardening_openvpn_for_def_con).

You know, IPv6 could be a security beast. Unless you are using IPv6 in your OpenVPN tunnerl, then all IPv6 traffic from your client will bypass the VPN and egress over the local network.
It is suggested to disable IPv6 support in your OS if you are not using it.

The OpenVPN Management interface allows OpenVPN to be remotely administered.
It is suggested to disable or restrict to localhost (or local trusted clients) the management interface.
Edit the server configuration file and comment the management option or make sure it is only accessible
via localhost:

When you are using a VPN tunnel, you should use only a trusted DNS server.
If an attacker is able to push a rogue DNS server it is a game over for you because he could redirect all
your traffic outside the VPN.
It should take care of your configured DNS servers, unfortunately how DHCP clients manage pushed DNS servers
depends by operating systems. Some systems do it incredibly poorly and it is possible to change your DNS
server, by pushing it via DHCP, after the VPN tunnel startup.
It is suggested to pin your DNS servers to be suere you are always using the right one.

Certificates should not be shared and each VPN client must have its unique certificate.
Is is suggested to enforce it disabling the duplicate-cn in the server configuration file, if present,
commenting or deleting it, as follows:

If your connection is interrupted and OpenVPN is trying to reconnect, in the meanwhile, traffic is passing
by your default route, bypassing your VPN.
It is suggested to configure OpenVPN to keep the device open and to hold traffic until the connection
is restored, add the following option to the configuration file:

OpenVPN authentication, in most cases, is based on PKI and X.509 certificates. Practicing secure PKI management
is mandatory to safeguard, also, OpenVPN.
It is suggested to follow best practices for secure PKI management, for example:

Secure management of CA PKI.

Generate private keys on the target system and never transport them.

Never share private keys.

Use certificate passwords if possibile and use a secure password policy.

The –tls-auth option uses a static pre-shared key (PSK) shared among all connected peers.
This is an extra layer of protection to the TLS channel by requiring that incoming connections are correctly HMAC
signed by the PSK key.
This feature could protect your VPN server by DoS attacks aimed to load your CPU load, by port scanning avoiding
service fingerprinting, and act as second line of defense for SSL library vulnerabilities.
Generate a PSK with the command:

openvpn--genkey--secretta.key

Add the following line to your server configuration:

tls-authta.key

Add the following line to your server configuration:

tls-authta.key

Beware, the –tls-auth key is changed, it must be changed on all peers at the same time, so it could
potentially lead to a network management horror story. It is suggested to use it with care.