This post transcribes some emails I sent to several mailing lists:

The initial email was sent to the Kafka User mailing list:

Reply-To: users@kafka.apache.org
Message-ID: <92aa6286-d875-04ed-6205-9e4a8fe3a1a1@jcea.es>
Date: Thu, 9 Nov 2023 03:37:39 +0100
To: users@kafka.apache.org
From: Jesus Cea <jcea@jcea.es>
Subject: How to get a X509 broker certificate with "openssl s_client"?

I am trying to remotely access to the brokers certificates (for audit
purposes, expiration alarms, etc) using this command:

"""
openssl s_client -showcerts -connect localhost:9092
"""

The connection is correctly established, but something is wrong. The TLS
session is has some errors at the beginning, but it success at the end:

"""
[jcea@Kafka ~]$ openssl s_client -showcerts -connect localhost:9092
CONNECTED(00000004)
1:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad
record mac:ssl/record/ssl3_record.c:676:
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1696 bytes and written 300 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
"""

I tried too writing a tiny TLS client in Python, same result, raising
this exception: "ssl.SSLError: [SSL:
DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac
(_ssl.c:992)".

I guess there is some kind of preamble before TLS negotiation.

Is that documented somewhere?. How can I check remotely the brokers'
certificates?

Thanks.

Leer más…

Cuando un cliente se conecta a un servidor SSH, normalmente le propondrá todas las identidades SSH presentes en el servicio SSH Agent. Esto no está necesariamente mal, pero tiene algunos problemas:

• El servidor SSH puede tener un número de reintentos limitado y nosotros podemos tener muchas identidades SSH que ofrecer.
• A veces queremos tener nuestras personalidades online separadas y es preferible ofrecer al servidor SSH una identidad concreta controlada en vez de informarle de todas nuestras identidades disponibles para que elija la que le sirva. Un servidor malicioso podría vincular personalidades SSH e identificarnos como la misma persona física en diferentes entornos que preferimos mantener separados.

Los pasos a seguir con OpenSSH son sencillos:

1. Creamos una nueva identidad SSH para un servicio concreto. Para eso se usa el comando ssh-keygen.

2. Configuramos en ~/.ssh/config un perfil para ese servicio con estos parámetros:

   # "IdentitiesOnly yes" indica que solo debemos ofrecer
   # esa personalidad, aunque el SSH-Agent tenga más.
   IdentitiesOnly yes
   IdentityFile PATH_A_LA_IDENTIDAD_SSH
   

Cuando nos conectemos al servidor usando ese perfil, el cliente SSH solo ofrecerá esa identidad.

Podemos verificar que todo está funcionando bien conectando a ese servicio con ssh -v y viendo qué identidades estamos ofreciendo al servidor.

En una máquina con sistema operativo basado en Illumos, como un SmartOS, podemos ver los detalles de un dispositivo NVMe con el comando nvmeadm. Por ejemplo:

[root@tmz1 ~]# nvmeadm list
nvme0: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W922518D, FW rev: 5B2QGXA7, NVMe v1.3
  nvme0/1 (c2t002538B931C60571d0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB
nvme1: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W920592A, FW rev: 5B2QGXA7, NVMe v1.3
  nvme1/1 (c3t002538B931C5FDEBd0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB

[root@tmz1 ~]# nvmeadm list-logpages nvme0
DEVICE  NAME              SCOPE         FIELDS    DESC
nvme0   error             controller    rae       Error information
nvme0   health            controller,   rae       SMART / Health information
                          namespace
nvme0   firmware          nvm           --        Firmware Slot Information
nvme0   cmdeff            controller    --        commands supported and effects

[root@tmz1 ~]# nvmeadm -v get-logpage nvme0 health
nvme0: SMART/Health Information
  Critical Warnings
    Available Space:                        OK
    Temperature:                            OK
    Device Reliability:                     OK
    Media:                                  OK
    Volatile Memory Backup:                 OK
  Temperature:                              35C
  Available Spare Capacity:                 100%
  Available Spare Threshold:                10%
  Device Life Used:                         0%
  Data Read:                                0GB
  Data Written:                             7GB
  Read Commands:                            27859
  Write Commands:                           42000
  Controller Busy:                          0min
  Power Cycles:                             10
  Power On:                                 11581h
  Unsafe Shutdowns:                         4
  Uncorrectable Media Errors:               0
  Errors Logged:                            0
  Warning Composite Temperature Time:       0min
  Critical Composite Temperature Time:      0min
  Temperature Sensor 1:                     35C
  Temperature Sensor 2:                     47C
  Thermal Management Temp 1 Transition Count: 0
  Thermal Management Temp 2 Transition Count: 0
  Time for Thermal Management Temp 1:       0sec
  Time for Thermal Management Temp 2:       0sec

Se pueden hacer muchas cosas, como un borrado seguro del NVMe, actualizar el firmware. Puedes ver las opciones disponibles revisando el manual con man nvmeadm.