one way to handle vpn-ca, is to generate passphrase in environment variable to encrypt the files being generated . once the generation process is completed, the pass phrase can be used to decrypt the files during the db insert.

The encryption is actually the easy part...

The hard part is deciding whether we want this at all, whether we want to have more configuration stuff stored in the database, whether we even want the CA in the database for which I'm currently leaning towards "no", because it never every changes during the lifetime of the server, i.e. it is "static". But if we'd go "database all the way for everything", then it may make sense again.

tls-crypt-default.key|#
...
...

wireguard.0.public.key|++h9x4ws2mGS3+dza3CPPlB9cSGF2Q7SHGp8v8neGz4=

This feature by itself is maybe not enough to modify the database. If we could also make other stuff part of the DB it might start to make sense, for example configure profiles as well though the DB. Then we can easily modify config through the web for example, or write a script to dynamically create a profile, etc...

The rest will never change, or only change if there is a serious problem.

The main thing is that these keys are generated on the node(s). So if a profile is added in the config with OpenVPN support, a new tls-crypt key will be generated and registered at the portal(s) and thus needs to be synced as well. It would be neat to only have the need to sync /etc/vpn-user-portal between portals and not /var/lib/vpn-user-portal.

Perhaps we make this WAY too complicated and we should only store the "dynamic" keys in the database, i.e. the files in /var/lib/vpn-user-portal. The rest will never change, or only change if there is a serious problem.

Currently the sessionExpiry is hard coded per server. We'll investigate to make this dynamic, for example through an attribute value provided by the IdM, e.g. eduPersonEntitlement. We could define an attribute value that indicates the expiry for that particular user and override the global sessionExpiry. For example:

/etc/vpn-user-config/config.php has:

'sessionExpiry' => 'P90D',

The attribute value could contain the scoped value:

• http://eduvpn.org/expiry/P1Y (1 year)
• http://eduvpn.org/expiry/P12H (12 hours)

In order to avoid the approval dialog, we could implement something like this:

https://gist.github.com/fkooman/82b39514eefe84449d208b5b296bf307

François Kooman referenced this ticket in commit b7882b3.

We may simply get rid of the distinction between key/crt file and store everything in 1 file, i.e. both the cert and private key concatenated. Then it is up to the 'consumer' of vpn-ca output to deal with that.

not only does vpn-ca need to support reading CA from env, it should probably also work without writing / reading anything from disk. This is a bit more tricky, especially when you want to have cert and key separately. You'd need to pipe stuff, e.g.

$ vpn-ca -gen-key > ca.pem
$ CA_KEY=$(cat ca.pem) | vpn-ca -ca -name "VPN CA" >>ca.pem
$ vpn-ca -gen-key > server.pem
$ CA=$(cat ca.pem) | vpn-ca -server -name foo.example.org >>server.pem

That's quite cumbersome! Especially the self signed case which is weird using this pattern.