message "did not match any allowed names" is output to splunkd.log.

[OGS]

Splunk 9.4.2

I'm investigating communication between the LicenseMaster and Indexer (LMTracker).
Please tell me about SAN authentication.

hostname: Connection is successful.

[sslConfig]
sslAltNameToCheck = license-1

IP: Connection fails.

[sslConfig]
sslAltNameToCheck = xx.xx.xx.10

*The destination license-1 has already been configured with indexer-1 information.

If the connection fails, the splunkd.log displays the message "did not match any allowed names."

08-18-2025 07:01:17.784 +0000 ERROR X509 [88364 LMTrackerExecutorWorker-0] - X509 certificate (CN=license-1,OU=XXX,O=XXX,L=XXX,ST=XXX,C=XX) alternate name (license-1,localhost) did not match any allowed names (,xx.xx.xx.10)

The certificate's "Subject Alternative Name" is as follows:

$ sudo openssl x509 -in /opt/splunk/etc/auth/mycerts/license-1.pem -noout -text | grep -A1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
DNS:license-1, DNS:localhost, IP Address:xx.xx.xx.10

Splunk is using the "IP Address" in the SAN. Why isn't "Address:xx.xx.xx.10" being recognized?
Is it being recognized, but just not being output as a log?
Please let me know if there is anything I should review.

I use Google Translate to translate Japanese into English.

[OGS]

@livehybrid
@PickleRick

Thanks for your answer.

I'll share some further findings.

When used in conjunction with sslCommonNameToCheck, the "did not match any allowed names" message is sometimes not output.

No error.

sslCommonNameToCheck = license-1 #present in CN and SAN
sslAltNameToCheck = xx.xx.xx.10 #IP present in SAN

This pattern also produces no error.

sslCommonNameToCheck = license-1 #present in CN and SAN
sslAltNameToCheck = xx.xx.xx.100 #IP not present in SAN

I may have misinterpreted this due to an insufficient translation.
I had interpreted the sslAltNameToCheck setting as immediately terminating communication if there was a mismatch.

Is using ssl[Common/Alt]NameToCheck in conjunction with this setting correct?
As you all indicated, Splunk ignores IP addresses, but in the above pattern, did it switch to querying by CN?

[PrewinThomas · Accepted solution]

@OGS 

Yes. When sslAltNameToCheck fails but sslCommonNameToCheck succeeds, Splunk falls back to CN validation and allows the connection.

Best is to use DNS names in your SAN and match them with sslAltNameToCheck

Regards,
Prewin
If this answer helped you, please consider marking it as the solution or giving a Karma. Thanks!

[livehybrid]

Interestingly the docs do actually state 

The SAN can be a short host name or a fully qualified domain name.

so maybe it does have to be a DNS name?

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[livehybrid]

Hi @OGS 

Based on the docs and guides (https://lantern.splunk.com/Splunk_Platform/Product_Tips/Administration/Securing_the_Splunk_platform_...) it should be possible to use an IP address in a SAN within your cert, however as @PickleRick  it might not be something that can be verified against. It might be that only a DNS name can be used for the sslAltNameToCheck.

If you are using sslAltNameToCheck or sslCommonNameToCheck then do you need to validate against the IP address or are you able to use one of the other SAN from your cert as the sslAltNameToCheck (or the CN to match sslCommonNameToCheck)?

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[PickleRick]

Yes. You can issue a certificate with an IP property in the SAN extension. And (most?) browsers will accept it while verifying the connection to HTTP server.

But the question is whether Splunk itself will use it or not.

[PickleRick]

You might want to verify this with the support but it might be an issue of the IP address type of SAN. It's relatively rarely used and I suppose Splunk might be doing ony DNS-based SANs. If it is so, please post feedback to the docs website so that it's described more precisely.