What's new

Solved No Certificate Issue with ASUS OpenVPN Config File

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

you might have to add BOTH duplicate-cn and username-as-common-name directives to the server custom config field.
1. I added to the file /etc/openvpn/server1/config.ovpn
Code:
# Custom Configuration
duplicate-cn
username-as-common-name
2. OpenVPN server off.
3. OpenVPN server on.
4. cat /tmp/etc/openvpn/server1/config.ovpn - I made sure the options are added.
5. Exported client1.ovpn to the client computer
6. Added to client1.ovpn
auth-user-pass auth
cipher AES-128-CBC
7. sudo openvpn client1.ovpn

The first client connects. After one second, the second client connects, the first client disconnects. Then the first client connects, the second client disconnects. And so in a circle.

Have I done everything right?
 
Ideally, it would be better to actually create client-specific certs and keys anytime you're using Manage Client Specific Options (and eliminate username/password completely).
How to do it?
 
 
1. I added to the file /etc/openvpn/server1/config.ovpn
Code:
# Custom Configuration
duplicate-cn
username-as-common-name
2. OpenVPN server off.
3. OpenVPN server on.
4. cat /tmp/etc/openvpn/server1/config.ovpn - I made sure the options are added.
5. Exported client1.ovpn to the client computer
6. Added to client1.ovpn
auth-user-pass auth
cipher AES-128-CBC
7. sudo openvpn client1.ovpn

The first client connects. After one second, the second client connects, the first client disconnects. Then the first client connects, the second client disconnects. And so in a circle.

Have I done everything right?

Seems to me it should have worked, but it may be something in OpenVPN itself that doesn't like the combination.

To restate, when you do NOT have Manage Client-Specific Options enabled, you shouldn't have this problem (and you might want to verify that by temporarily disabling it). And that's because the router inserts the duplicate-cn directive into the server's config file. IOW, all clients are allowed to share the one client cert+key, and all at the same time.

But once you enable Manage Client-Specific Options, things change. Now the router does NOT include the duplicate-cn directive. And that's because Manage Client-Specific Options implies that each client will be distinguished from the others based on its unique client cert+key.

The plot thickens when it comes to the username/password option. If you choose to ONLY use username/password, then there are no client cert+keys AT ALL, and users are distinguished from one another based solely on the username. The router does this by adding the username-as-common-name directive to the server's config file.

The worst situation is your own. If you have Manage Client-Specific Options enabled, and use BOTH the one client cert and username/password for authentication, the router adds neither the duplicate-cn nor username-as-common-name directives to the server's config file. And so you're right back to the original problem of only being allowed access by one client at a time.

That's why I thought that by adding those two directives back, it would work. The duplicate-cn directive should allow concurrent access by multiple users w/ the same client cert, and the username-as-common-name should allow the username to be used in place of the common-name in Manage Client-Specific Options. But apparently that's not the case, and I don't know why at this point.

The other option would be to use username/password ONLY (if only as a temporary fix until you can generate per-client certs and keys).

As I said before, you wouldn't normally configure the OpenVPN server in this fashion anyway. When using Manage Client-Specific Options, you would more normally create client-specific certs and keys, and eliminate username/passwords too (including the latter would be like setting up public/private keypairs w/ SSH, and still requiring passwords; it makes no sense).
 
Thanks for the help! I will investigate further.

Offtopic.
When I copy the keys from the client to the router (ssh-copy-id), the keys live until the first reboot. How to fix it?
 
Thanks for the help! I will investigate further.

Offtopic.
When I copy the keys from the client to the router (ssh-copy-id), the keys live until the first reboot. How to fix it?

For the purposes of SSH, you have to store the authorized keys using the GUI, in the SSH section of the Administration->System page. Using ssh-copy-id only copies it to the root folder of the router (/tmp/home/root/.ssh/authorized_keys), which is the ram drive. By using the GUI, it will store the contents of that file to nvram, then restore that file on a reboot.
 
cat /tmp/home/root/.ssh/authorized_keys
Copy file content and paste into Authorized_keys field? As is?
 
That's one way to do it.

Or ...

Code:
nvram set sshd_authkeys="$(cat /tmp/home/root/.ssh/authorized_keys)"
nvram commit
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top