OpenVPN missing client cert/key

[elorimer]

More curiosity than an issue. I'm on 386.4 with an AC86U at the moment.

I've gotten around to regenerating all of my OpenVPN server configs with SHA256 keys rather than SHA1 keys. (This is due to a regression in Asus's 386 code that Merlin fixed.)

Because I have three older Chromebooks that do not support the unofficial Android client, I need to use the native OpenVPN .onc process. Chromebooks don't support two server certs for the same router, so I generate the first server, then copy the certs over to the second server. Here's the rub: when I export the configuration for the second server, the client cert and key are missing, like so:

<cert>
    paste client certificate data here
</cert>
<key>
    paste client key data here
</key>

This essentially repeats what is in the corresponding /tmp/etc/openvpn/ server directory. It isn't a big deal to paste the client cert and key in from the first server configuration, and those configurations then work fine in the windows laptops and the chromebooks that support the unofficial client, but I'm curious if anyone knows why this might be so.

A further thing I don't understand, is that /jffs/openvpn/vpn_crt_server1_client_crt is different than /jffs/openvpn/vpn_crt_server2_client_crt.

 

[eibgrad]

IMO, this just comes down to how the router decides to manage this process, based on its own rationale. If you or I were to generate all our own certs and keys for both servers using EASY-RSA (which I still do, I tend to be old school about these things), more than likely we would reuse the same files for each instance. In my own case, I use one for a routed tunnel (TUN), the other for bridged tunnel (TAP). And it just isn't worth managing the files differently given my usage.

Now you're pondering why an auto-generated process produces different files. Well for one thing, each server could be configured differently, such as using different key lengths (e.g., 1024 vs 2048 bits). Each may be generating certs at different times, requiring their start and expire dates to be different. IOW, these differences are inherent to the process the router uses for auto-generation. It's NOT making the kind of assumptions you and I are more likely to make when generating our own certs and keys.

It stuff like this that makes me continue to create my own certs and keys w/ EASY-RSA. I want *full* control over the process. The auto-generation process is nice, and sufficiently convenient for most users, but like any kind of automation, it's NOT going to serve the needs of everyone, esp. more demanding users.

As far as the specific problem of the missing client cert and key, who knows, but once you start messing w/ the underlying files, that always risks corrupting the automation process. So while I wouldn't have expected that specific problem, the fact something like that happened doesn't surprise me either.

JMTC

 

[Igor]

One OpenVPN server and two certificate clients on ASUS routers.

Installed OpenVPN server on ASUS router. In the GUI settings I see "Data ciphers: CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC". I don't see the key length. The client on another ASUS router connects only with a certificate. Everything is working.

Installing a third ASUS router as an OpenVPN client. The client does not connect because no "Client Certificate" and "Client Key". How to generate them correctly?
I see help on openvpn and understand that I don’t understand anything :-(

 

[Igor]

<cert>
paste client certificate data here
</cert>
<key>
paste client key data here
</key>