tls: Access certificate details

[AndiDog]

Feature Description

Only these TLS-related fields are available right now:

// Response is a representation of an HTTP response
type Response struct {
	// ...
	Timings        ResponseTimings          `json:"timings"`
	TLSVersion     string                   `json:"tls_version"`
	TLSCipherSuite string                   `json:"tls_cipher_suite"`
	OCSP           netext.OCSP              `json:"ocsp"`
	// ...
}

If each X.509 certificate in the chain provided by the server could be represented there, k6 checks could assert that no certificate expires in the next N days.

Even better: if the client certificate for the request, if any is specified, is also represented, the whole request/response pair can be used in assertions.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

[mstoykov]

Hi @AndiDog , thanks for the feature request 🙇.

As I explained in #2391 (comment) adding more fields to the Response has its downsides. In that particular case it also added only one field out of one particular certificate. From what I gather you want the whole which I would argue is better. This still does mean that we will be creating and returning potentially many certificates object that will likely not be used by the majority of the users. But those users will still experience a performance degradation due to that.

Given that I would really prefer if this is done in the future new HTTP API where hopefully most of those issues will be solved from the grounds up. There has been some work started in actual experimentation around it so hopefully at least a PoC will be coming in the following few release cycles 🤞 .

Connected issues: #2393

[OzoneChris]

This would be very helpful, as it would allow assertions against expiry dates. @mstoykov the 'new' API you mention, is that now the currently one in 2025- or is there still one in progress?

[joanlopez]

@mstoykov the 'new' API you mention, is that now the currently one in 2025- or is there still one in progress?

The "new HTTP API" is still an item on our roadmap, not the existing API nowadays. Unfortunately, I cannot give you any rough delivery date, just say that it won't come in the near future but beyond.