Documentation forLoggly

Upgrade SSL Certificate – Frequently Asked Questions

1. Do I need to change anything right now?

  • No. You will need to update your configuration in the future to ensure that the CA root certificate remains valid (as it has its own expiration date). We strongly advise to use the system trust store of CA certificates usually located in /etc/ssl/certs/ca-certificates file.

2. What should I do when my logs are not being sent?

  • Check if there aren’t SSL verification errors on the client side, in /var/log/syslog
  • If you are using rsyslog follow our documentation to change the $DefaultNetstreamDriverCAFile to the $DefaultNetstreamDriverCAFile /etc/ssl/certs/ca-certificates.crt
  • Restart rsyslog.

3. Why will I need to eventually update my configuration?

  • The client must provide an anchor for verification process of the SSL certificate chain (the CA Root certificate itself).
  • To-date, this was provided by the SolarWinds Loggly team in the form of the whole certificate chain that the customer needed to download and configure their systems.
  • Now it should be provided by the OS certificate store instead, so that this information is always up to date and dependent only on the update cycle of the client system.
  • You can make sure you have the certificates updated by installing on Debian/Ubuntu systems a package apt-get install ca-certificates

4. Why does it work now even though I haven’t changed the configuration yet?

  • We are now sending our SSL certificate + all the Intermediate certificates in the chain when the TLS connection is initiated to the Collector endpoints.
  • From now on the client side needs only the CA root certificate in their Syslog configuration to complete the chain. As long as the chain is correct the verification will succeed. It is still correct because the CA and Intermediate are still valid and they didn’t change with updating the certificate on our side.
  • Previously we only sent our SSL certificate without any Intermediates and therefore the client side needed the full certificate chain bundle to correctly verify the chain. If the customer doesn’t have the correct chain provided by us, the verification process failed and communication stopped working.
  • These root CA certificates (for all globally trusted CAs) are usually stored in OS wide trust stores that are available to applications (e.g. /etc/ssl/certs/ca-certificates). The clients should therefore leverage this path instead of our custom file.
  • On the Linux platform some applications like logspout or syslog-ng are already leveraging this path by default. On the other hand, rsyslog needs a specific configuration setting to be present in it’s configuration file.
  • On the Windows platform you have to update your configuration for NXLog due to the way Windows OS provides the OS-wide certificate store (CryptoAPI) which NXLog does not use.

Troubleshooting Your Rsyslog TLS Configuration

  • Wait a few minutes in case indexing needs to catch up
  • Make sure you restarted rsyslog
  • Troubleshooting Rsyslog if the files are being written but not being sent to Loggly
  • Search or post your own Rsyslog TLS questions in the community forum.

Operating Systems that do not Fully Support TLS 1.1 or 1.2 (CentOS 5, RHEL5, etc)

Customers that are running Operating Systems that do not fully support TLS 1.1 or 1.2 have a few options to ensure their logs continue to flow to Loggly.

  • For traffic that does not need to be encrypted, customers can switch back to non-encrypted syslog traffic on these Operating Systems.
  • For traffic that requires encryption, customers can configure their application to send to our HTTP(S) endpoint via our RESTful API.
  • Customers can upgrade to an Operating System that does support a version of OpenSSL that supports TLS 1.1 or 1.2, for example, CentOS 6.