On 5/17/25 8:27 AM, Jaroslaw Rafa via mailop wrote:
There is nothing wrong with using a client certificate for
authentication *as such*, but the server cert and client cert functions
should be separated.
Except when /the/ /authenticated/ /server/ /is/ /the/ /client/.
E.g. my use case wherein MTAs authenticate to each other using their
server certificate. -- This could be done via IP in most cases. But
dynamic IPs at client offices really benefit from the known subject from
an authorized public CA being allowed to do things despite the IP
changing out from under them. (Think outbound relay at a spoke office
authenticating to a central MTA in corporate HQ.)
Why?
I understand -- what I consider to be -- the small but real security
posture improvement that is being chased.
My concern is that this, like the forthcoming 47 day TLS cert (from
public CAs), is going to end up causing people to downgrade their
security thereby worsening the overall security posture.
Server cert, like the one obtained from Lets Encrypt, identifies a
*server*, not a particular user.
Sometimes, as in my case, /the/ /server/ /is/ /the/ /user/.
Even if you specify a contact email address in the cert request, that
address is not verified (as far as I remember), and it is also intended
to be a generic administrative address under which the server operator
can be contacted, rather than an address identifying a particular user.
My understanding is that the subject (alternative name(s)) is (are) what
is verified.
In my use case, Let's Encrypt has verified my server as the subject.
And the verified subject is what's being authenticated (or not) based on
the certificate subject.
Client cert, on the other hand, identifies a particular *user*.
I think we're using a different definition of "user" in our two
contexts. I suspect lawyers might call these alternative facts, each
valid in their own context.
In our case, the user's identity would be determined by a particular
email address.
And said email address should be the subject of the certificate, not
just a contact field.
It's my understanding that the extended key usage flags are -- IMHO --
somewhat arbitrary and disassociated from what the subject is set to. I
say arbitrary as it's possible to create certificates with any
combination of the server vs client authentication EKU values.
I can totally imagine that Lets Encrypt, besides server certs, *could*
issue separate client certs, where you specify your email address
in the cert request, and that address is verified eg. by the usual
method - you receive a confirmation link in email and you have to
click on it. Such a cert would identify a particular email account
and could be used to authenticate to the email server (instead of
login and password).
That would be for putting an email address in the certificate's subject.
I don't think there's anything other than Let's Encrypt's validation
requirements / infrastructure preventing that today. As in the
underlying X.509 ${BAILIWICK} supports this as is.
But these functions should not be mixed in the same cert.
That's one opinion. I have a different opinion.
There are times when /the/ /client/ /is/ /the/ /server/ which has been
authenticated and is the subject of the certificate.
There are other times when the client is some completely separate entity.
--
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
