On Mon, Apr 17, 2023 at 11:41 AM Robert Relyea wrote:
> I know of no public CA which issues SSL client auth certs (or what it
> would mean for a server to trust a public client auth cert).
>
Let's Encrypt issues roughly 3 million publicly trusted certificates per
day that contain the client auth
Richard Barnes writes:
>Let's Encrypt issues roughly 3 million publicly trusted certificates per day
>that contain the client authentication EKU
But they just set that by default for every cert they issue so it's pretty
much meaningless. There are public CAs that set keyAgreement for RSA certs,
So like a "client" cert is just a way to say "yes I'm really
example.org" yeah?
That seems particularly useful for federated networks (XMPP, etc). Why
not call these server-to-server certs?
On 4/18/23 20:45, Peter Gutmann wrote:
Richard Barnes writes:
>Let's Encrypt issues roughly 3 millio
Not necessarily. One could use client certificates to ensure that only
authorized clients (e.g. a laptop with the client certificate in its key
store) can access some resource.
On Tue, Apr 18, 2023 at 5:07 PM Soni L. wrote:
> So like a "client" cert is just a way to say "yes I'm really
> example
Yes, and organization IT can even mark the private key associated with the
client cert not exportable from that laptop.
I do have customers requiring client cert as one factor of authentication.
Thanks,
Kha Thach
From: TLS On Behalf Of Rushil Mehra
Sent: Wednesday, April 19, 2023 8:05 A
On Tue, Apr 18, 2023 at 09:06:40PM -0300, Soni L. wrote:
> That seems particularly useful for federated networks (XMPP, etc). Why
> not call these server-to-server certs?
That's basically it. At least in OpenSSL, when a EKU extension is
present in the client certificate, it must allow client a
