A certificate proves a file was copied correctly. It says nothing about who is sitting at the keyboard. Switching OpenVPN to username and password authentication is the change that turns a floating key into a personal login.
This is step one of the video's upgrade, and it is worth understanding what it actually changes. In a default setup the client config is the identity: present the file, and you are in. With username and password authentication enabled in the server settings, the file becomes just the address and the lock shape - the person must also prove who they are, every single connection. Here is what that means in practice, and the order to do it in so nobody gets locked out.
Be precise about the weakness, because it decides the fix. A config-only login proves the connecting machine holds a file your server once issued. It does not prove the machine is still yours, the person is still employed, or the file was not copied to a second machine last year. Stolen laptops, emailed configs and forgotten copies all pass this test perfectly. That is not a bug in OpenVPN - it is simply all that a file can say. Asking for a username and password adds the one thing the file cannot carry: knowledge held by a person.
The change itself, as shown in the video, takes a minute: log in to the firewall admin interface, open OpenVPN, open the Server settings, select username and password authentication, and Save. Two disciplines make it safe. First, do it when the local directory users from the next step already exist, or create them in the same sitting. Second, change it during a window when you can help the first users reconnect - the next existing session may keep running, but the next new connection will ask for credentials people do not have yet if you skipped the user creation.
After the change, the OpenVPN client asks for a username and password at connect time, where before it connected silently. Warn people in advance or your phone will do it for you. Their config file still matters - it points at your server and carries the certificates - but it no longer works alone. This is also the moment the shared office config quietly dies as a master key: it now needs a person's password too, which is exactly why the next step gives every person their own account instead of letting them all type the same one.
The honest downside of this step: you have added passwords to the world, and passwords get reused, written down and guessed. Keep them long, make each one unique to the VPN, and never let the VPN password be the email password. The full answer to weak passwords is not a stricter lecture - it is the MFA step from the video, which makes a guessed or leaked password useless on its own. Username and password authentication is the necessary foundation; the one time code is what makes the foundation worth standing on.
The exact clicks in the server settings, plus the local directory and MFA steps that complete the change.
▶️ Watch Full VideoNew connections will ask for a username and password, so create the local directory accounts in the same session, before or immediately after saving, and warn users the same day. Anyone already connected usually keeps their session until they reconnect.
No - the file still carries the server address and certificates and is still required. It just stops being sufficient on its own, which is the entire point of the upgrade.
Still do the MFA step. A password can be guessed, reused or phished; the authenticator code is what makes a leaked password worthless by itself. The video treats password authentication and MFA as one upgrade, in that order.