VMware Cloud Community
Kewlicks
Contributor
Contributor

ESXi 7.0.3n and Rsyslog over TLS1.2

Hi All,

I wonder if anyone can help. 

I have set up a central Rsyslog server running on RHEL 9.3. It's configured to use port 1514 and is set to use TLSv1.2 cipher suites

Certificate has been generated and placed on the RHEL server along with the root CA template to complete the chain. The same root CA certificate has been placed in vCenter and pushed to the ESXi hosts. This is confirmed by looking in the /etc/vmware/ssl/castore.pem file on the host.

Logs are forwarded from other RHEL servers and vCenter to the central Rsyslog server. No issues there. However, it's a different story for the ESXi hosts. 

ESXi is configured to forward to rsyslog using the Syslog.global.logHost advanced setting and the firewall is opened. I am seeing connectivity on the Rsylog server, but the connection ends with Rsyslog error message:

"gnutls returned error on handshake: One of the involved algorithms has insufficient security level"

I've googled around to no avail. I have turned on enhanced debugging on the Rsyslog since I can't seem to find any enhanced logging on the ESXi server which actually records the the start of TLS handshake.

On the Rsyslog server, I see the following..

nsd_gtls.c: GnuTLS log msg, level 5: REC[0x7fb0c8003960]: Decrypted Packet[0] Handshake(22) with length: 114
nsd_gtls.c: GnuTLS log msg, level 4: HSK[0x7fb0c8003960]: CLIENT HELLO (1) was received. Length 110[110], frag offset 0, frag length: 110, sequence: 0
nsd_gtls.c: GnuTLS log msg, level 4: HSK[0x7fb0c8003960]: Client's version: 3.3
nsd_gtls.c: GnuTLS log msg, level 2: FIPS140-2 context is not set
nsd_gtls.c: GnuTLS log msg, level 3: ASSERT: db.c[_gnutls_server_restore_session]:334
nsd_gtls.c: GnuTLS log msg, level 2: FIPS140-2 context is not set
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Parsing extension 'Supported EC Point Formats/11' (4 bytes)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Parsing extension 'Supported Groups/10' (8 bytes)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Received group SECP256R1 (0x17)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Received group SECP521R1 (0x19)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Received group SECP384R1 (0x18)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Selected group SECP256R1
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Parsing extension 'Session Ticket/35' (0 bytes)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Parsing extension 'Signature Algorithms/13' (32 bytes)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (6.1) RSA-SHA512
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (6.2) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (6.3) ECDSA-SHA512
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (5.1) RSA-SHA384
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (5.2) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (5.3) ECDSA-SHA384
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (4.1) RSA-SHA256
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (4.2) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (4.3) ECDSA-SHA256
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (3.1) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (3.2) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (3.3) (null)
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (2.1) RSA-SHA1
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (2.2) DSA-SHA1
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: rcvd signature algo (2.3) ECDSA-SHA1
nsd_gtls.c: GnuTLS log msg, level 4: EXT[0x7fb0c8003960]: Parsing extension 'Heartbeat/15' (1 bytes)
nsd_gtls.c: GnuTLS log msg, level 4: HSK[0x7fb0c8003960]: Received safe renegotiation CS
nsd_gtls.c: GnuTLS log msg, level 2: checking c0.2f (GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256) for compatibility
nsd_gtls.c: GnuTLS log msg, level 2: Selected (RSA) cert
nsd_gtls.c: GnuTLS log msg, level 4: checking cert compat with RSA-SHA512
nsd_gtls.c: GnuTLS log msg, level 4: Selected signature algorithm: RSA-SHA512
nsd_gtls.c: GnuTLS log msg, level 4: HSK[0x7fb0c8003960]: Selected group SECP256R1 (2)
nsd_gtls.c: GnuTLS log msg, level 4: HSK[0x7fb0c8003960]: Selected cipher suite: GNUTLS_ECDHE_RSA_AES_128_GCM_SHA256
nsd_gtls.c: GnuTLS log msg, level 3: ASSERT: handshake.c[read_client_hello]:884
nsd_gtls.c: GnuTLS log msg, level 3: ASSERT: handshake.c[_gnutls_recv_handshake]:1655
nsd_gtls.c: GnuTLS log msg, level 3: ASSERT: handshake.c[handshake_server]:3540
errmsg.c: Called LogMsg, msg: gnutls returned error on handshake: One of the involved algorithms has insufficient security level.

What I am failing to understand is why the ESXi host is offering a signature of RSA-SHA512 as the first signature when it can only run TLS1.2. The UserVars.ESXiVPsAllowedCiphers advanced setting on the host shows a value which when translated into Openssl only shows SHA256 or SHA384 cipher strings to be used. My certificate and CA certificate are SHA256 based.


If I do the same diagnosis with the vCenter connection, the first signature offered is RSA-SHA256 and that, as expected, connects and forms a TLS1.2 connection.

Any help would be greatly appreciated. 

Steve

0 Kudos
0 Replies