SSL Client Certification Alert 46 Unknown CA

[NUCUSER]

We are seeing 'Alert 46 Unknown CA' as part of the initial TLS handshake between client & server. From a wireshark capture, the 1st Client Hello is visible, followed by the 'server hello, certificate, server key exchange, certificate request, hello done'. As part of this exchange, TLS version 1.2 is agreed, along with the agreed cypher. The next packet in the flow is an ACK from the source, followed by Alert (Fatal), Description: Certificate Unknown. I cannot see anywhere in the capture a certificate provided by the client

This behaviour occurs regardless of the client authentication/client certificate setting (ignore/request/require).

I have ran openssl s_client -connect x.x.x.x:443 as a test (from the BIG-IP) and I see the server side certs and 'No client certificate CA names sent' which is expected as no client cert sent.

The end client has not reinstalled the client certificate as yet (3 day lead time).

Are there any additional troubleshooting steps I can undertake to confirm the client is either rejecting the server certificate and therefore not returning the client certificate?

Kind Regards

[SanjayP · Accepted solution]

Cool. If it's a web based application and browser is the client then yes it would be present. But if it's API call with server to server communication they might need to install it explicitly.

​Also, other thing I would check on the F5 clientssl profile, if CA cert is correctly added to the chain (in case it's not bundled with the server cert)? Meanwhile, please verify that part as well.

[Lidev]

Hi,

You can try to decode TLS records with SSL dump to better understand the root cause and see which part fail.

Please refer below link to get information :

K10209: Overview of packet tracing with the ssldump utility

Also, uncheck the Generic Alert options on your Client SSL profile and increase the log level SSL on your F5 to obtain perhaps more details in the ltm log.

Regards

[NUCUSER]

Hi Lidev

I already tried SSL dump and it did not appear to provide any more data than a standard wireshark capture. I will revisit.

Generic alerting is disabled/unchecked. The only alerts I see are generic SSL handshake failed messages for TCP source > dest (status code 1260013)

Thanks

[Lidev]

Have you try to enable SSL debug logging on the BIG-IP ?

tmsh modify /sys db log.ssl.level value Debug

[NUCUSER]

Hi, we are running version 15 so low level debugging is enabled by default. I did try via tosh and it provided no additional logging

Thanks

[SanjayP]

Please check if client has server certificate's CA (intermediate certificate) installed in it's trust store. If not, please share the CA cert (public key of the intermediate certificate) to the client so that it can trust the server certificate. ​

[NUCUSER]

Hi Sanjay, Thanks. We have asked the client to confirm however intermediate cert is digicert so would expect they have.

[SanjayP · Accepted solution]

Cool. If it's a web based application and browser is the client then yes it would be present. But if it's API call with server to server communication they might need to install it explicitly.

​Also, other thing I would check on the F5 clientssl profile, if CA cert is correctly added to the chain (in case it's not bundled with the server cert)? Meanwhile, please verify that part as well.

[NUCUSER]

Hi Sanjay, is there anyway to test confirm the certificate chain on the server side?

The SSL certificate chain comprises of /common/wildcard.company123.com.crt/Common/wildcard.company123.com.key /Common/digicert_inter.crt

The Intermediate CA chain is specified in the client ssl profile (trusted certificate authorities) is XYX_Int_CA_Chain.crt. This crt is present on the F5 along with the wildcard.company123.com.crt cert

Thanks

[SanjayP]

Yes, if VIP is internet facing easy way would be to check on https://www.sslshopper.com/ssl-checker.html It would show if chain is correctly installed.

 

Other way would be to check on the browser itself and it should show the error if chain is not correctly installed (something sort of it can't trust the authority of the certificate)

[NUCUSER]

Thanks - this check comes back as all good.

[SanjayP]

cool and any feedback on the client end if they have intermediate CA installed on their end?

[NUCUSER]

client have found a 'possible' cause, waiting on further info from client. Will keep you posted - tks for your steer..

[jaikumar_f5]

 ,

This is a client side issue for not having the required intermediate or root certificate in the trust store of client machine. In LTM you'll just SSL Handshake failed logs, but in pcap you'll see this, alert coming from Client to LTM, SSL Fatal alert, RST.

level          fatal,   

value          unknown_ca

Work with your client support team & have required keystore updated.

[NUCUSER]

cheers..

[SanjayP]

Root certificate is not needed on the client end it's just a intermediate CA cert.

[NUCUSER · Accepted solution]

Update - Thanks for all your suggestions, most helpful!! This turned out to be a client side cert password issue, client cert re-installed and now working.

[Rebecca_Moloney]

Glad you were able to find a solution! Just popping in after the fact to share a few popular TLS related DevCentral articles in case anyone finds them helpful: 

Decrypting TLS traffic on BIG-IP 

TLS Stateful vs Stateless Session Resumption

What is Mutual TLS (mTLS)?