Hi Paula, great post! I hadn't seen nmap used for this task before.
I think there's one potential problem to consider:
After you grep the negotiations file contents you captured with openssl to make sure the correct renegotiation string is there your script concludes "Certificate validity ensured."
Depending on what you meant here it might not be true and its mostly the fault of openssl s_client having really bad defaults :'(
Your script uses openssl s_client -connect $1:443 but this command will return successfully even if the presented certificate chain is invalid. It will also return successfully if the subject common name (CN) and subject alternate names (SAN) in the certificate don't match $1. One great way to get a sense for this is to try using s_client with various subdomains of badssl.com/ and seeing what the output looks like for different failure conditions.
To have your script give a better sense of whether the certificate is valid I recommend adding -CApath or -CAfile arguments pointing to your system CA trust store and a -verify_hostname $1 argument to force s_client to check the certificate hostname matches expected. It may also be beneficial to check the "Verify return code" output from s_client.
Hope that helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Paula, great post! I hadn't seen nmap used for this task before.
I think there's one potential problem to consider:
After you grep the
negotiationsfile contents you captured withopensslto make sure the correct renegotiation string is there your script concludes "Certificate validity ensured."Depending on what you meant here it might not be true and its mostly the fault of
openssl s_clienthaving really bad defaults :'(Your script uses
openssl s_client -connect $1:443but this command will return successfully even if the presented certificate chain is invalid. It will also return successfully if the subject common name (CN) and subject alternate names (SAN) in the certificate don't match$1. One great way to get a sense for this is to try usings_clientwith various subdomains of badssl.com/ and seeing what the output looks like for different failure conditions.To have your script give a better sense of whether the certificate is valid I recommend adding
-CApathor-CAfilearguments pointing to your system CA trust store and a-verify_hostname $1argument to forces_clientto check the certificate hostname matches expected. It may also be beneficial to check the "Verify return code" output froms_client.Hope that helps!