On 18.08.23 16:31, Jason Long wrote:
1- So, if we have multiple servers, then it is better that the servers have the same key, but each client has its own key. Am I right?
No.I said that *if* you want your clients to be able to replace one server with another dynamically, it may be a valid reason to have the *CN* in their server certs have *similarities* to each other (for "verify-x509-name ... name-prefix"), or be outright the same (other types of "verify-x509-name" checks).
(Identical DNs/CNs technically still do not imply that the servers use the same keypair. And using the same keypair technically still does not imply that the servers use the same cert. Though we're going into the area of somewhat questionable setups there.)
2- I can filter clients by MAC address
No, you can't. If the VPN server can see the clients' MACs (*before* a VPN has been established *and* does *bridging*), there's no need to run a VPN between them in the first place.
3- Can you introduce a tool to easily generate keys?
You're already using EasyRSA, that's about as easy¹ as it gets. Not that the act of generating a keypair looks that much different between EasyRSA, plain OpenSSL, or more sophisticated PKI tools ...
¹ "Easy" as in "easy to understand and use manually". Automation and integration may yield something that's easier *to use and maintain long-term*, but since you're apparently unclear on what other systems you're going to integrate it *with* (see next question), we can't comment on that.
4- You said " You need a PKI solution that doesn't just chuck new certs onto a local disk, but can feed it into whatever mechanism you use to keep the clients updated.", which mechanism?
The mechanism that *you* are going to define (and, probably, build) that allows you to admin the clients you designed, and keeps the entire system from coming crashing down as soon as the first certificates' validity period ends.
For example: a) Our staff is usually able to install a new client cert for their laptop's VPN connection to the company LAN themselves, so all we need *there* is an e-mailed reminder to IT that user XY will need a new cert in a couple weeks; but b) the firmware of the appliances we send to customers asks our servers "do I need to update something?" every morning, and if a VPN cert is running out, the servers i) verify that the customer's contract is still ongoing, ii) generate a new cert, and iii) inject it into a more general small-updates-offering mechanism that handles *all* config changes we hand to those appliances.
5- When I use "./easyrsa build-ca nopass", then it asks me "Common Name (eg: your user, host, or server name) [Easy-RSA CA]:", and as you said, better not to use "server" as name. For example, I entered "Jason_Server"
... which should better read "Jason's CA" (yes, blanks are OK there), as it still hasn't anything to do with any servers ...
then I must use "Jason_Server" in the "./easyrsa gen-req Jason_Server nopass" and "./easyrsa sign-req server Jason_Server" commands. Right?
Now *those* commands actually *are* part of generating the *server* certificate, so having them say "server" makes sense, unlike in creating the CA cert above. (I would still prefer server certs to have an FQDN for a CN, though. Old habits die hard ...)
6- Is this true for client too?
Yes.(With the difference that VPN clients usually aren't expected to *have* a long-term-stable FQDN, so I would suggest naming the certs by user and/or device, like "Jason Long's private cell phone".)
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
