Test embedding an encoded JSON payload at tail end of LongServiceOutput content

[atc0005]

Overview

There may be better ways to handle this, but I want to make sure that the certificate chain captured by the monitoring plugin is exposed to the monitoring system.

The current plugin API permits passing human readable information back for display in a web UI or notifications and metrics for calculations & other data manipulation purposes, but AFAIK does not permit passing something like a JSON payload between plugin and the monitoring system.

My particular use case is accessing this information via the Nagios XI API, but I'd like to see this implemented in a way that's usable to others using the plugin from other monitoring systems.

I'd also like to see this implemented in an opt-in manner so that it's off by default.

While ideally the additional info would be available via a dedicated field of some kind, I'm considering whether it's a workable solution to provide a small, customized JSON payload in an encoded format (able to safely pass default sanitization requirements) that can be accessed later from the LongServiceOutput field.

I've not yet checked to confirm that the base64 encoding format would pass the illegal_macro_output_chars requirements, but assuming that it would, we'd still be limited by the default 4K plugin output requirements.

References

• Nagios character restrictions applicable to LongServiceOutput macro
  • https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/configmain.html#illegal_macro_output_chars
• base64 encoding
  • https://gobyexample.com/base64-encoding
  • https://golang.cafe/blog/golang-base64-encode-example.html
• ascii85 encoding
  • https://blog.manugarri.com/note-to-self-fixing-encoding-in-golang-ascii85/
  • https://pkg.go.dev/encoding/ascii85

See also:

• Add support for embedding an encoded payload within and later extracting the payload from plugin output go-nagios#251
• Create exported JSON payload type for use by dependent projects #989
• Add option to omit Subject Alternative Names (SANs) list instead of listing all entries #993

[atc0005]

May need to also update the atc0005/go-nagios project to provide some helper functionality.

[atc0005]

May need to also update the atc0005/go-nagios project to provide some helper functionality.

The v0.17.0 release of that project will provide the necessary support for encoding/decoding embedded payloads.

The https://github.com/atc0005/cert-payload project will provide a cert payload type for encoding/decoding the JSON data.

[atc0005]

Current prototyping efforts are going well enough with most evaluated certificate chains falling below the 8K plugin output cutoff. However, there is one certificate chain I'm testing against which has 73 SANs entries. Listing all of them in the plugin output exceeds the 8k "budget".

Some debug output generated by the prototype:

[go-nagios] 2024/11/04 04:33:04 222 bytes plugin ServiceOutput content written to buffer
[go-nagios] 2024/11/04 04:33:04 3914 bytes plugin LongServiceOutput content written to buffer
[go-nagios] 2024/11/04 04:33:04 6251 bytes plugin EncodedPayload content written to buffer
[go-nagios] 2024/11/04 04:33:04 273 bytes plugin performance data content written to buffer
[go-nagios] 2024/11/04 04:33:04 10660 bytes total plugin output to write

For contrast, here is the debug output when evaluating the certificate used by www.google.com:

[go-nagios] 2024/11/04 04:43:16 217 bytes plugin ServiceOutput content written to buffer
[go-nagios] 2024/11/04 04:43:16 1602 bytes plugin LongServiceOutput content written to buffer
[go-nagios] 2024/11/04 04:43:16 272 bytes plugin performance data content written to buffer
[go-nagios] 2024/11/04 04:43:16 2091 bytes total plugin output to write

For the former cert chain, we'll need this flag to be implemented to bring the content down below the 8k plugin output limit:

• Add option to omit Subject Alternative Names (SANs) list instead of listing all entries #993