All,
We are experimenting with tracking/whitelisting x509 certificate issuers, using Bro 2.2. I’m seeing that certain certificates consistently don’t appear to be getting parsed properly.
For example:
1.311.60.2.1.3=#13025553CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
025553CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
.1.3=#13025553CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
This is just a small sample, but it appears to happen mostly with certain certificates (like the Verisign extended validation certs). Is anyone else seeing this?
Mike
Hello Michael,
it may have been fixed in the dev version, see
https://bro-tracker.atlassian.net/browse/BIT-1195
Anthony
I saw that too, that even if I was careful to get copies in the host’s cert storage and run a script like is outlined in (https://www.bro.org/current/solutions/extending/). It seems there is indeed an issue with the cert parsing code.
Hello Michael,
like Anthony said, this bug was probably fixed in the current master version. Could you try with that and see if that fixes your problem? I think this is the only change since 2.3-beta that made it into master, so using it will not break anything else.
Johanna
Ignoring the potential certificate parsing issue, it's usually not a good idea to track certs by their subject. You can collect the hash of the certificate and compare on that too.
.Seth
I’m only using a small sample pcap, but 2.3-beta5 appears to fix the parsing issue.
thanks!