• State Not Answered
  • Replies 1 reply
  • Subscribers 39 subscribers
  • Views 430 views
  • Users 0 members are here
Options
Related

Syslog validation certificate error

sabino giancristiano

Hello,

I'm currently receiving a certificate validation error when trying to connect from SPS to the syslog server (Certificate validation failed). I imported in the trust store the CA certificate, but the warning is still there, also if I remove the Check server certificate, I receive the logs on the splunk server, if I enable it I don't receive anything more.

Do you have any idea of the reason of this behaviour?

Thank you

Parents
  • 0

    Hey Sabino,

    Since it works with the check-off, TLS is fine — SPS is just rejecting the cert. Importing the CA usually isn't enough. Most likely causes:

    1. Name mismatch (most common): SPS checks that the cert's SAN/CN matches the destination address you configured. If you connect by IP but the cert only has an FQDN (or vice-versa), it fails. Match them, or reissue the Splunk cert with the right SAN.
    2. No SAN at all — CN-only certs are rejected. Reissue with a SAN.
    3. Incomplete chain — if signed by an intermediate, import root + intermediates, not just the root.
    4. CA not linked to this destination — confirm the destination's TLS settings point at the Trusted CA list you populated.
    5. Expiry/clock skew between SPS and Splunk.

    Quick diagnosis — check what Splunk actually presents:

    openssl s_client -connect <splunk-host>:<port> -showcerts

    Compare the leaf's Subject / SAN and issuer chain against the address you configured and the CA you imported. It's almost always #1 or #2.

Reply
  • 0

    Hey Sabino,

    Since it works with the check-off, TLS is fine — SPS is just rejecting the cert. Importing the CA usually isn't enough. Most likely causes:

    1. Name mismatch (most common): SPS checks that the cert's SAN/CN matches the destination address you configured. If you connect by IP but the cert only has an FQDN (or vice-versa), it fails. Match them, or reissue the Splunk cert with the right SAN.
    2. No SAN at all — CN-only certs are rejected. Reissue with a SAN.
    3. Incomplete chain — if signed by an intermediate, import root + intermediates, not just the root.
    4. CA not linked to this destination — confirm the destination's TLS settings point at the Trusted CA list you populated.
    5. Expiry/clock skew between SPS and Splunk.

    Quick diagnosis — check what Splunk actually presents:

    openssl s_client -connect <splunk-host>:<port> -showcerts

    Compare the leaf's Subject / SAN and issuer chain against the address you configured and the CA you imported. It's almost always #1 or #2.

Children
No Data