Log Insight 4.0 changed the default option of “ssl” from off to on as I covered in this post. Using encryption by default is a best practice, but you should be aware of the four SSL parameters that can be set in the [server] section of the Log Insight agent configuration. Read on to learn more!
Behavior
The vRealize Log Insight Agent stores certificates and uses them to verify the identity of the server during all but the first connection to a particular server. If the server identity cannot be confirmed, the vRealize Log Insight Agent rejects the connection with server and writes an appropriate error message to the log file:
2016-12-11 16:57:10.591208 0x00007f19cb29a700 <warng> SSLVerifyContex:153| Certificate pre-verify error = 19. self signed certificate in certificate chain. 2016-12-11 16:57:10.591768 0x00007f19cb29a700 <error> CurlConnection:844 | CurlConnection::Connect transport error: Peer certificate cannot be authenticated with given CA certificates
Certificates received by the Agent are stored in cert folder:
- Windows = C:\ProgramData\VMware\Log Insight Agent\cert
- Linux = /var/lib/loginsight-agent/cert
Rules
- If the vRealize Log Insight Agent has a locally stored self-signed certificate and receives a different valid self-signed certificate with the same public key, then the agent accepts the new certificate. This can happen when a self-signed certificate is regenerated using the same private key but with different details like new expiration date.
- If the vRealize Log Insight Agent has a locally stored self-signed certificate and receives valid CA-signed certificate, the vRealize Log Insight Agent silently replaces new accepted certificate.
- If the vRealize Log Insight Agent receives a self-signed certificate after having a CA-signed certificate, the Log Insight Agent rejects it. The vRealize Log Insight Agent accepts self-signed certificate received from vRealize Log Insight Server only when it connects to the server for the first time.
- If the vRealize Log Insight Agent has a locally stored CA-signed certificate and receives a valid certificate signed by another trusted CA, the Agent rejects it.
Parameters
ssl_ca_path
This specifies the location of the trusted root certificates on the client system. By default, the agent looks in the following locations:
- Windows: System root certificate stores (no way to change)
- Linux
- /etc/pki/tls/certs/ca-bundle.crt
- /etc/ssl/certs/ca-certificates.crt
IMPORTANT: Some versions of Linux do not include either file specified above (e.g. SLES 11). If you need to generate this file, you can use the script provided here. Be sure to name the file according to the standards above unless you plan to define the ssl_ca_path yourself.
ssl_accept_any=no and ssl_accept_any_trusted=no
Based on the SSL rules defined about, the Log Insight agent will only accept:
- The first self-signed certificate it receives (by default, the Log Insight server ships with a self-signed certificate)
- Another self-signed certificate with the same public key as the first self-signed certificate
- The first trusted certificate as defined by the ssl_ca_path parameter
- The first trusted certificate as defined by the ssl_ca_path parameter after the first self-signed certificate
If you change from:
- One self-signed certificate to another with a different private key
- One trusted certificate to a self-signed certificate
- A different trusted certificate after the first trusted certificate
Then the Log Insight agent will not accept the change unless:
- The ssl_ca_path specified includes the self-signed certificate (which it will not by default).
- The ssl_accept_any is set to “yes”. This option can get around all three limitations, but at the expense of security. It is recommended that you DO NOT change this setting.
- The ssl_accept_any_trusted is set to “yes”. This will overcome the third limitation defined above only. It is recommended that you DO NOT change this setting.
NOTE: While not supported and not recommended, you can overcome all three limitations once more by removing the certificates listed in the cert directory of the agent.
ssl_cn
The default common name that the Log Insight agent expects is “VMware vCenter Log Insight”. If this common name does not match then the agent looks attempts to match the hostname field as defined in the [server] section of the Log Insight agent configuration.
NOTE: If the common name of the SSL certificate is based on a wildcard certificate (e.g. *.sflanders.net) then the agent will attempt to match based on the hostname field properly (e.g. li.sflanders.net will match).
If both attempts fail to match then the agent will deny the SSL certificate and not send events. If the common name is some other value, then you can define it with the ssl_cn option.
© 2017, Steve Flanders. All rights reserved.
thank you
You are welcome
Thank you for this post.
I have one question regarding Trust between vrli server & vrli agent installed on Windows OS having different ca authority.
Setup:- vrli 4.8 server with customised certificate from internal CA (CA01).
vrli agent has been installed on Windows server having different AD & different internal CA (CA02).
SSl is ON, meaning vrli server will not accept agent with untrusted certificates. I have installed the vrli server certificate & CA01 certificate in agent windows.
Still we are getting error for SSL certificate on agent. Do we need to add the CA02 certificate in vrli server ‘trusted root’ ?
Below are the logs from agent:
2019-12-17 11:13:33.171885 0x00001744 SSLVerifyContex:160| Certificate pre-verify error = 19 while trying connect to ‘10.109.255.107’. self signed certificate in certificate chain
2019-12-17 11:13:33.171885 0x00001744 CurlConnection:723 | Transport error while trying to connect to ‘10.109.255.107’: SSL peer certificate or SSH remote key was not OK
2019-12-17 11:13:33.171885 0x00001744 CFApiTransport:108 | Postponing connection to 10.109.255.107:9543 by 292 sec.
2019-12-17 11:18:39.134338 0x00001744 CFApiTransport:128 | Re-connecting to server 10.109.255.107:9543
2019-12-17 11:18:39.165584 0x00001744 SSLVerifyContex:160| Certificate pre-verify error = 19 while trying connect to ‘10.109.255.107’. self signed certificate in certificate chain
2019-12-17 11:18:39.165584 0x00001744 CurlConnection:723 | Transport error while trying to connect to ‘10.109.255.107’: SSL peer certificate or SSH remote key was not OK
2019-12-17 11:18:39.165584 0x00001744 CFApiTransport:108 | Postponing connection to 10.109.255.107:9543 by 216 sec.
“self signed certificate in certificate chain” sounds like the wrong certificate is being detected. As I recall, you can specify exactly where the certificate is and which exact one to use. Check the documentation on how to set these options and see if it helps.