First off, the pre-reqs in the OpenSSL-CA Creation section don't quit match, the openssl.cnf file is different than expected. None the less, I worked through these issues, and go to step 3:
openssl crl -inform PEM -in crl/OpenWrt-CA.crl.pem -outform DER
in there where my SSH client spits out crazy characters for several lines, followed by
I'd suggest creating the CA, certs, and keys on a regular PC/Mac/Linux box. I used the EasyRSA method, so not sure if there are any complications using OpenSSL. But the author of the guide recommends OpenSSL for security and a few other reasons (I do not know what impact EasyRSA has on those considerations).
There is supposed to be a \ to join the two lines like in the other commands so the -out option is part of the command. Without a -out option, output goes to the terminal instead of a file.
You don't really need a crl file unless you're going to revoke certificates. A revoked certificate lets the server deny a formerly approved user (CN) without having to remake and distribute all new certificates.
And like psherman said, it is easier (and faster) to generate these files on a PC using one of the GUI packages available.
man, duh. They missed the \ and instead added another - on the next line. THANK YOU
I edited the wiki to be correct.
I wanted to add though, do you know a good guide for making the certs required on WIN10, and getting them into the proper folders with the proper names?
In the end my goal is to get a really simple openVPN server set up here... using the Lede build for the C7 V2 linked above. I'm pretty new to this so any further direction is greatly appreciated... =)
The build has the opVPN GUI with a sample VPN Server profile made... but of course no certs and no guidance beyond that.
I'm a fan of this guide, which uses the EasyRSA certs. If you want to do the OpenSSL certs, you'll probably just be substituting that part of the process. The majority of this uses the command line options, but if you read through it and understand what it is doing, you should be able to do it with the LuCI interface, if you want.
Server section starts on Line 201 and ends on Line 218
Client section starts on Line 219 and ends on Line 225
This is in case one has multiple servers/clients they need to issue certs for.
This is the recommended way of doing it, as CA creation should never be performed on a device which will be utilizing it's certificates (which should also be air-gapped), and while that wiki originally had this in it, I removed it a while back due to users stating this was inconvenient for them.
Thanks for that. When I ported the wiki over from OpenWrt there were some alignment issues with the LEDE wiki site, so I had to adjust the commands from a single line to multi-lined, and I clearly missed a backslash when I did that.
See the bottom of the openssl.cnf linked to and the GitHub ReadMe, as that openssl.cnf is made for Windows. I never put that point in the wiki, as I assumed users would note Line 3, then read Lines 12 - 18, adjusting the config as required.
That guide, as well as 99% of OpenVPN server guides on the web:
Is a dated, bare-minimum, generic instruction, configured with redirect-gateway enabled, something most users will not use.
Is inefficient, using SSL instead of Elliptic-Curve TLS ciphers, which are far more efficient and supported as of OpenVPN 2.4
Lacks tuning of the VPN connection, ensuring one will receive less than optimal throughput
Easy-RSA should not be utilized for a whole host of reasons and does not conform to several RFCs:
Easy-RSA prevents the usage of certain EC ciphers, severely limiting one's cipher choices, due to it not supporting customization of keyUsages [KUs], and altogether prevents the usage of extendedKeyUsages [EKUs].
Easy-RSA does not create proper client & server certs, of which should have their respective EKUs for server-auth and client-auth
This prevents MITM [Man In The Middle] attacks
Easy-RSA requires OpenVPN to use an obsolete server TLS verification option intended for the defunct, no longer existing Netscape Browser
Easy-RSA prevents the usage of SANs [subjectAltName profile], as CN [Common Name] usage for IPs/URLs was depreciated more than 2 decades ago in the RFC.
This is a bad idea all around and will cause more issues than it solves.
The OpenVPN LuCI interface is so convoluted, it was difficult for me to navigate through, even with as much as I know about OpenVPN.
It is far simpler to configure OpenVPN via CLI
The only thing the LuCI package enables one to do is alter OpenVPN server config options, although I do recommend installing it, but only for using it as a status indicator. Most users utilize LuCI, not CLI, to manage their router, and a quick glance at the OpenVPN LuCI page allows one to verify it's status.
For example, the CA section does not start at line 177 in my config file. Same with the CA client section at line 195.
Further, the folder required to be changed in my version in the config (it was pointing to ./demoCA) which led me in a big circle too =).
Another example is that my build does not even find the extension v3_ica_router2 - in fact I can't find that ever referenced in the config file either.
This may be the root of my problems, otherwise I can copy/paste commands and edit files according to instructions, but when they don't match well it makes it very touch for me.
I really want to use your guide because as you say, it is far more secure and "proper." Just somehow need to get to the same starting point I guess! =)
Definitely missed that. I took "Download openssl.cnf" to mean - download the existing file from the router onto my PC.... let me give it another shot =).
For CA and ICA servers and clients, what should we edit there?
direct openvpn conf file, typically /etc/openvpn/xxxxx.ovpn
/etc/config/openvpn
LuCI app-openvpn (not recommended)
The first method, to use the direct conf file, requires placing a single option in /etc/config/openvpn pointing to it, so once your instance of openvpn is launched, it reads the file.
This gets you "close to the metal" and you can directly follow documentation from openvpn.net. It is particularly useful if you are setting up your router to be a client to a commercial service and they supply a suggested .ovpn file. Usually that file can be used with minor changes such as paths and the name of the tun interface.
If you use /etc/config/openvpn you generally will take the .ovpn style options word for word and reformat them into UCI format.
You can skip the ICA section, as all you technically need is the CA, however I configured the openssl.cnf, and the wiki, in such a way that everything is there should any arbitrary user choose to properly secure devices/servers they utilize.
Ideally, there should be a primary CA whose only purpose is to sign ICAs, and every device/server should have their own ICA, of which then signs certs for each device server. This creates a chain of trust of Self-Signed-CA -> CA signed ICA -> ICA signed certs.
It's extremely important VPN servers have an isolated CA or ICA, as this prevents the arbitrary user from having to generate new certs for every server/device if the VPN, or it's ICA, is ever compromised.
It's generally easier and more convenient for home users to simply regenerate a VPN's ICA and sign new certs than it would be to maintain a CRL (I've included the creation of a CRL in the wiki because it was quite difficult to find how to generate one when I wrote the wiki)
For example, this is my Chain of Trust
Primary & master CA for Sophos UTM, of which signs all Sophos UTM related certs
ICAs for each router, FreeNAS server, and IPMI UIs (totaling 8), of which are all signed by the Sophos UTM CA
Each router's ICA signs the WebUI (uhttpd) cert and all VPN server and client certs
.
This is in the OpenVPN Server Wiki, under VPN Wikis - OpenVPN, with a "Highly Recommended" Notice wrap above it.
Everything else in your post is covered in the OpenVPN Server wiki, under Server Config.
option config has no use to a user utilizing a single VPN server/client instance, with it's main purposes being either to load multiple configs from nested locations, or for multi-user systems, where an arbitrary user may not have write privileges to the system wide openvpn config (see OpenVPN 2.4 Man)
For example, on Windows, non-admin users don't have write privs to %ProgramFiles%\OpenVPN\config, so an admin can simply have a system wide config refer to a config at %UserProfile%\.ovpn\config. This allows a non-admin user to modify the config(s), without providing them write privileges to system level directories.