3

Is it conceptually possible to allow in the server a specific self signed client certificate for mutual TLS?

If possible but not recommended. Why?

I have a client to who I have to provide a server that does mutual TLS auth. But they say they wont sign our server certificate nor will they let us sign their client certificate. How should I approach this?

4 Answers 4

5

Is it conceptually possible to allow in the server a specific self signed client certificate for mutual TLS?

Yes. A self-signed certificate is nothing special. Using the trust chain against a trusted root CA is not the only way a certificate can be verified, but one can for example simply explicitly trust the given certificate or the public key inside it.

Note that a self-signed certificate still need to be verified against the expected value. Blindly trusting arbitrary self-signed certificates (as done in many examples) is insecure. How such validation needs to be implemented is different between programming languages and frameworks.

If possible but not recommended. Why?

Certificates issued by an already trusted CA can rely on this CA as the trust anchor. For self-signed certificates there is no such pre-existing trust anchor. In this case the certificate, its fingerprint or similar must be distributed using some existing trusted mechanism to all the peers which should trust the certificate. And it must be removed from all these clients if it needs to be revoked. This is doable with a few peers but does not scale to many.

I have a client to who I have to provide a server that does mutual TLS auth. But they say they wont sign our server certificate nor will they let us sign their client certificate. How should I approach this?

As I said, self-signing certificates are perfectly acceptable to use if the trust relationship was distributed over a trusted medium. It simply does not scale well with many parties and it might be a problem to properly verify the certificate in the applications. But, if this is not a problem in your specific case, then self-signed certificates can be used.

3
  • So. in haproxy I should just add the client self signed certificate in the ca.pem ca-file ? Commented Jun 28, 2021 at 15:22
  • 1
    @DavidHofmann: Nothing about haproxy was in the question. But yes, ca-file seems to be the appropriate option. Commented Jun 28, 2021 at 15:26
  • @37315 created a new question for the haproxy specifics. thanks ! security.stackexchange.com/q/251832/69009 Commented Jun 28, 2021 at 15:35
1

Yes, it's entirely possible for clients to authenticate with your web server using self-signed client certificates.

See https://cweiske.de/tagebuch/ssl-client-certificates.htm for a good write-up on how this is done using Apache and PHP. In this write-up, the author uses a CA-signed client cert. However, there is no reason why the client certificate could not be self signed. To determine whether or not to authenticate a client based on the client's certificate, the server checks the values in a few of the fields in the leaf certificate and compares these with the expected values for that client. If the values in the certificate match the expected values, the client is authenticated. (*Of course, the client must be able to complete a TLS handshake with the server, proving that it has possession of the private key that corresponds with the certificate). But, to answer your question, other certificates higher up in the chain are not relevant, so it doesn't matter if the client certificate is self-signed or signed by a CA.

1
1

Yes, it can work. You only need to have a mapping from the user (or client) identity to the corresponding user (or client) public key (eg. in stored database).

Actually you don't need need certificates at all. TLS 1.3 has an option for only sending public key instead of sending certificates. This is done by using using the client_certificate_type (or server_certificate_type for server certificates) extension:

struct {
  select(ClientOrServerExtension) {
  case client:
    CertificateType server_certificate_types<1..2^8-1>;
  case server:
    CertificateType server_certificate_type;
  }
} ServerCertTypeExtension;

enum {
  X509(0),
  RawPublicKey(2),
  (255)
} CertificateType;

As an example, the use of self-signed certificates for OAuth client authentication is specified in OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. In this case, the self-signed client certificate is fetched by the server over HTTPS:

This method of mutual-TLS OAuth client authentication is intended to support client authentication using self-signed certificates. As a prerequisite, the client registers its X.509 certificates (using jwks defined in [RFC7591]) or a reference to a trusted source for its X.509 certificates (using jwks_uri from [RFC7591]) with the authorization server.

Whereas HTTP servers have builtin support for checking a client certificate chain against one (ore more) trusted root(s), if you choose to use self-signed certificates, you will have to implement the logic by yourself (it can be very simple however).

1

Proof of possession of the private key does a lot, but mutual authentication as OpenSSL implements it checks all CA certificates along the chain if they end up in a Root-CA the server trusts first.

So, it would be required to configure the self-signed certificate as trusted root CA on every endpoint/machine.

The next hurdle is the extended attributes. For Root-CA certificates, the extension attribute CA:TRUE is required If the extension and attribute are missing, then the certificate later may not be considered a valid CA certificate. This is a typical cause for a client side authentication error during the TLS handshake.

So my advice is, don't do it even if it could be possible.

New contributor
Boettinger is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
1
  • This is just not true, OpenSSL is a library, not a protocol. You don’t need to add a root certificate for certifying it. And you don’t need extended attributes for the scheme to work. You could use all of them, but this all depends on how you set it up, a d what you are protecting against.
    – LvB
    Commented Jul 15 at 18:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .