Default scan commands are not run when using --certinfo_ca_file

[Deas-h]

Hello,

sorry if I am doing anything wrong...

I use sslyze 5.0.5 on Windows with a small batch job:

.\sslyze.exe --regular --certinfo_ca_file=.\pem_files\myca.pem myserver.mydomain.com

in the past this did a scan on my server and presented me the complete output. This is no longer working as --regular is not recognized.

Now I can do ".\sslyze.exe myserver.mydomein.com" and get the result, but then my internal CA is not included in the check.

When I try ".\sslyze.exe --certinfo_ca_file=.\pem_files\myca.pem --certinfo myserver.mydomain.com" the cert is validated against my CA, but all the additional information about TLS versions and vulnerabilities is missing.

I also checked the options and did not find anything that does what --regular did. Was this removed by accident? Because an option that tests for everything would be nice.

[nabla-c0d3]

Hello,
--regular now gets run by default, so you should try .\sslyze.exe --certinfo_ca_file=.\pem_files\myca.pem myserver.mydomain.com. Hope this helps!

[Deas-h]

Hello,

Sorry - no and I already wrote this in my initial post. When I try .\sslyze.exe --certinfo_ca_file=.\pem_files\myca.pem myserver.mydomain.com I only get this output:

CHECKING CONNECTIVITY TO SERVER(S)

myserver.mydomain.com:443 => 1.2.3.4

SCAN RESULTS FOR MYSERVER.MYDOMAIN.COM:443 - 1.2.3.4

SCANS COMPLETED IN 0.432612 S

COMPLIANCE AGAINST MOZILLA TLS CONFIGURATION

Disabled; use --mozilla_config={old, intermediate, modern}.

Yes, thats all - nothing else! So there must be a bug when I add a ca to check against.

[cddmp]

Before I open another issue, I thought I add my comment here. I think --regular was removed here, right?
1f448d1#diff-e8bfae37aec311a90b2180f684debe74f9c7a29c6d5522417cf39e29dd2dd2ccL117-L120

From my understanding when I previously wanted to do
sslyze --regular --fallback example.com
I now need to run
sslyze --mozilla_config intermediate --fallback example.com

sslyze --fallback example.com "alone" will only do the SCSV check.

Is this behaviour really intended?

[nabla-c0d3]

@Deas-h It will be fixed in the next release.

@ccdmp I'm not sure I understand what you are trying to do as sslyze --regular --fallback example.com was the same as sslyze --regular example.com . The difference is that now --regular is run by default without having to specify it.

[Deas-h]

@nabla-c0d3 - thanks a lot!

[nabla-c0d3]

Fix released as part of v5.0.6.

[Deas-h]

Works, thanks a lot!

[cddmp]

@ccdmp I'm not sure I understand what you are trying to do as sslyze --regular --fallback example.com was the same as sslyze --regular example.com . The difference is that now --regular is run by default without having to specify it.

Sorry for my late reply.
sslyze --regular example.com is not the same as sslyze --regular --fallback example.com. The first one will not schedule the SCSV check, the latter one did the "regular" checks + the SCSV check which is not included in --regular.
If I now want to have both, the regular checks + the SCSV check, I need to run sslyze --mozilla_config intermediate --fallback example.com, since --regular does not exist any longer.
This is at least what I see on Kali Linux with sslyze in version 5.0.6.

Examples:

Using the --fallback parameter only, does only perform the SCSV fallback check:

$ sslyze --fallback example.com --json_out example.com.json &>/dev/null

$ jq ".server_scan_results[0].scan_result.tls_fallback_scsv" example.com.json
{
  "error_reason": null,
  "error_trace": null,
  "result": {
    "supports_fallback_scsv": true
  },
  "status": "COMPLETED"
}

$ jq ".server_scan_results[0].scan_result.tls_1_2_cipher_suites" example.com.json                                                                                
{
  "error_reason": null,
  "error_trace": null,
  "result": null,
  "status": "NOT_SCHEDULED"
}

Using no additional scan parameter, the SCSV check will not be scheduled ("regular" does not include SCSV checks):

$ sslyze example.com --json_out example.com.json   &>/dev/null
$ jq ".server_scan_results[0].scan_result.tls_fallback_scsv" example.com.json    
{
  "error_reason": null,
  "error_trace": null,
  "result": null,
  "status": "NOT_SCHEDULED"
}

"--regular" is deprecated:

$ sslyze --regular --fallback example.com --json_out example.com.json                                                                                           
usage: sslyze [-h] [--update_trust_stores] [--cert CERTIFICATE_FILE] [--key KEY_FILE] [--keyform KEY_FORMAT] [--pass PASSPHRASE] [--json_out JSON_FILE]
              [--targets_in TARGET_FILE] [--quiet] [--slow_connection] [--https_tunnel PROXY_SETTINGS] [--starttls PROTOCOL] [--xmpp_to HOSTNAME]
              [--sni SERVER_NAME_INDICATION] [--resum] [--resum_attempts RESUM_ATTEMPTS] [--tlsv1] [--tlsv1_3] [--heartbleed] [--compression] [--sslv2] [--early_data]
              [--http_headers] [--elliptic_curves] [--certinfo] [--certinfo_ca_file CERTINFO_CA_FILE] [--sslv3] [--openssl_ccs] [--fallback] [--tlsv1_2] [--tlsv1_1]
              [--reneg] [--robot] [--mozilla_config {modern,intermediate,old,disable}]
              [target ...]
sslyze: error: unrecognized arguments: --regular

This "workaround" works:

$ sslyze --mozilla_config intermediate --fallback example.com --json_out example.com.json    
$ jq ".server_scan_results[0].scan_result.tls_fallback_scsv" example.com.json 
{
  "error_reason": null,
  "error_trace": null,
  "result": {
    "supports_fallback_scsv": true
  },
  "status": "COMPLETED"
}
 
$ jq ".server_scan_results[0].scan_result.tls_1_2_cipher_suites" example.com.json | head -n 10
{
  "error_reason": null,
  "error_trace": null,
  "result": {
    "accepted_cipher_suites": [
      {
        "cipher_suite": {
          "is_anonymous": false,
          "key_size": 128,
          "name": "TLS_RSA_WITH_SEED_CBC_SHA",