Security

Splunkd SSL and Subject Alternative Names

mgaraventa_splu
Splunk Employee
Splunk Employee

Will splunk forwarders respect Subject Alternative Names in indexer ssl certs when configured to verify the common name of the indexer? I.e. Indexer's common name is indexerA, with SAN of indexerB, and forwarder is configured to check for common name of indexerB, will the forwarder be able to connect and forward logs to this indexer?

Thanks!

0 Karma
1 Solution

mgaraventa_splu
Splunk Employee
Splunk Employee

If you would like to use the "Subject Alternate Names" in SSL certificates, then Splunk provides following parameters which should cover the use-case you are referring to:

outputs.conf:

sslAltNameToCheck = <string> 
* Check the alternate name of the server's certificate against this name. 
* If there is no match, assume that Splunk is not authenticated against this server. 
* You must specify this setting if sslVerifyServerCert is true. 

sslVerifyServerCert = [true|false] 
* If true, you must make sure that the server you are connecting to is a valid one (authenticated). 
* Both the common name and the alternate name of the server are then checked for a match. 
* Defaults to false. 

More details here:

http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Outputsconf

In addition in server.conf:

sslAltNameToCheck = <alternateName1>, <alternateName2>, ... 
* If this value is set, and 'sslVerifyServerCert' is set to true, 
splunkd will also be willing to verify certificates which have a 
so-called "Subject Alternate Name" that matches any of the alternate 
names in this list. 
* Subject Alternate Names are effectively extended descriptive 
fields in SSL certs beyond the commonName. A common practice for 
HTTPS certs is to use these values to store additional valid 
hostnames or domains where the cert should be considered valid. 
* Accepts a comma-separated list of Subject Alternate Names to consider 
valid. 
* Items in this list are never validated against the SSL Common Name. 
* This feature does not work with the deployment server and client 
communication over SSL. 
* Optional. Defaults to no alternate name checking 

sslVerifyServerCert = true|false 
* Used by distributed search: when making a search request to another 
server in the search cluster. 
* Used by distributed deployment clients: when polling a deployment 
server. 
* If this is set to true, you should make sure that the server that is 
being connected to is a valid one (authenticated). Both the common 
name and the alternate name of the server are then checked for a 
match if they are specified in this configuration file. A 
certificiate is considered verified if either is matched. 
* Default is false. 

More details here:

http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Serverconf

View solution in original post

mgaraventa_splu
Splunk Employee
Splunk Employee

If you would like to use the "Subject Alternate Names" in SSL certificates, then Splunk provides following parameters which should cover the use-case you are referring to:

outputs.conf:

sslAltNameToCheck = <string> 
* Check the alternate name of the server's certificate against this name. 
* If there is no match, assume that Splunk is not authenticated against this server. 
* You must specify this setting if sslVerifyServerCert is true. 

sslVerifyServerCert = [true|false] 
* If true, you must make sure that the server you are connecting to is a valid one (authenticated). 
* Both the common name and the alternate name of the server are then checked for a match. 
* Defaults to false. 

More details here:

http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Outputsconf

In addition in server.conf:

sslAltNameToCheck = <alternateName1>, <alternateName2>, ... 
* If this value is set, and 'sslVerifyServerCert' is set to true, 
splunkd will also be willing to verify certificates which have a 
so-called "Subject Alternate Name" that matches any of the alternate 
names in this list. 
* Subject Alternate Names are effectively extended descriptive 
fields in SSL certs beyond the commonName. A common practice for 
HTTPS certs is to use these values to store additional valid 
hostnames or domains where the cert should be considered valid. 
* Accepts a comma-separated list of Subject Alternate Names to consider 
valid. 
* Items in this list are never validated against the SSL Common Name. 
* This feature does not work with the deployment server and client 
communication over SSL. 
* Optional. Defaults to no alternate name checking 

sslVerifyServerCert = true|false 
* Used by distributed search: when making a search request to another 
server in the search cluster. 
* Used by distributed deployment clients: when polling a deployment 
server. 
* If this is set to true, you should make sure that the server that is 
being connected to is a valid one (authenticated). Both the common 
name and the alternate name of the server are then checked for a 
match if they are specified in this configuration file. A 
certificiate is considered verified if either is matched. 
* Default is false. 

More details here:

http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Serverconf

Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...