Related Answers
Download topic as PDF
How to prepare your signed certificates for Splunk authentication
Once you have your certificates, you must combine the server certificate and your keys into a single file that Splunk software can use.
If you do not have your certificates and need help getting them, we provide some basic examples using OpenSSL in the following topics:
Note: Make sure your certificates and public key are in x509 format and that your private key is in RSA format.
Create a single PEM file
Combine your server certificate and public certificate, in that order, into a single PEM file.
For the examples here, we are using the file names described in "How to self-sign certificates" and "How to get certificates signed by a third party."
The following is an example for *nix:
cat myServerCertificate.pem myServerPrivateKey.key myCACertificate.pem > myNewServerCertificate.pem
The following is an example for Windows:
>type myServerCertificate.pem myServerPrivateKey.key myCACertificate.pem > myNewServerCertificate.pem
Once created, the contents of the file myNewServerCertificate.pem should contain, in the following order:
- The server certificate (
myServerCertificate.pem) - The private key (
myServerPrivateKey.key) - The certificate authority public key (
myCACertificate.pem)
Here's an example of a properly concatenated certificate:
-----BEGIN CERTIFICATE-----
MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
...
<Server Certificate>
...
8/PZr3EuXYk1c+N5hgIQys5a/HIn
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,CFCECC7976725DE5
S+DPcQ0l2Z1bk71N3cBqr/nwEXPNDQ4uqtecCd3iGMV3B/WSOWAQxcWzhe9JnIsl
...
<Server Private Key – Passphrase protected>
...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
...
<Certificate Authority Public Key>
...
8/PZr3EuXYk1c+N5hgIQys5a/HIn
-----END CERTIFICATE-----How to configure certificate chains
To use multiple certificates, append the intermediate certificate to the end of the server's certificate file. You can add as many certificates you need to in decreasing order of hierarchy, up to the root.
The certificates should be concatenated in the following order:
[ server certificate] [ intermediate certificate] [ root certificate (if required) ]
So for example, a certificate chain might look like this:
-----BEGIN CERTIFICATE----- ... (certificate for your server)... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... (the intermediate certificate)... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... (the root certificate for the CA)... -----END CERTIFICATE-----
In another example, when using Splunk Forwarder to Indexer Certificates that contain a Private Key, the completed certificate file might look like this :
-----BEGIN CERTIFICATE----- ... (certificate for your server)... -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- ...<Server Private Key – Passphrase protected> -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... (certificate for your server)... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... (the intermediate certificate)... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ... (the root certificate for the CA)... -----END CERTIFICATE-----
Next steps
Now that you have the certificates you need, you must configure Splunk software to find and use them:
- See "Configure Splunk forwarding to use your own certificates" to learn more about configuring certificate authentication for forwarding.
- See "About securing inter-Splunk communication" to learn more about configuring certificate authentication for inter-Splunk communications.
|
PREVIOUS Configure allowed and restricted SSL versions |
NEXT Determine your cipher suite |
This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.3.0, 7.3.1
Comments
I agree with Frank's comments whole heartedly. Additionally, you should be aware that the methods for preparing the cert for splunkd (server.conf) and splunkweb (web.conf) are different. This shows off the combination of the server cert and key method which is required when configuring it for splunkd. The splunkweb method has you have the private key and the server cert (public key) in two separate file objects which are referenced separately in the config file.
This document instructs to merge the private key into the server certificate .pem file. Consecutive documents instruct to deploy the server certificate .pem file onto clients. I assume the clients need this cert in order to trust it, but the server's private key should never be stored outside the server like that.
I know the instructions also mention to password protect the key, but still, this whole approach of copying .pem files that include a private key, to the clients goes against the basic principles of public key crypto...
It would be much better if the documentation would instruct to only copy the server certificate itself (and CA certs) to the clients, not including the private key. Or the documentation must provide a clear note on the importance of a strong passphrase, as the whole security of the communication now depends on that, since private keys stored on clients are much more likely to get compromised.
The use of a combined key/certificate file is a burden. certmonger can manage keys and certificates automatically, but it keeps the keys and certs separate (as appropriate since one is private and the other public). This make it very difficult to manage the splunkd and forwarder keys automatically.