![]() ![]() The Subject Alternative Name(s) (SAN) are crucial for proper implementation if you turn on TLS verification.Check the Not Before and Not After fields displayed on the certificate. Matching is called being self-signed and will make the certificate invalid. The CN of a server certificate cannot match the CN of its issuer certificates.Also, do not put a passphrase on the private key if you plan to use requireClientCert=true! Do not lose this, because the certificate won’t work without it. The private key used in the CSR is required only on the system that the certificate is for (not the issuer, not clients connecting to it, etc).When generating the CSR, there are a few important items to be aware of: The CSR must be signed by an issuer certificate in order to become a leaf (client/server) certificate. You should place the server/client certificate and private key in one file, and all of your issuer certificates in another file.Ī CSR contains information about a specific server or subset of servers. In Splunk we automatically create the chain by using the client/ serverCert and sslRootCAPath values automatically, so you should not create a "full chain certificate". A certificate chain is a leaf certificate that has the proper issuer certificates under it in a single file. You’ll also often hear the term “(full) certificate chain” when reading about TLS.You might hear these referred to as forwarder certificates in the Splunk ecosystem. They only need to be signed by an issuer that the Splunk platform server trusts. These are called client certificates because they don’t need to represent (the CN/SAN) the system they’re installed on. Universal forwarders (or web browsers, if desired) use client certificates.You can also put multiple hosts in the SAN, but this can become difficult to manage or update compared to a wildcard. Splunk platform allows wildcard CN/SANs to be used. Splunk platform systems use server certificates, meaning the certificate should represent the system(s) in the Subject Alternative Name (SAN) line and Common Name (CN) value.They are often referred to as client or server certificates because that’s generally what they represent, but these are not technical TLS terms. Leaf means that the certificate is unable to sign any additional certificates. The verification works by checking the issuers of the presented certificate and seeing if they are in the CA bundle. The bundle initiates a connection to a remote system (A -> B) with sslVerifyServerCert or to respond to a remote system that initiated the connection (A <- B) with requireClientCert. This is a single file ( sslRootCAPath) that contains all your issuer certificates. In Splunk platform, when TLS verification is enabled, the system will refer to its “CA Bundle”.“Issuing” and “signing” are done using Certificate Signing Requests (CSRs).A root certificate can issue a leaf certificate directly, and this is allowed in Splunk platform. This improves security however, intermediates are not required. ![]() A root certificate is most often used to issue intermediate certificates, and then the intermediate is used to issue leaf (client/server) certificates.The terms “issuer certificate” and “certificate authority” can be used interchangeably. They don’t represent a system or set of systems instead they represent a trusted authority on verification. These are your root and intermediate certificates. Issuer certificates & certificate authorities Enable TLS verification: How to enable verification for deployment server connections and TLS forwarding.Then, you'll harden the environment with TLS verification settings. You'll start by putting certificates in place and enabling TLS across various configuration files (management, forwarding, and web). How to secure Splunk platform with TLS: A phased process to secure your environment with TLS.Common OpenSSL error outputs: How to remediate when the connection with OpenSSL hangs, or when you receive the error messages "Unable to get local issuer", "Self-signed certificate in chain" or "Key values mismatch".Using OpenSSL commands: How to use OpenSSL to test TLS connectivity, view a certificate, verify that the private key and certificate match, build your certificate chain, and verify your certificate chain.TLS basics: High-level TLS concepts you need to know.This article is split into a number of different sections: A robust TLS setup ensures your connections are encrypted and reduces the risk of man-in-the-middle attacks for your SIEM. To maximize the security of your Splunk platform environment, implementing TLS correctly is essential. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |