drwetter
commented
6 years ago Thank you, understood .
1) the cert# in case of >1 certificates : that was just omitted which seems s bug.
2) the other point is a design decision I need to think about.
: If there is only 1 certificate available, the "<cert #1>" part is missing. If parsing the output, I first have to check if sth. like "cert_fingerprintSHA256" is present and if not I have to check for "cert_fingerprintSHA256 <cert #1>".
That should be just matches patterns? The logic I would apply is the number of different host certificates supplied (this is missing btw. in JSON). Then one could go from there. I understand though that this might be not straightforward.
Or even better: Create a separate list for certificates instead of a flat structure with numbered "ids"?
You mean in pretty JSON a separate object for each certificate?
happyc0ding
Parsing the output of testssl is still a bit of a hazzle. Especially when reading the certificate data (both JSON and pretty JSON), the id "cert" is duplicated. The host "google.com" is a good example to reproduce this behaviour.
...
The other ids are labeled with sth. like "cert_fingerprintSHA256 <cert #1>". This is another issue, since the output of testssl changes: If there is only 1 certificate available, the "<cert #1>" part is missing. If parsing the output, I first have to check if sth. like "cert_fingerprintSHA256" is present and if not I have to check for "cert_fingerprintSHA256 <cert #1>". Maybe it is better to always keep the number in there, even if only 1 certificate is available? Or even better: Create a separate list for certificates instead of a flat structure with numbered "ids"?
I tested with the current testssl version ("09182cb 2018-07-05 09:54:58") on Linux.