[Action required] Replace your Logz.io data shipping certificates before May 28
Scheduled Maintenance Report for logz.io
The scheduled maintenance has been completed.
Posted May 28, 2020 - 20:59 IDT
In progress
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Posted May 28, 2020 - 16:25 IDT
What's happening?
To support encrypted shipping of your logs and metrics, shipping methods over SSL/TLS use a public certificate that's authenticated by a trust chain, issued by a certificate authority. Lower protocols like TCP need guidance on "who to trust". That guidance includes a certificate that you install in your environment. All this is so your data can be read by Logz.io, only after you can be sure we are who we say we are.

At the end of May, this chain of trust expires, and we need to rotate certificates so you can keep sending your data without any issues.

To make sure there's a smooth transition, we'll rotate certificates and establish a new chain of trust a few days early. This new chain won't expire until 2038.

This means you'll need to update any of your data shipping configurations that make use of our certificate chain.
IMPORTANT: Configurations need to be updated before May 28 to avoid disruptions in sending your data to Logz.io.

What's affected?
Many of the shipping methods covered in the Logz.io docs are affected, but not all. This does not affect data that you're sending unencrypted or with higher protocols.

This could affect you if any of these are true:
- You're sending data using any Beats shippers (such as Filebeat, Metricbeat, or Winlogbeat)
- You're sending data with Logstash over SSL
- You've deployed our Docker images or Kubernetes configmaps
What this does not affect:
This does not affect data sent over HTTP or HTTPS, including bulk shipping. This also does not affect any of the code libraries covered in the docs.

How do I update my certificates?
The actions you need to take depend on how you're shipping your data. The lists below show the docs that include information on updating your certificates. You can find these docs here: https://docs.logz.io/shipping/

You'll need to do this before May 28 to avoid disruptions. You can remove the old certificates only after June 5.

Affected log shipping methods:
- Filebeat
- Logstash
- Active Directory for Windows Server (Filebeat)
- Apache (Filebeat)
- auditd (Filebeat)
- Check Point (Filebeat)
- Cisco ASA Server (Filebeat)
- Docker
- Elastic container service
- Fail2ban (Filebeat)
- Falco (Filebeat)
- FortiGate (Filebeat)
- GitLab (Filebeat)
- HashiCorp Vault (Filebeat)
- Jenkins (Filebeat)
- JSON uploads
- Juniper SRX (Filebeat)
- Mcafee ePO (Filebeat)
- MySQL (Filebeat)
- Network devices (Filebeat)
- nginx (Filebeat)
- OSSEC (Filebeat)
- Palo Alto Networks (Filebeat)
- Puppet (Filebeat)
- Stackdriver
- Wazuh (Filebeat)
- Windows (Filebeat)
- Windows Defender (Filebeat)
- Zeek (Filebeat)

Affected metrics shipping methods:
- Azure Monitor metrics (Metricbeat)
- Docker
- EC2 Auto Scaling
- EC2
- Kubernetes metrics (Metricbeat)
- Lambda
- S3
- System metrics (Metricbeat)

I use a different solution for sending data. Does this affect me?
This may affect custom or third party solutions that aren't covered in the docs. If you send any data to Logz.io over TCP, check your configurations. If they use our trust chain, update them before May 28 to use the old and the new certificates.

You can download the new public certificate from here:

How can I be sure my configuration change works?
Starting Monday, May 18th, we'll open up test data receivers so you can confirm the new configurations will work after we switch to the new chain of trust.

You can test your new configuration by temporarily pointing your shipper to a testing URL for your region (in the table below). You'll know the configuration is good (and that it will work after May 28) if you see the data coming into your account.

After you've confirmed the configuration is good, revert your shipper to the production URL for your region.

US East (Northern Virginia): Test using listener-us-catest.logz.io
Asia Pacific (Sydney): Test using listener-au-catest.logz.io
Canada (Central): Test using listener-ca-catest.logz.io
Europe (Frankfurt): Test using listener-eu-catest.logz.io
West Europe (Netherlands): Test using listener-nl-catest.logz.io
Europe (London): Test using listener-uk-catest.logz.io
West US 2 (Washington): Test using listener-wa-catest.logz.io

We know we're an important part of your work and we want to make sure all your data stays available to you.

If you have any questions, your Customer Success Engineer and the Support team (help@logz.io) are here to help.
Please reach out any time.
Posted May 14, 2020 - 22:53 IDT