SSL tests for certificates

Use SSL tests in Splunk Synthetic Monitoring to monitor SSL/TLS certificates for expiration, issuer validation, and protocol compliance to ensure secure connections.

SSL tests are designed to proactively monitor and validate SSL/TLS certificates, ensuring secure connections for your services. They offer specialized checks for certificate expiration, issuer validation, self-signed status, and revocation. By providing visibility into the entire certificate chain, SSL tests help prevent outages and maintain the integrity of your cryptographic infrastructure.

Use cases for SSL tests

In an SSL test, you can do the following:

Proactively detect when SSL/TLS certificates are nearing their expiration date.
Verify that the certificate was issued by a trusted Certificate Authority (CA) and that its entire chain of trust (from the server certificate up to the root CA) is valid and correctly configured.
Assert that your servers are using strong, up-to-date TLS versions (e.g., TLS 1.2 or TLS 1.3) and are not falling back to deprecated or vulnerable protocols (like SSLv3 or older TLS versions).
Verify the public key algorithm used in the certificate (e.g., RSA, ECC) and potentially its strength (key size).
Identify instances where a server might be presenting an untrusted root or a self-signed certificate, which could indicate a misconfiguration, a development environment, or a potential security issue in a production environment.
Monitor metrics like TLS handshake time, DNS resolution time, and connection time.

What happens during an SSL test?

In an SSL test, Splunk Synthetic Monitoring establishes a direct TCP connection to a server to retrieve its SSL/TLS certificate chain. It then reports on the certificate's health, expiration status, and compliance with user-defined validation rules, alongside performance metrics like DNS, TCP connect, and TLS handshake times. This lets you to proactively monitor the validity and status of your SSL/TLS certificates to prevent potential outages or security issues before they impact users. For example, SSL tests can alert you to when you need to replace expiring certificates that could result in an outage or let you know when you are using an old TLS version with security vulnerabilities,

SSL tests for trusted and untrusted certificates

By default, SSL tests validate certificates signed by publicly recognized Certificate Authorities (CAs) such as DigiCert. The test involves verifying their expiration, trust chain, and revocation status. These tests are ideal for public-facing or production services such as websites and APIs and require no special configuration.

If your service uses a certificate issued by a Certificate Authority that is not publicly trusted (e.g., an internal corporate CA), you can upload the CA's root certificate (.pem file) to Splunk Synthetics. This allows the SSL test to explicitly trust certificates signed by that specific CA to ensure proper validation. See Use a global variable for a custom Certified Authority (CA) certificate.

For internal, development, or private environments that use self-signed certificates, SSL tests will fail by default. To allow these tests to pass, you must enable the Ignore self-signed certificate option to ignore the self-signed certificates.

SSL test validations

The SSL test validations provide essential checks to verify SSL/TLS certificate properties such as issuer name, algorithm, and self-signed status. The default test validations are run by default and ensure the authenticity and cryptographic strength of certificates, helping to detect common SSL issues. The validations enable users to maintain network trust and security with minimal configuration in SSL tests.


Validation	Description
Expired (Default)	Tests if the SSL certificate has already expired. If the certificate is expired, the test will automatically fail.
Untrusted Authority (Default)	Tests if there is an untrusted Certification Authority (CA) in the certificate chain. If an untrusted CA is detected, the test will fail automatically. This failure can be suppressed if the test is configured to allow self-signed certificates.
Self-Signed (Default)	Tests if the certificate is self-signed. If a self-signed certificate is detected, the test will fail automatically. This failure can be muted if the test is configured to allow self-signed certificates.
Revoked (Default)	Fails if the certificate was revoked by the issuer. This validation ensures that certificates revoked by the issuer are not trusted, enhancing security by preventing the use of compromised or invalid certificates. Here are the revocation checks: Performs revocation checks by querying the Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) from the issuer using the OpenSSL library. Verifies the certificate's serial number against the CRL database or OCSP response to determine if it has been revoked. Verifies if the certificate is found on the revocation list.
Expiration in days	Tests if the certificate is expired or if it will expire within a specified number of days.
Subject	Validates the specified value matches the expected values in the Certificate or Issuer Subject.
TLS version	Tests whether the TLS connection uses the specified TLS version.
Issuer name (CA name)	Tests whether the specified value matches the expected values in the Issuer name or CA name fields of the certificate.
Algorithm	Tests whether the certificate's public key algorithm matches the user-specified expected algorithm, such as RSA 2048, EC (Elliptic Curve), DSA 1024, or DH 2048. The user specifies the algorithm in the test configuration.
Is Self-Signed	Tests whether the certificate was self-signed (value is 1) or not (value is 0).
Is Trusted	Tests whether the certificate is trusted (value is 1) or not (value is 0).
Is Revoked	Tests whether the certificate was revoked (value is 1) or not (value is 0).

Setup steps

There are no setup steps if you are testing certificates issued by publicly trusted CA and not self-signed.

If you are testing certificates issued by a Certificate Authority that is not publicly trusted, the only setup step would be to use a global variable for a custom Certified Authority (CA) certificate.