Add SSL checks

[beevelop]

Would be awesome to support SSL checks automatically validate certificate provisioning and proper configuration of e.g. reverse proxies.

ssl:
  https://github.com:
    expired: false
    common-name: github.com
    allow-invalid: false
    timeout: 1000

[aelsabbahy]

What would the purpose of allow-invalid be in the above example? I'm also wondering if this should be an extension of http or a separate category ssl.

[beevelop]

allow-invalid would be useful when accessing an exposed service locally (the hostname would differ from the provided common name, but the certificate could still be considered valid) – e.g. via IP address or when „skipping“ the a reverse proxy.

[morsik]

Using https:// here is not really useful. SSL is not bound to HTTP - it can be used with any service. More wire would be:

ssl:
  127.0.0.1:80:  # IP and port specified here
    expired: false
    common-name: github.com
    allow-invalid: false
    timeout: 1000

    # my proposals
    valid: +60d  # this cert should be valid longer than 60 days - useful for testing if all certs are deployed correctly

[tzz]

Please also consider explicitly provided CA and client certificates, and protocol versions and other SSL/TLS parameters for testing.

[matrixise]

this feature could be really useful

[billux]

Having a separate module for SSL checks would allow us to run more SSL/TLS related tests, like supported protocols and ciphers:

ssl:
  127.0.0.1:443
    […]
    protocols:
      consist-of: ['TLSv1.1', 'TLSv1.2', 'TLSv1.3']  # and thus ensure that SSLv3 and TLSv1.0 are NOT supported
    ciphers:
      - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256  # Only ensure that this cipher is supported among others

[sshipway]

We approximate this functionality by doing a command resource

  command:
    certificate-https:
      exec: "openssl s_client -verify_return_error -quiet -host www.company.com -port 443 -no_ign_eof </dev/null"
      exit-status: 0
      stderr:
        - 'DONE'
        - '/^verify return:1/'
        - '!/^verify return:0/'
        - '!/^verify error:/'
        - '/CN=www.company.com/'
        - '/Protocol *: *TLSv1.[123]/'

However a native SSL check would allow things like tests on remaining days' validity, available cipher list, and name checks against extended or wildcard certs.

Using openssl s_client allow you to test against native SSL or starttls as well - so a native SSL check should allow the different STARTTLS functionality as well as straight ssl.

[aelsabbahy]

This feels like it could end up being quite a bit of scope creep for goss to support, SSL is sufficiently complicated that using command to delegate to more specialized tools makes more sense to me.

Wonder if the upcoming goss v0.4.0 command/gjson would make this a lot easier.

For example, using https://github.com/square/certigo:

command:
  certificate-gh.com:
    exec: 'certigo connect -j github.com'
    timeout: 10000
    exit-status: 0
    stdout:
      gjson:
        certificates.0.is_self_signed: false
        certificates.0.dns_names: {consist-of: ["github.com","www.github.com"]}
        tls_connection.version:
          and:
            - or: [tls_1_1, tls_1_2, tls_1_3]
            - match-regexp: 'tls_1_[123]' # using regex instead of or

My goal is to expand the macher language so that command can be used to integrate 3rd party and specialized tooling.

Would love your thoughts on this.

[gsauthof]

What about doing both? That means having a basic TLS check module in Goss with a limited set of features - but which still is probably sufficient for the majority of use cases. And for everything beyond that users can switch to certigo via command/gjson.

One of the selling points I see in goss is that it's one self-contained executable with which you can get far without having to install extra dependencies.

[sshipway]

It would be nice if the goss http module could check the basic things -- certificate CN, expiry (maybe days remaining), and chain.

certigo looks good, but its not available as a centos RPM in the main repos yet, and it would mean another dependency to add. Plus, it's written in go, so its a big chunky binary.

The gjson comparator looks very nice - particularly with execs like certigo, or REST https services - but does it have the ability to do date comparisons on the certificate notAfter date? If not then we'd not be able to check for days remaining. Generic failure could be tested for though, including chain and CN.

[aelsabbahy]

The gjson comparator looks very nice - particularly with execs like certigo, or REST https services - but does it have the ability to do date comparisons on the certificate notAfter date? If not then we'd not be able to check for days remaining. Generic failure could be tested for though, including chain and CN.

Another one on my mental backlog is more range tests. Kind of how the semver range works, but create one for rpm, deb, date, etc..

That all said, it sounds like there's enough interest in this. So I'm open to @gsauthof and @sshipway suggestion of adding just the basics to goss:

What about doing both? That means having a basic TLS check module in Goss with a limited set of features - but which still is probably sufficient for the majority of use cases. And for everything beyond that users can switch to certigo via command/gjson.

Let's see if everyone here can come to an agreement on what those minimal set of requirements are. Then I can mark this as approved.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.