OPENSSL_internal:BAD_PACKET_LENGTH

Greetings:

I have just configured a new Graystack and have chosen to enable tls. Here are my TLS settings, server side:

#### Enable HTTPS support for the HTTP interface
#
# This secures the communication with the HTTP interface with TLS to prevent request forgery and
eavesdropping.
#
# Default: false
http_enable_tls = true
# The X.509 certificate chain file in PEM format to use for securing the HTTP interface.
http_tls_cert_file = /etc/certs/grayserver-0.pem
# The PKCS#8 private key file in PEM format to use for securing the HTTP interface.
http_tls_key_file = /etc/certs/grayserver-0.key
# The password to unlock the private key used for securing the HTTP interface.
#http_tls_key_password = secret                                                   

There are no errors within the logs to suggest TLS is configured improperly (Graylog is communicating with mongodb [same server]); it communicates with 3 Opensearch Nodes via TLS without error.

However, when I attempt to ingest via TLS, I get this error:

2024-01-31T23:10:27.076Z ERROR [AbstractTcpTransport] Error in Input [Syslog TCP/FortigateDomestic/65bad32da8cafa6f775cfe06] (channel [id: 0x5e047c6b, L:/192.168.128.114:5556 ! R:/192.168.128.1:24752]) (cause io.netty.handler.codec.DecoderException: io.netty.handler.ssl.ReferenceCountedOpenSslEngine$OpenSslHandshakeException: error:10000070:SSL routines:OPENSSL_internal:BAD_PACKET_LENGTH)

My configuration is as follows:

Any ideas?

Thank you!

EDIT: You may notice the artificially low Buffer size. That was just a wild swing to resolve. It produced the above errors with the default size, as well

Hey @accidentaladmin

Are the cert’s used for Graylog (HTTPS) made the same way for your INPUT (FortigateDomestic)?
Are these certs RSA Public-Key: (2048 bit)?

Unfortunately yes. This is an AD CA PKI setup so everything is much more complicated than if, for instance, I was just self-signing via openssl

I understand, Only thing I can suggest is to ceck your certificate length:

openssl x509 -in certificate.crt -text -noout | grep “Public-Key”

If there is anyway to increase it I would, sorry I cant be more help on this.

Yeah, I am fully prepared to accept that this is a Fortinet problem (see my previous thread about Fortinet log peculiarities).

That being said, I am very willing to concede I may be very confused, generally, with respect to TLS. Perhaps you could assist.

When creating an input, generally, whose/what certificate/key path goes in 1, 2, & 3, below, respectively?

Thank you as always; y’all rock!

Hey @accidentaladmin

Unfortunately, with our setup with Fortinet/FortiGate ranging for 60D to 100F series Firewalls, this is internal. We haven’t had the use for certificates between the two. This is internal so they can’t reach the internet. This makes it easier to secure since no one can reach them. As for testing this we have a while back BUT we used OpenSSL to create them.

https://docs.fortinet.com/document/fortigate/6.2.15/cookbook/825073/procure-and-import-a-signed-ssl-certificate

I have took my self-signed certificates and add to the Microsoft Active Directory. The porcedure was pretty simple found here

Not sure if that will help but just an idea.

I still haven’t figured out the Fortigate but have everything else figured (except TLS client authentication; not sure if the juice is worth the squeeze).

AD does indeed make things difficult for my little predominantly linux molded brain but I found a process that works for me.

I just export the root/intermediate cert and key to a linux vm and then use a script I frankensteined together from various sources (OpenSearch, Wazuh, etc.) to create my certs using OpenSSL and the AD cert to sign the csr’s. AD isn’t the wiser and its a billion times easier (IMHO).

1 Like

hey @accidentaladmin

Yeah I had to do that with Keycloak few years back. I used this,not sure if you seen it.

As for Fortigate, If you get it to work I would like to know how ya did it if thats kool.