PRODUCT ADVISORY: Pre 6.3, Splunk Enterprise, Splunk Light and HUNK default root certificates expire on July 21, 2016.
(Updated: May 19, 2016)
Instances of Splunk Enterprise, Splunk Light and HUNK that are older than 6.3 AND that are using the default certificates will no longer be able to communicate with each other after July 21, 2016 unless the certificates are replaced OR Splunk is upgraded to 6.3 or later.
Please note that for all Splunk Enterprise versions, the default root certificate that ships with Splunk is the same root certificate in every download.
That means that anyone who has downloaded Splunk has server certificates that have been signed by the same root certificate and would be able to authenticate to your certificates. To ensure that no one can easily snoop on your traffic or wrongfully send data to your indexers, we strongly recommend that you replace them with certificates signed by a reputable 3rd-party certificate authority.
Failure to replace expired certificates prior to this will result in the immediate cessation of network traffic for any connection which uses them.
Expiration of Splunk certificates does not affect:
1) Splunk instances that are in Splunk Cloud
2) Splunk instances that use certificates that are internally generated (self-signed) or obtained from an external Certificate Authority (CA).
3) Splunk instances in your configuration that are upgraded to 6.3 or above and use that version’s root certificates.
4) Splunk instances that do NOT use SSL - (This is the default configuration for forwarder to indexer communication)
Certificate expiration DOES affect Splunk deployments where:
Any or all Splunk instances in your deployment run a release prior to 6.3 and use Splunk default certificates. This includes
There are several options that you can take to resolve certificate expiration. You must take action prior to July 21, 2016.
1) Remain at your current Splunk version (pre- 6.3) and manually upgrade the current default root certificates with the provided shell script that is appropriate for your operating system. Note that the shell script only replaces the current default root certificate with a new (cloned) certificate with a future expiration date. The script does not replace a Splunk default certificate with your own certificate.
The script is available at:
Update: minor script changes to update messages and remove redirect of stderr to /dev/null when checking OpenSSL version
Please be sure to read the README.txt included in the zip file before running the script.
2) Upgrade all Splunk instances in your environment to 6.3 or above and use self-signed or CA-signed certificate. We strongly recommend this as the most secure option. Replace current default root certificates with your own certificates. Download the following document to learn about hardening your Splunk infrastructure:
3) Remain at your current Splunk version (pre- 6.3) and use self-signed or CA-signed certificate. Replace current default root certificates with your own certificates. Download the following document to learn about hardening your Splunk infrastructure.
4) Upgrade ALL Splunk instances to 6.3 or above and use those default root certificates.
Note: Prior to the upgrade, if in use please remove the existing Splunk default certificate copies of ca.pem and cacert.pem
Refer to: Upgrading my Splunk Enterprise 6.2.x to 6.3.x did not upgrade the expiration dates on my default SSL...
See the following link to learn about adding certificates:
Securing Splunk Enterprise
Use the following procedure to configure default certificates:
Configure Splunk forwarding to use the default certificate
Regarding option #2 above, I'm a big fan of http://conf.splunk.com/session/2015/conf2015_DWaddle_DefensePointSecurity_deploying_SplunkSSLBestPra... / http://conf.splunk.com/session/2015/recordings/2015-splunk-115.mp4 which goes through the whole process of removing self-signed certs from end to end.
We've struggled to get end to end ssl working. So many things broke that getting the perfect order for every single instance across the organisation timed exactly right was impossible. As such we had to use the default certificates that came with the product.
We're now in a worse position were we are going to lose a significant volume of data as forwarding hosts will be lost after this date as we don't have contact information for the teams that own those devices (they had project defined requirements to install a forwarder at the time).
There are going to be some very pissed off people because of this.
How about server certificate(server.pem) ?
Only required action is replacing default root certificate ?
It seems that the script includes the option to replace the server certificate(s-renewcertssh -serverCert) , but what you mentioned above is only root certificate.
Yes, I too have the same query.
script execution says :
At least one of -defaultCA, -liveCA, or -serverCert is required;
order should be -defaultCA, -liveCA, -serverCert.
after providing the "-serverCert" as argument ., no change in the server cert it still shows the older expiry date before I ran the script.
Will there be a problem with forwarders running pre-6.3 sending data when the indexers and other infrastructure components are already at 6.3 or later?
I second this question. Further, I am curious if it's a problem for Forwarders on a version prior to 6.3 where you are not using SSL communication between the Forwarders and Indexers. Or in other words, does the root cert expiring cause splunkd to not function even while not using SSL features?
This is what my exact doubt..!!
Can anyone reply for this???
Pre-6.3 forwarders that are configured to use the default certificates will be impacted. If you are not using SSL, you will not be impacted by expiring root certs.