Noone else was facing this, did I really miss the solution?
Running a (holiday) router to connect to the home network with OpenVPN set up
as a server at home
as a client on the holiday router
But starting the service openvpn with ovpn config file on OpenWRT doesnt let me set the client key password?
Please let me know what I am missing, I could not find it in the openwrt openvpn docs (https://openwrt.org/docs/guide-user/services/vpn/openvpn/client) nor on the search engines. using "askpass" in /etc/openvpn/vpnclient.ovpn does not help anyways.
Or do I need to start the "service" in dialog mode?
Log error is
daemon.err openvpn(vpnclient)[21975]: neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'. If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
Wed Nov 7 11:11:47 2018 daemon.notice openvpn(vpnclient)[21975]: Exiting due to fatal error
The error message says it all - you would need a tty console to be able to enter a password. The only way I know of to fix the issue is to make a set of crypto files that do not require a password.
I have the same general setup of a home vpn server and remote client device. I just don’t use the password option.
But it means that I would need to create an additional key without password - if this is possible. The client key for other devices must be password protected.
It would be ok for me to start the openvpn service in dialog mode like with --daemon but I did not figure out how to get this --askpass working.
First you create a root certificate with CA authority. Every device needs a copy of the public part of that certificate. The private key though is used only to sign new certificates. You should keep that in a very safe place and have a password on it. If someone gets the private CA key they can make their own certificates and compromise the whole system.
Each client or server has its own individual certificate which you have signed with the root certificate. The device holds a full copy (public and private) of that certificate. It is not necessary to distribute it to other devices. You should not reuse the same user certificate on more than one device. This lets you revoke the one certificate if a device is lost or stolen. Though when you only have a small number of users you could just make a new CA and rebuild everything.
It doesn't add any security to encrypt a private key when you must also store the passphrase in plaintext on the filesystem to facilitate automated use.
Noone mentioned that it adds security if the password for the key is stored in plain text. It is like writing the pin number of your credit card on a piece of paper and putting it next to it in your wallet. If both, the credit card and the piece of paper gets lost with the wallet, the credit card account gets compromised. This is very similar to a private key and the password. It does in fact not make really sense to store the password in plaintext in a file on the device.
Yeah, this seems to be an option for a workaround. [https://knowledge.digicert.com] comes with a really good knowledge base with lots of useful information.
Fortunately, there is a way to copy the ovpn file as-it-is and to set the askpass /etc/openvpn/vpnclient.auth
It would be much better to use some kind of secure storage (instead of storing the pass in plain text), is this also described on that site?
I have never seen private keys used for authentication or encryption (also of the transport layer) that are not password protected. Maybe in a garage in test environment, but not in real life.
The overall goal of this post was not to tell or learn, it was about finding or enhancing the documentation for
OpenVPN Basic guide isn't solo-written, and I'm not motivated enough to argue about that topic with other authors.
If you check OpenVPN Dual Stack guide, you will notice another point of view.
You've seen at least OpenVPN server key, which is unencrypted.
"OpenVPN Dual Stack guide" - because you are the author? Good one!
Not a good one is:
Recommending "nocrypt" for client keys that are supposed (!!!) to leave a device / to be transported / to be used on a mobile device is grossly negligent.
I don't want to need to notice this view, it feels very uncomfortable!
There is a need for dual stack setup for openvpn for me too, but I cannot follow this guide in general.
Security is never absolute, it's always relative and depends on threat modeling.
Nobody stops you from additional security hardening.
That's one of the reasons the code isn't completely scripted, so you can adapt it to your needs.
"OpenVPN Dual Stack guide" - because you are the author? Good one!