TLS 1.2 handshake issue (Server Certificate request)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS 1.2 handshake issue (Server Certificate request)

Bashin, Vladimir

Hello, OpenSSL experts !

 

We need your help in better understanding a below behavior -

 

We are experiencing issue during the initial TLS handshake :

We have the customer-issued TLS certificate that we deploy on our TLS client system

The certs  have been generated with a CSR that was generated on customer’s  FIPS compliant server

The CSR was then signed by CA hosted on SMGR 

 

During the endpoint registration with the server we have an endpoint initiated TLS handshake – during that handshake the TLS server requests the client Certificate but our TLS client responds with the Certificates Length 0 that causes the TLS server to respond with the Handshake Failure.

 

 

The Google search gives some generic ideas on why that might be happening – something along the following lines - that could be happening in case the client’s certificate does not match the server certificate – for example, due to a signing authority mismatch, or due to the encryption cipher type mismatch, or maybe due to some other factors.

 

Could you please help us in better understanding this issue – what else could be wrong or missing in the Server and Client certificates ?

 

 

 

 

 

 

 

Thanks,

Vladimir Bashin

 

Reply | Threaded
Open this post in threaded view
|

Re: TLS 1.2 handshake issue (Server Certificate request)

Dmitry Belyavsky-3
Hello Vladimir,

It's worth trying to reproduce the situation using openssl s_client/s_server command-line apps. 

On Fri, Feb 7, 2020 at 9:25 PM Bashin, Vladimir <[hidden email]> wrote:

Hello, OpenSSL experts !

 

We need your help in better understanding a below behavior -

 

We are experiencing issue during the initial TLS handshake :

We have the customer-issued TLS certificate that we deploy on our TLS client system

The certs  have been generated with a CSR that was generated on customer’s  FIPS compliant server

The CSR was then signed by CA hosted on SMGR 

 

During the endpoint registration with the server we have an endpoint initiated TLS handshake – during that handshake the TLS server requests the client Certificate but our TLS client responds with the Certificates Length 0 that causes the TLS server to respond with the Handshake Failure.

 

 

The Google search gives some generic ideas on why that might be happening – something along the following lines - that could be happening in case the client’s certificate does not match the server certificate – for example, due to a signing authority mismatch, or due to the encryption cipher type mismatch, or maybe due to some other factors.

 

Could you please help us in better understanding this issue – what else could be wrong or missing in the Server and Client certificates ?

 

 

 

 

 

 

 

Thanks,

Vladimir Bashin

 



--
SY, Dmitry Belyavsky
Reply | Threaded
Open this post in threaded view
|

Re: TLS 1.2 handshake issue (Server Certificate request)

Dmitry Belyavsky-3
If you have the server's key and certificate, the command will be smth like

openssl s_server -key key -cert cert -CAfile file_with_ca -verify_return_error

file_with_ca should contain a concatenation of the certs of the CAs that should issue the client's certificate.

if you don't have the server keypair, try to understand smth from the command

openssl s_client -connect host:port -cert clicert -key clikey.

At least you'll hopefully see the list of allowed client certificate issuers.

Please read the manuals of s_client/s_server apps for more details.

On Fri, Feb 7, 2020 at 11:18 PM Bashin, Vladimir <[hidden email]> wrote:

Thanks Dmitry!

Do I need the server certificate in order to run those commands?

Also , could you please point me to the exact commands that I’d need to execute in order to reproduce the tls handshake ?

 

Regards,

VB

 

From: Dmitry Belyavsky <[hidden email]>
Sent: Friday, February 7, 2020 3:07 PM
To: Bashin, Vladimir <[hidden email]>
Cc: [hidden email]
Subject: Re: TLS 1.2 handshake issue (Server Certificate request)

 

Hello Vladimir,

 

It's worth trying to reproduce the situation using openssl s_client/s_server command-line apps. 

 

On Fri, Feb 7, 2020 at 9:25 PM Bashin, Vladimir <[hidden email]> wrote:

Hello, OpenSSL experts !

 

We need your help in better understanding a below behavior -

 

We are experiencing issue during the initial TLS handshake :

We have the customer-issued TLS certificate that we deploy on our TLS client system

The certs  have been generated with a CSR that was generated on customer’s  FIPS compliant server

The CSR was then signed by CA hosted on SMGR 

 

During the endpoint registration with the server we have an endpoint initiated TLS handshake – during that handshake the TLS server requests the client Certificate but our TLS client responds with the Certificates Length 0 that causes the TLS server to respond with the Handshake Failure.

 

 

The Google search gives some generic ideas on why that might be happening – something along the following lines - that could be happening in case the client’s certificate does not match the server certificate – for example, due to a signing authority mismatch, or due to the encryption cipher type mismatch, or maybe due to some other factors.

 

Could you please help us in better understanding this issue – what else could be wrong or missing in the Server and Client certificates ?

 

 

 

 

 

 

 

Thanks,

Vladimir Bashin

 


 

--

SY, Dmitry Belyavsky



--
SY, Dmitry Belyavsky
Reply | Threaded
Open this post in threaded view
|

RE: TLS 1.2 handshake issue (Server Certificate request)

Michael Wojcik
In reply to this post by Bashin, Vladimir
> From: openssl-users [mailto:[hidden email]] On Behalf Of Bashin, Vladimir
> Sent: Friday, February 07, 2020 11:25

> ... during that handshake the TLS server requests the client Certificate
> but our TLS client responds with the Certificates Length 0 that causes
> the TLS server to respond with the Handshake Failure.

This means your client can't find a certificate to send. Usually this means that it doesn't have a certificate that:

- is among the ones it's been told, in some application-specific manner, it can use as a client certificate;
- it has the corresponding private key for;
- is valid (not expired, etc.);
- has the appropriate purpose (X.509v3 Extended Key Usage, if present, includes TLS Web Client Authententication), if the application makes this check;
- and meets the requirements listed in the server's CertificateRequest message

Note that last point. The CertificateRequest sent by the server specifies requirements and hints for the client certificate, as described below.

Also note that here "application" refers to both the end application and whatever TLS implementation it's using. Some TLS implementations do most or all of the certificate-selection work for the end application; others don't.

> ... that could be happening in case the client’s certificate does
> not match the server certificate

No, the client certificate doesn't have to match anything in the server certificate. What it has to satisfy are the CertificateRequest parameters.

See RFC 5246 (TLSv1.2) section 7.4.4. CertificateRequest contains three fields:

1. certificate_types, which is a list of certificate "types", by which the authors mean the kind of public key the certificate uses. The RFC specifies four possible values, but two of them are redundant (for historical reasons), so basically this comes down to RSA and/or DSA. RFC 8422 added ECDSA, and there are some less-common variants.

2. supported_signature_algorithms, which is a list of the signature-and-hash-algorithm pairs the server supports for client certificates. These are integer value pairs which are defined to represent algorithm pairs such as {sha1, rsa}. The RFC and its successors specify the standard values at the time each RFC is published, and IANA maintains the current list.

3. certificate_authorities, which is a list of distinguished names.

If the client sends a certificate, it MUST use a public key that matches one of the types in #1, and a signature algorithm that matches one of the pairs in #2.

The client MAY attempt to find a certificate signed by one of the authorities listed in #3. In practice, many client applications will honor this list, to the point of not sending a certificate at all if they don't have one signed by a CA on the server's list.

So you need to know what's in that CertificateRequest message. Since it's encrypted, you'll probably have to get either the server or the client to log it. Or maybe the client can be configured to log why it couldn't find a suitable client certificate.

Short version: TLS PKI is difficult. It's so difficult, and so security-critical, that I don't recommend people try to configure it without an expert. Unfortunately experts are hard to come by. (I'm certainly not one, despite having worked with TLS for a couple of decades now, and taken courses on it, and read books and other references...)

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

RE: TLS 1.2 handshake issue (Server Certificate request)

Bashin, Vladimir
Thank you very much, Michael - let us digest the information and present it to the customer.   I may probably come back with the follow up questions in case they say something worth passing to you...

Regards,
Vladimir Bashin

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Michael Wojcik
Sent: Friday, February 7, 2020 3:37 PM
To: [hidden email]
Subject: RE: TLS 1.2 handshake issue (Server Certificate request)

> From: openssl-users [mailto:[hidden email]] On
> Behalf Of Bashin, Vladimir
> Sent: Friday, February 07, 2020 11:25

> ... during that handshake the TLS server requests the client
> Certificate but our TLS client responds with the Certificates Length 0
> that causes the TLS server to respond with the Handshake Failure.

This means your client can't find a certificate to send. Usually this means that it doesn't have a certificate that:

- is among the ones it's been told, in some application-specific manner, it can use as a client certificate;
- it has the corresponding private key for;
- is valid (not expired, etc.);
- has the appropriate purpose (X.509v3 Extended Key Usage, if present, includes TLS Web Client Authententication), if the application makes this check;
- and meets the requirements listed in the server's CertificateRequest message

Note that last point. The CertificateRequest sent by the server specifies requirements and hints for the client certificate, as described below.

Also note that here "application" refers to both the end application and whatever TLS implementation it's using. Some TLS implementations do most or all of the certificate-selection work for the end application; others don't.

> ... that could be happening in case the client's certificate does not
> match the server certificate

No, the client certificate doesn't have to match anything in the server certificate. What it has to satisfy are the CertificateRequest parameters.

See RFC 5246 (TLSv1.2) section 7.4.4. CertificateRequest contains three fields:

1. certificate_types, which is a list of certificate "types", by which the authors mean the kind of public key the certificate uses. The RFC specifies four possible values, but two of them are redundant (for historical reasons), so basically this comes down to RSA and/or DSA. RFC 8422 added ECDSA, and there are some less-common variants.

2. supported_signature_algorithms, which is a list of the signature-and-hash-algorithm pairs the server supports for client certificates. These are integer value pairs which are defined to represent algorithm pairs such as {sha1, rsa}. The RFC and its successors specify the standard values at the time each RFC is published, and IANA maintains the current list.

3. certificate_authorities, which is a list of distinguished names.

If the client sends a certificate, it MUST use a public key that matches one of the types in #1, and a signature algorithm that matches one of the pairs in #2.

The client MAY attempt to find a certificate signed by one of the authorities listed in #3. In practice, many client applications will honor this list, to the point of not sending a certificate at all if they don't have one signed by a CA on the server's list.

So you need to know what's in that CertificateRequest message. Since it's encrypted, you'll probably have to get either the server or the client to log it. Or maybe the client can be configured to log why it couldn't find a suitable client certificate.

Short version: TLS PKI is difficult. It's so difficult, and so security-critical, that I don't recommend people try to configure it without an expert. Unfortunately experts are hard to come by. (I'm certainly not one, despite having worked with TLS for a couple of decades now, and taken courses on it, and read books and other references...)

--
Michael Wojcik