Solved No Certificate Issue with ASUS OpenVPN Config File

[InductionForced]

Hi folks,

I'm very new to OpenVPN and am looking to get it a private VPN server setup on my ASUS DSL-AC68R router. I am strictly following this guide so the settings in the ASUS router are exactly the same as shown below: https://randyshomeprojects.blogspot.com/2016/11/openvpn-on-asus-router.html​

I setup the server and export the config file to my Android. I press the toggle button to connect and then I am prompted with

Select Certificate. This profile doesn't include a client certificate. Continue connecting without a certificate or select one from the Android keychain?

I press continue and bypass the 'no certificate' prompt and it connects with no problems. The VPN connection is successful and all is running fine.

To see if it isn't just an Android issue I try to connect to the server on a laptop and then get a similar error

Connection Error. Missing external certificate

My config file looks like this:

redacted
float
nobind
proto udp
dev tun
sndbuf 0
rcvbuf 0
keepalive 10 30
comp-lzo adaptive
auth-user-pass
client
auth SHA1
cipher AES-256-CBC
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
redacted
-----END CERTIFICATE-----


</ca>

Here is the ASUS log file too when connecting to Android. Apologies for all the 'redacted' lines, not sure what I was meant to exclude so I excluded everything (IP Addresses)

Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_VER=3.git:released:662eae9a:Release
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_PLAT=android
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_NCP=2
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_TCPNL=1
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_PROTO=2
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_LZO_STUB=1
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_COMP_STUB=1
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_COMP_STUBv2=1
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_GUI_VER=net.openvpn.connect.android_3.2.4-5891
Feb 17 23:17:53 vpnserver1[--]: ----- peer info: IV_SSO=openurl
Feb 17 23:17:53 vpnserver1[--]: ----- PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Feb 17 23:17:53 vpnserver1[--]: ----- TLS: Username/Password authentication succeeded for username 'asus' [CN SET]
Feb 17 23:17:54 vpnserver1[--]: ----- Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256
Feb 17 23:17:54 vpnserver1[--]: ----- [asus] Peer Connection Initiated with [AF_INET]redacted (via [AF_INET]redacted%ppp0)
Feb 17 23:17:54 vpnserver1[--]: asus/----- MULTI_sva: pool returned IPv4=redacted, IPv6=(Not enabled)
Feb 17 23:17:54 vpnserver1[--]: asus/----- MULTI: Learn: redacted -> redacted
Feb 17 23:17:54 vpnserver1[--]: asus/----- MULTI: primary virtual IP for redacted
Feb 17 23:17:54 vpnserver1[--]: asus/----- PUSH: Received control message: 'PUSH_REQUEST'
Feb 17 23:17:54 vpnserver1[--]: asus/----- SENT CONTROL [asus]: 'PUSH_REPLY,route redacted redacted vpn_gateway 500,redirect-gateway def1,dhcp-option DNS redacted,route redacted,topology net30,ping 10,ping-restart 30,ifconfig redacted redacted,peer-id 0,cipher AES-256-GCM' (status=1)
Feb 17 23:17:54 vpnserver1[--]: asus/----- Data Channel: using negotiated cipher 'AES-256-GCM'
Feb 17 23:17:54 vpnserver1[--]: asus/----- Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 17 23:17:54 vpnserver1[--]: asus/----- Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

There is a certificate section in the config file as shown above so I am bit confused as to why it is saying there is no certificate as I thought when exporting that client.opvn file, everything should all be in there including the certificates to make a secure connection. I thought it was as simple as exporting the client.opvn file from the ASUS server to the client device and connecting. Although I can get away without using a certificate and successfully making a VPN connection with the server, ideally I want my VPN connection to be as secure as possible so I was wondering how I can go about implementing this certificate properly? I understand from research that one can simply add the line "--verify-client-cert none" to the server config file but that completely avoids the issue and compromises the security of the connection? I have also performed a factory hard reset to no avail.​

Thanks in advance!

 

[eibgrad]

Technically, you don't need to use client-based certs/keys. But yes, doing so increases security. I don't use the OEM firmware, so I can't speak directly to what its OpenVPN server GUI offers. Sometimes the GUI has the ability to auto-generate such certs/keys, but it *may* be the case that the stock firmware is limited to simple username/password, and only auto-generates the CA cert. And if that's the case, you may be forced to generate these yourself, outside the router, e.g., from a Windows or Linux PC using EASY-RSA. Then either use the appropriate fields in the GUI (if they are available), or worst case, specify the additional certs/keys *inline* using the custom config field.

Again, since I don't use the OEM firmware, I don't know how flexible it is. I'm making an educated guess as to how it works. That's why so many ppl embrace Merlin's firmware. It makes a lot of this stuff trivial by offering a more thorough and richer environment. But of course, that assumes YOUR router is supported.

 

[eibgrad]

P.S. If it's any consolation, many commerical OpenVPN providers don't offer client-based certs/keys either! Just simple username/password w/ a CA cert (to authenticate the client and server). As I said, this is minimally sufficient. But I too prefer to authenticate individual clients w/ their own cert/keys. I just don't want you to be under the false impression that simple username/password is easily compromised. It's NOT.

 

[InductionForced]

Technically, you don't need to use client-based certs/keys. But yes, doing so increases security. I don't use the OEM firmware, so I can't speak directly to what its OpenVPN server GUI offers. Sometimes the GUI has the ability to auto-generate such certs/keys, but it *may* be the case that the stock firmware is limited to simple username/password, and only auto-generates the CA cert. And if that's the case, you may be forced to generate these yourself, outside the router, e.g., from a Windows or Linux PC using EASY-RSA. Then either use the appropriate fields in the GUI (if they are available), or worst case, specify the additional certs/keys *inline* using the custom config field.

Again, since I don't use the OEM firmware, I don't know how flexible it is. I'm making an educated guess as to how it works. That's why so many ppl embrace Merlin's firmware. It makes a lot of this stuff trivial by offering a more thorough and richer environment. But of course, that assumes YOUR router is supported.

Thanks for that clarification! In that case, is it easy to generate the required key with EASY-RSA? Doing a quick Google, it seems rather complex. Referring to the stock GUI in the first picture in the original post, there is a link 'Content modification of Keys & Certification.' which gives a block of code for the Certificate Authority, Server Certificate and Server Key. I'm assuming I would need these to generate a key with EASY-RSA or can I put these into the config file?

I'm thinking if I have to go through all the effort of manually generating a key each time a new config file is made, the best choice would be just install Merlin but the problem is there is no Merlin firmware available for the DSL model ...

 

[RMerlin]

Asus' stock firmware will take care of generating the server key/cert automatically. You just need to export the generated config file to your client device.

 

[eibgrad]

Asus' stock firmware will take care of generating the server key/cert automatically. You just need to export the generated config file to your client device.

Thanks, although I believe what the OP is concerned about is the lack of *client* cert/key. The server cert/key only authenticates the server. At least that appears to be missing in the client config as posted. As I said, it isn't required that you use client-based certs and keys. You can just use username/password alone, or client-based certs and keys, or both. I'm merely speculating that the ASUS OEM firmware is taking the easy way out and only generating username/password, just to keep things simple. Otherwise I would expect any auto-generated client config file to contain a client cert and key.

Again, I'm at a disadvantage here given I don't have any ASUS router running stock firmware at the moment to verify one way or the other. But I wouldn't be shocked if indeed the OP is correct and the OEM firmware is just relying on basic username/password for client authentication. As you know, OEM firmware often creates a less than ideal configuration.

 

[eibgrad]

Thanks for that clarification! In that case, is it easy to generate the required key with EASY-RSA? Doing a quick Google, it seems rather complex. Referring to the stock GUI in the first picture in the original post, there is a link 'Content modification of Keys & Certification.' which gives a block of code for the Certificate Authority, Server Certificate and Server Key. I'm assuming I would need these to generate a key with EASY-RSA or can I put these into the config file?

I'm thinking if I have to go through all the effort of manually generating a key each time a new config file is made, the best choice would be just install Merlin but the problem is there is no Merlin firmware available for the DSL model ...

Sounds to me that this is only providing information about the server side and its cert/key.

Understand, I'm old school and *always* use EASY-RSA to generate and manage by certs & keys, be they client or server, DH params, etc. The works. GUIs are great and usually do make things much easier, but *sometimes* they make compromises for the benefit of the OEM. So rather than hoping the GUI does what I want, I just bite the bullet and do it myself. And I've developed scripts to automate the process to my liking. So no big deal for me. But I can understand your concerns.

Quite honestly, if it was me, and I had concerns about dealing w/ client-based certs & keys, I'd probably just live with what the GUI offers, even if less than ideal. As I said, OpenVPN providers routinely rely solely on username/password. So I wouldn't lose any sleep over the fact that client-based certs and keys are (apparently) not available.

But if you insist on it, and the GUI is NOT generating them for you, my advice is to abandon whatever the GUI generates in this regard, and just do as I do; create everything w/ EASY-RSA, client and server. IMO, it's just going to be easier than dealing w/ some hybrid solution (if that's what you're contemplating) where you try to combine what the GUI offers w/ EASY-RSA. Even if it's possible, *I* certainly am not in a position to give advice on such an approach.

 

[eibgrad]

I've posted my own openvpn client config file to PasteBin, just so you can see what Merlin generates and compare it to your own w/ the OEM firmware. Notice besides the <ca></ca> section, it also contains the <cert></cert> and <key></key> sections, which are client cert and key. I assume the latter two sections do NOT appear in your client's config.

clientdev tunproto udpremote 192.168.63.102 1194resolv-retry infiniten - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

 

[InductionForced]

I've posted my own openvpn client config file to PasteBin, just so you can see what Merlin generates and compare it to your own w/ the OEM firmware. Notice besides the <ca></ca> section, it also contains the <cert></cert> and <key></key> sections, which are client cert and key. I assume the latter two sections do NOT appear in your client's config.

clientdev tunproto udpremote 192.168.63.102 1194resolv-retry infiniten - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Thanks once again mate, you've been a great help. So from what I can depict, the firmware is only supplying keys for the server side and not the client side? Whereas in the Merlin firmware, the client keys are generated and integrated into the config file like the one you uploaded?

I guess the only less hair pulling option is just to live without the certificate and I can just add the

--verify-client-cert none

line to every config file I make so it doesn't give the annoying prompts all the time

Nervermind, I think I solved it!

I simply changed the first setting in the image above to 'No' and that changed the authorisation mode to TLS. I guess the option is pretty self explanatory and makes a lot more sense to me after your explanations. Now to authorise the connection it will not only use a username and password but the a key as well. Looking at my config file now it is the exact same format as yours with the client cert and key!

You're probably shocked the stock firmware has that ability

Using the new config file in the Android client it does not ask for any certificates and the connection works fine. Glad that's sorted. Thanks for your help again eibgrad, I appreciate it.

 

[eibgrad]

Awesome! I was puzzled why it didn't provide it. But as I said, I had no way to test it here. Glad it's working.

 

[elvn]

Thanks for this. I have just recently been messing with this kind of setup. The TLS method and forcing it to use that key instead of just the username and password is much more secure. However I still can't help wanting to set up a separate, unique client cert key for each user/device.

It would have been nice if Asus had set up a bunch of client checkboxes with export keys or a drop down to set the number of client keys to generate via a button next to it. Unless there is something stronger encryption wise built into each android device that would require the certs to be generated on each of those devices themselves from some command line?

I don't really want to resort to using a linux box , raspberry pi, etc right now. I think I could manually generate some via windows command line using the primary cert contents if I follow along some google results but it's a little bit of a pain. I know there is some way that you can log into the asus router itself via terminal but I don't know if you can do the same kind of multiple user cert generation that way. I haven't seen any web results showing that yet at all. Asus could have just built that into the UI but it's not there unless I missed something that activates after changing a dropdown menu selection or something.

I do have it working now as you described with a single key though so thanks again for that. Anyone with some extra info about any of the questions I had above regarding multiple key generation in windows command line (or in the asus command line via terminal) would be greatly appreciated though.

 

[eibgrad]

@elvn

It is possible to use EASY-RSA on the router provided you have access to Entware, which would require access to third-party firmware (e.g., Merlin). In fact, some third-party firmware already supports the generation of per-client certs and keys in the GUI (e.g., FT (FreshTomato)).

But even if this capability is available on the router, while it is convenient, the process can be very slow compared to a desktop PC or laptop running Windows or Linux. There's also the security concerns of storing your private keys (esp. the one for the CA (Certificate Authority) cert) on the same device as the OpenVPN server. That CA Cert private key is the "key to the kingdom" in a sense. It's what allows you to generate client certs and keys that are only valid for your server w/ the matching CA cert. It's actually far more secure to manage this process OFFLINE, on some other device. Many things done on the router are for the sake of convenience, and NOT because it's safe (or as safe as it needs to be in the eyes of more discerning users).

So the reality is, you're going to be MUCH better off, both for security and performance reasons, to manage your own certs and keys OFF the router, even though I understand it may be painful due to the learning curve, finding a suitable device, etc.

And btw, there's no benefit in generating the client certs and keys on the client device itself. There's NOTHING the client device uniquely adds to the process to make the certs and keys "better". The only difference a change in platform brings is worse or better performance in generating those same certs and keys. It also means you need to provide the CA cert's private key to the client, which is itself a potential security risk. You do NOT want that falling into the wrong hands.

So I urge you to move the process to a desktop/laptop if you have concerns over the lack of client-specific certs and keys, no matter how painful it may be. Perhaps use a live Linux CD and persist your EASY-RSA environment on a USB stick. Or perhaps find a spare router that supports FT and use it solely for these purposes (it won't be as fast, but at least the process is already automated in the GUI, just keep it inaccessible to the internet).

 

[Igor]

Asus' stock firmware will take care of generating the server key/cert automatically. You just need to export the generated config file to your client device.

ASUS RT-AC68U fw 386.4. I have a workable openvpn with one client. I added a second client. Now two clients are fighting to access the server. Do I understand correctly, the reason is that both clients use the same certificate? If so, how can the issue be resolved?

 

[eibgrad]

ASUS RT-AC68U fw 386.4. I have a workable openvpn with one client. I added a second client. Now two clients are fighting to access the server. Do I understand correctly, the reason is that both clients use the same certificate? If so, how can the issue be resolved?

What do you mean by "fighting to access the server"?

No matter how you configure the server, this shouldn't prevent access by multiple clients at the same time (if that's what you're suggesting). There's only one server cert, which all clients use to verify the server. When it comes to the client and the use of client-based certs+keys, that's another issue. You have different options, which include a) NO client cert+key (in which case username/password is required), b) client cert+key plus username/password, or c) client cert+key and NO username/password. The issue w/ options "b" and "c" (at least for some ppl) is that all clients share the same client cert+key (which works thanks to the fact the server includes the duplicate-cn directive), and the router offers no solution for those that prefer to have each client issued its own client cert+key. For that you have to create your own client certs and keys using EASY-RSA and distribute a different client config file each client, each containing a different client cert+key.

But regardless how you configure the server, there's nothing that should prevent multiple users from accessing the same server, if that's what you mean by "fighting to access the server".

 

[Igor]

What do you mean by "fighting to access the server"?

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.

. For that you have to create your own client certs and keys using EASY-RSA

Where can I find EASY-RSA on my router?

 

[eibgrad]

The first client connects. A second later, the second is connected, the first is disconnected. Then the first one connects, the second one disconnects. And so in a circle.

How do you have the server configured wrt the "Username/Password Authentication" and "Username/Password Auth Only" fields?

Might as well take a look at the server config file too, just to make sure things are correct.

cat /tmp/etc/openvpn/server1/config.ovpn

Where can I find EASY-RSA on my router?

You won't normally find this on the router.

Solved - No Certificate Issue with ASUS OpenVPN Config File

Hi folks, I'm very new to OpenVPN and am looking to get it a private VPN server setup on my ASUS DSL-AC68R router. I am strictly following this guide so the settings in the ASUS router are exactly the same as shown below...

www.snbforums.com

 

[eibgrad]

@Igor

Ok, based on the following link ...

Problem with more than 1 client connected to VPN at a time.

I setup 2 devices on on my RT-AC68R 386.2_6 and both are working great except that when one connects the other disconnects. Is it possible to run 2 devices in the same tunnel, or do I need to take turns, or use my second VPN? I do see they get the same address each time....I don't understand...

www.snbforums.com

I see what is probably happening here. When you enable Manage Client-Specific Options, the router is *removing* the duplicate-cn directive, which makes sense, since when you enable that option, you need a means to uniquely identify the user based on the common-name on their client cert. But you should be able to use the username/password instead as the common-name, provided the router includes the username-as-common-name directive. But for reasons I don't quite understand, it only does that when you specify Yes for "Username/Password Auth Only". If you have that set to No, you could try adding that same directive manually to the custom config field. Of course, if you have Username/Password completely disabled, then you have a problem since by definition, the use of Manage Client-Specific Options *requires* unique client certs+keys.

P.S. I understand this can be confusing. There's a lot of different options, settings, and directives involved w/ all this, and each changes how the router responds and configures the server's config file.

 

[Igor]

How do you have the server configured wrt the "Username/Password Authentication" and "Username/Password Auth Only" fields?

"Username/Password Authentication" - yes
"Username/Password Auth Only" - no

daemon ovpn-server1
topology subnet
server 10.8.0.0 255.255.255.0
proto tcp4
port 1194
dev tun21
txqueuelen 1000
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
data-ciphers-fallback AES-128-CBC
keepalive 15 60
verb 3
push "route 192.168.1.0 255.255.255.0 vpn_gateway 500"
client-config-dir ccd
client-to-client
route 192.168.50.0 255.255.255.0
route 192.168.50.0 255.255.255.0
route 192.168.8.0 255.255.255.0
route 192.168.8.0 255.255.255.0
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up 'ovpn-up 1 server'
down 'ovpn-down 1 server'
status-version 2
status status 5

 

[eibgrad]

@Igor

Try adding the username-as-common-name directive to the server custom config field.

 

[eibgrad]

@Igor

Now that I think about it, you might have to add BOTH duplicate-cn and username-as-common-name directives to the server custom config field.

Just make sure in Manage Client Specific Options you specify the username where it asks for the Common Name. 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). But I think you can get away w/ using the same client cert+key provided you have make the above changes.