What are you trying to achieve?

Encrypting network communication with SSL/TLS adds an additional layer of complexity to the communication which can be the source of issues, like expired certificates, outdated ciphers&protocols, ...

I would like to add several semantic conventions to the spec to describe SSL/TLS connections. I suggested a few through an instrumentation implementation for nodejs at open-telemetry/opentelemetry-js-contrib#447 via https://nodejs.org/api/tls.html (most other languages will have the same properties available):

tls.protocol
The negotiated SSL/TLS protocol version of the current connection, one of the following values:

• 'SSLv3'
• 'TLSv1'
• 'TLSv1.1'
• 'TLSv1.2'
• 'TLSv1.3'

tls.authorized
true, if the peer certificate was signed by one of the CAs specified when creating the tls.TLSSocket instance, otherwise false.

tls.cipher.name
OpenSSL name for the cipher suite.

tls.cipher.version
The minimum TLS protocol version supported by this cipher suite.

tls.certificate.fingerprint (or tls.server.certificate.fingerprint?)
The SHA-1 (or SHA-256) digest of the DER encoded certificate

tls.certificate.serial_number
The certificate serial number, as a hex string

tls.certificate.valid_from
The date-time the certificate is valid from.

tls.certificate.valid_to
The date-time the certificate is valid to.

tls.alpn_protocol
The negotiated ALPN protocol

There are a lot more potential candidates, like certificate details (subject, issuer, subjectaltname), SNI server name used, ephemeral key details, client certificate details. If there is value in adding any of these, part of a discussion should be which ones provide the most value and which ones might be irrelevant from an observability perspective or which ones are interchangable (fingerprint vs serial number // cipher.name vs cipher.standardName ...)