TLS Cert validity alerting

[andrewvc]

Design Issue:

Personas / User Stories
As someone responsible for managing TLS/SSL Certificates
I want my certificates to be checked a regular basis and to be notified when I have a certificate that is aged over X days or within Y days the certificate expiry
So that I can ensure we aren't at risk of data being compromised or services going down from an expired certificate
AND so that I can take prompt action to replace a near expiry certificate

ACs:

• Must be able to use the Kuerybar settings
• Intervals are hardcoded at every 24 hours
• Users can specify max age or time to expiration expiry as alert condition (in settings)
• Users can specify interval in days (in settings)

To check: How to specify severity (ie 45 days it's an FYI, 7 days it's a drop everything type situation)

Example syntax:

WHEN ANY MONITOR
HAS A CERTIFICATE [30 DAYS] FROM EXPIRATION
OR OLDER THAN [365 DAYS]

Days values ^^ will display a popover with the following text: You can change the criteria for expiration and age in the [settings page].

Alert state and context

While implementing this feature we ran into the problem of what to include as our default message, and what values would be useful to supply in the alert's state and context.

@andrewvc and @justinkambic defined the following fields:

state.count: The total number of certs returned by elasticsearch that will be outside of bounds
state.expiringCount: The number of certificates detected who will be out of date soon.
state.expiringCommonNameAndDate: The common name and expiration date of the certs from the above.
state.agingCount: Same as expiring but for `certificate_not_valid_before`
state.agingCommonNameAndDate: Same as above but for `certificate_not_valid_before`
state.hasExpired: a true | null field for use in our mustache expressions
state.hasAging: a true | null field for use in our mustache expressions

Along with that, this is the working copy for the default alert message users will see when interacting with the AddAlert flyout:

Detected {{state.count}} TLS certificates expiring or becoming too old.

{{#state.hasExpired}}
Expiring cert count: {{state.expiringCount}}.
Expiring Certificates: {{state.topExpiringCommonNameAndDate}}.
{{/state.hasExpired}}

{{#state.hasAging}}
Aging cert count: {{state.agingCount}}.
Aging Certificates: {{state.topAgingCommonNameAndDate}}.
{{/state.hasAging}}

[katrin-freihofner]

Design issue

[katrin-freihofner]

Figma link
Prototype link

[andrewvc]

I'm thinking we need copy in the alert dialog that links to the settings page to adjust the days. Maybe:

"You can change the thresholds for certificate expiration warnings on the [settings] page", with 'settings' being a link. Thoughts?

[justinkambic]

I'm thinking we need copy in the alert dialog that links to the settings page to adjust the days.

What would be the path to get back into the flyout after that? Would they have to return to the certs page and reopen?

Could we just allow them to edit the settings from this page, with copy explaining that the values can also be viewed in Settings with a link?

Alternatively, we could allow them to open the Certs alert flyout from the settings page, but that seems to go against the flow that we've previously discussed where we keep the various alert creation dialogues associated with their respective pages.

[justinkambic]

I updated the description to reflect some new reqs about the alert state and default message we display to users, feel free to comment and share recommendations or concerns.

[justinkambic]

We are planning to have the Add Alert flyout default to our TLS alert when the button is clicked in our UI, but we should also determine the proper icon to use for the different alert types we support. Today, the selection dialogue would look like this:

cc @andrewvc @katrin-freihofner

[katrin-freihofner]

Fyi, this is how APM handles multiple alert types.