TLS Certificates dashboard is empty


I have a problem with the TLS Certificates dashboard in Uptime 7.14.0.
In the Monitors dashboard, I can see dates in the TLS Certificates column saying that the certificates will expire next year. Unfortunately, when I look in the TLS Certificates dashboard, it is empty. This problem is only with one index, the data from other indices work fine. I've compared the TLS fields in working and non-working documents, and I can't find any difference.
The agent which has the problem, is 7.12.0, so that should be fine.

What is necessary in the documents, so that they would appear in the TLS dashboard?


Hi @norgro2601 - the field this page uses is tls.server.hash.sha256. If you've configured your Heartbeat to monitor an endpoint that uses TLS this field should autopopulate without any additional action on your part and display in the UI.

I might be able to provide some more specific help if you're able to share your Heartbeat config, or provide an example of a public website that is not showing for you.

Hi @jkambic,

I've checked the tls.server.hash.sha256 field, it is populated in all documents. Here are two examples of websites, which are not working.

Thanks in advance.

Hi @jkambic ,

this is a screenshot of a definition in Heartbeat that works.heartbeat

This example does not work.heartbeat-problem

Have you tried running it without ssl verification disabled? Can I ask why you care about certs, but don't want TLS verification?

Hi @Andrew_Cholakian1,

these definitions are from a new environment that is still in test, and I assume, this is why my colleagues have set ssl.verification_mode to none. They are mainly interested in the expiry date.

I will have them change the setting, but I doubt, that this is the root cause of the problem, as there are examples with this setting that works as needed, so I assume, that this setting alone has no influence on the visibility in the Certificates dashboard.

Hi @norgro2601 - I have pulled down a 7.14.0 release stack and run the exact monitor config you've specified, and I was able to see cert information in the TLS page. If you're telling me the field is present when you look at individual documents and you're still not seeing it I am not sure what else to check, at least with the available information.

Are any errors being logged in your browser console or in the Kibana server log when trying to access these pages? You could also look at the network tab and confirm that calls to api/uptime/certs have no data coming down.

Hi, we are also on 7.14.0 and experiencing the same issue. TLS dashboard is all empty. The field tls.server.hash.sha256 is populated in all documents in our index.
The error I get in the browser console:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-xxxxxxx'), or a nonce ('nonce-...') is required to enable inline execution. uptime/certificates:282

response from the /api/uptime/certs: {"certs":[],"total":0}

@Herman Aplogies for a delayed response on the thread,

Can you try running this query in your kibana dev tools,


This is the query basically it use to get list of certificates from API.
Good luck

1 Like

I'll add @Herman the error you see is expected, Kibana intentionally generates it to test some browser capabilities IIRC (if you look in the console, there's a line below it explaining that).

Looking forward to seeing if running the query @shahzad31 gave you helps, that's the exact query we run in the Uptime UI.

1 Like

Hi Andrew, it looks like the issue is with monitor.timespan in the query @shahzad31 provided.
We moved to data streams and we are not using the legacy heartbeat index template anymore. We started using the synthetics (mapping)template, included in Elasticsearch.
Comparing them both and we found out the legacy template has monitor.timespan as type date_range. And our data stream doesn't have this field. We only see monitor.timespan.gte and being created in the index.

I forgot to mention: we're not using Fleet agent.

Ah, that makes sense. That said, the synthetics mappings do include the monitor.timespan field as a date_range, so I'm surprised that you're missing them.

The thing about the timespan field is that date_ranges are ranges, they are compound fields. So, you send the values as two separate fields (much as you'd send a lat and lon field for geo), but it gets stored as a single range value.

If you fix the mapping (and delete old data) it should work. The old data with the improper mapping will throw off the queries since it's the wrong time.

I looked in every index template for synthetics and I couldn't find the mapping for monitor.timespan. We run a cluster on version 7.13.3 and a cluster on 7.14.0, both don't seem to have a mapping in the synthetics template (or their component templates).
If I look at the output of the heartbeat agent, which is on version 7.14.0, it sends this:

"monitor": {
    "type": "http",
    "timespan": {
      "gte": "2021-09-22T08:11:39.447Z",
      "lt": "2021-09-22T08:11:44.447Z"

Can you tell me where I should look for this mapping?

Sorry that I only find time to answer today on my initial question.

I've run your query twice, once on an index, where I can see the certificates and once on the index, where the view is empty. On the second index, the result is zero hits, then I tried with removed filter on monitor.timespan, and I get results. I added monitor.timespan then to the returned fields and noticed, that the values are at least 5 days back from today and older, although Heartbeat is pushing data all the time.

What is the reason for this and is that the reason for the empty view?

Hi, finally found the problem, the mapping for the monitor.timespan field was incorrect, it was no date_range field. After correcting the template, everything works.

1 Like

Hi Andrew,
Can you guys put monitor.timespan field as a date_range mapping in the default synthetics template installed by x-pack?

Thanks Herman

This topic was automatically closed 24 days after the last reply. New replies are no longer allowed.