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!
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
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