ERROR:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE: certificate verify failed

cancel
Showing results for 
Search instead for 
Did you mean: 

ERROR:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE: certificate verify failed

L4 Transporter

I have installed a Trap agent and certificate in Red Hat 6 successfully. But when I try to pull a Trap log. The error message occurs,  ERROR: 14090086: SSL routines: SSL 3_GET_SERVER_CERTIFICATE: certificate verify failed What could be for this error coming.   Linux error.jpg

3 REPLIES 3

L4 Transporter

Hi there,

 

Please see step 3 in the document listed at this URL:

 

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/get-started-with-cortex-xdr...

 

Do you know if the 3 certs are trusted on the Linux server in question?


David Falcon 
Solutions Architect, Cortex
Palo Alto Networks® 

L0 Member

Hello,

 

has anyone had luck installing Cortex Agent to Linux Mint 20? I have had no issues running Ubuntu Linux (20.04 LTS), but keep getting the "SSL Exception: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed" error on Mint.

Certificates are installed the same way as on Ubuntu, openssl verification to the server is successful.

 

Thanks, best regards

Martin

 

 

L0 Member

It's seems a problem between PA's kubernetes config and some version of openssl <1.1.1, because in 1.1.1 they change the behavior:

 

 

s_client will now send the Server Name Indication (SNI) extension by default unless the new "-noservername" option is used. The server name is based on the host provided to the "-connect" option unless overridden by using "-servername".

 


This works on modern distros (openssl > 1.1.0i) but not in Centos 6 (1.0.1e):
openssl s_client -connect distributions.traps.paloaltonetworks.com:443

 

 

CONNECTED(00000003)
depth=0 O = Acme Co, CN = Kubernetes Ingress Controller Fake Certificate
verify error:num=20:unable to get local issuer certificate
...

 

 

 


In Centos 6 you need to set the TLS SNI with -servername
openssl s_client -servername distributions.traps.paloaltonetworks.com -connect distributions.traps.paloaltonetworks.com:443

 

 

 

CONNECTED(00000003)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
...

 

 

 

 

Relevant info to fix this on the server side:
https://www.ssllabs.com/ssltest/analyze.html?d=distributions.traps.paloaltonetworks.com&latest

https://github.com/kubernetes/ingress-nginx/issues/1984

https://github.com/kubernetes/ingress-nginx/issues/6398

https://kubernetes.github.io/ingress-nginx/user-guide/tls/

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl

https://support.cloudbees.com/hc/en-us/articles/360019630132-Issue-connecting-External-Client-Master...

https://www.ibm.com/docs/en/cloud-paks/cp-management/1.3.0?topic=troubleshooting-key-management-serv...

 

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!