Suddenly getting lot of TLS decoder related alerts from Suricata

  • Since yesterday evening from around 5 PM UTC, I've been getting a steady amount of "SURICATA TLS invalid certificate" and "SURICATA TLS certificate invalid length" alerts from valid hosts, such as Apple's iCloud, Microsoft store and Azure.

    I'm running 2.3.4-RELEASE (amd64) with Suricata 3.2.1_1 that has paid Snort rules and ETOpen. I've checked both Snort changelogs for 2990 (for the sake of it) and ETOpen changelogs ( that nothing has been changed in any TLS_ related rules.

    Am I being targeted by the NSA here or what's going on?  ::) Any ideas?

    05/19/2017-00:20:16.457983  [] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} n.n.n.29:56158 ->
    05/19/2017-00:20:16.457983  [] [1:2230007:1] SURICATA TLS certificate invalid length [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} n.n.n.29:56158 -> for example is used by Google.

    The original rules in my tls-events.rules for these two alerts are:
    alert tls any any -> any any (msg:"SURICATA TLS invalid certificate"; flow:established; app-layer-event:tls.invalid_certificate; flowint:tls.anomaly.count,+,1; classtype:protocol-command-decode; sid:2230004; rev:1;)
    alert tls any any -> any any (msg:"SURICATA TLS certificate invalid length"; flow:established; app-layer-event:tls.certificate_invalid_length; flowint:tls.anomaly.count,+,1; classtype:protocol-command-decode; sid:2230007; rev:1;)

  • The error is being generated by one of the built-in rules of Suricata.  I would suggest checking over on the Suricata Redmine site to see if anyone else has posted the same or similar issue.  If the alert is coming from the rule I think it is, then the only thing that changes that rule is an actual update of the entire Suricata binary package.  There is a core set of event and app-layer rules that install with the package (DNS events is one I recall, and I think there is a TLS events rule file as well).

    Here is their Redmine site:

    Taking a quick look myself, I found this TLS bug.  I don't know if it applies in your case, but you can check out the thread here:


  • Thanks Bill for your ideas, though I didn't find anything that quite fits the bill on the Suricata Redmine.

    I checked that my clock is set and functioning, then rebooted my pfSense instance and I'm still getting these errors. For example, at the very same second, I've got like 10 rows from/to the same IPs to my logs about this:

    [] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} -> nnn.nnn.nnn.35:50801

    So I've enabled TLS logging in Suricata to get the thumbprints and thus I can see the "invalid" certificate is actually valid without any issues:

    nnn.nnn.nnn.35:50801 ->  TLS: Subject='C=US, ST=California, L=San Francisco, O=Twitter, Inc., CN=*' Issuerdn='C=US, O=DigiCert Inc,, CN=DigiCert SHA2 High Assurance Server CA' SHA1='fa:29:8e:8a:5e:2c:3d:fb:77:58:da:11:e7:1c:03:36:cc:b3:de:a0' VERSION='SSLv2' NOTBEFORE='2016-08-04T00:00:00' NOTAFTER='2019-10-02T12:00:00'

    Again, this is now happening for certs from Google, Twitter, iCloud, Microsoft etc.

    I just can't figure out what's going on  :-\  :-\  :-\ - this isn't happening to anyone else?

  • …and oh yes, even is affected :-X

    [] [1:2230004:1] SURICATA TLS invalid certificate [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} nnn.nnn.nnn.35:58745 ->

    For a brief moment I wondered if I was sending some client certificates which are not working, but I'm seeing these errors also from iPhones doing some iCloud stuff, so I guess it's not client related in any way either. I'm getting confused here  >:(

  • And you said this problem just popped up out of the blue after things had been working fine?  A rules update from neither Snort VRT nor Emerging Threats would update this particular rule.  It is part of the core set of rules provided in the Suricata source code and gets updated when the binary version changes.

    The last Suricata update was to version 3.2.1 of the binary (and thus of these built-in rules).  So do you know if your problem happened well after you updated to the 3.2.1 binary version, or could those two be related?  I'm trying to pin down if this perhaps happened as a result of the 3.2.1 update.  However, if it did, I would expect to be seeing more posts here about it.


  • I was able to get rid of the errors by shutting down ntopng!

    Not sure what's wrong it with but in the logs I also saw this:

    May 21 19:45:48 ntopng    [HTTPserver.cpp:538] ERROR: Unable to start HTTP server (IPv4) on ports 3000s: Address already in use

    Perhaps some upgrade gone bad  :-\

Log in to reply