On 20 Mar 2024 19:21 +0800, from jeremy.ard...@gmail.com (jeremy ardley): >>> Regarding certificates, I issue VPN certificates to be installed on each >>> remote device. I don't use public key. >> >> What exactly is this "certificate" that you speak of? In typical >> usage, it means a public key plus some surrounding metadata, but you >> say that you "don't use public key". > > Each client is issued with a private key unique to the access point. When I > say I don't use public key I mean I don't use certificates issued from > public key authorities such as comodo
Ah, so when you say "public key", what you mean is "certificate issued by a widely trusted X.509 PKI certificate authority" (a large chunk of which is often abbreviated as CA). Not the cryptographic concept of the public portion of an asymmetric key pair. Gotcha. Though now I'm instead uncertain what you mean by "access point"; somehow I don't think you're referring to IEEE 802.11 variants APs, although of course certificate-based authentication _can_ be used with those. By the way, no sane public CA these days should issue your keys _for_ you, and no customer should accept a process that involves the CA doing so. The process of acquiring a signed certificate starts with preparing and presenting a CSR which includes the public portion of a key pair generated locally (for some definition of locally); this ensures that it is at least _possible_ that only the party preparing the CSR has knowledge of the corresponding private key. Breaches notwithstanding, obviously, but that's an issue in any scheme. Certainly no reasonable CA should _want_ the risk of ever handling the corresponding private keys. > Private keys aren't private in any corporate network. Security management > would be impossible to manage if users could generate their own keys and > install them on any server. For one thing users do not have any easy way to > revoke certificates. "Run this command, send me this file." Depending on the setup, that can of course also be automated. It is even possible to provision a provisional key pair, triggering a forced key rotation upon login if that key is used (or if a flag is set in the user database); and if you only allow _one_ key at any one time, that this key is generated under the user's control should not present any significant difficulties. Also, I suspect that you use the term "certificate" here in a different sense than elsewhere, because aside from the issues surrounding PKI certificate revocations (as opposed to rotation) in practice, private-CA certificates face similar issues which revocation is supposed to help mitigate. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
