You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The used winlogbeat version v7.5.2 is quite old and becomes Security Support EoL this June. The current stable version is 7.10.2 and should be downloaded via the install script.
The new version also allows “ssl.validation_mode: certificate”. This enables to check the BeaKer/Espy-side server certificate against a CA without requiring an actual matching FQDN in the certificate. It makes securing the communication between the winlogbeat and elasticsearch (in case of BeaKer) or redis (Espy) pretty straight forward, as the server side CA cert can just be included in the winlogbeat config and the server certificate is still considered valid when accessing it directly via IP address or any hostname/FQDN. In short: this makes secure TLS encryption possible without requiring customers to set up DNS entries, internal PKI configuration and manual setup of certificates on both ends.
So far I tested v7.10.2 with BeaKer and Espy configurations on a Windows-VM and have not observed any issues, yet. This also includes testing the TLS approach stated before with BeaKer using the automatically generated kibana CA. Checking this with Espy/Redis is still ongoing as your helper script (generate_tls_certs.sh) only generate a self-signed cert without a CA.
Cheers
Clemens
The text was updated successfully, but these errors were encountered:
The used winlogbeat version v7.5.2 is quite old and becomes Security Support EoL this June. The current stable version is 7.10.2 and should be downloaded via the install script.
The new version also allows “ssl.validation_mode: certificate”. This enables to check the BeaKer/Espy-side server certificate against a CA without requiring an actual matching FQDN in the certificate. It makes securing the communication between the winlogbeat and elasticsearch (in case of BeaKer) or redis (Espy) pretty straight forward, as the server side CA cert can just be included in the winlogbeat config and the server certificate is still considered valid when accessing it directly via IP address or any hostname/FQDN. In short: this makes secure TLS encryption possible without requiring customers to set up DNS entries, internal PKI configuration and manual setup of certificates on both ends.
So far I tested v7.10.2 with BeaKer and Espy configurations on a Windows-VM and have not observed any issues, yet. This also includes testing the TLS approach stated before with BeaKer using the automatically generated kibana CA. Checking this with Espy/Redis is still ongoing as your helper script (generate_tls_certs.sh) only generate a self-signed cert without a CA.
Cheers
Clemens
The text was updated successfully, but these errors were encountered: