Note that the tool does not check validity of certificates

[jonnybarnes]

At the time of posting shanehudson.net actually returns a cert for shanehudson.co.uk

We should warn users about this misconfiguration when it occurs.

[konklone]

I'm not sure we should. Instead, I'd prefer to indicate to the user that we specifically don't validate certificates, and link them to SSL Labs to do that. Validation of certs is much much more complicated than checking the signature algorithm, and I don't want to reinvent SSL Labs here.

I'll leave this ticket open until it's clarified one way or the other on the site.

[konklone]

FWIW, I did check to see if openssl does that automatically in its openssl s_client call, but it does not. However, even if I could find an openssl command that did that, I'd like to leave the door open to ditching the remaining openssl call in favor of an in-code approach (like I did in #30 by removing openssl x509).

[jonnybarnes]

Presumably the -showcerts will expose the CN of the cert that we could then check what they entered in the field against. I agree we aren't checking how well they have set up their SSL/TLS. But if they have set it up in an invalid way we should probably throw a warning.

[konklone]

I just see it being a long tail of bugs ("your validity checker is broken, you're not checking expiration dates", "you're not checking wildcards", "you're not analyzing the validity of the intermediates or root", etc.), and a larger code surface to watch over. The more we can stick to the mission of validating SHA-2 readiness, the simpler the infrastructure will stay and the less of the Internet's entropy we'll need to plan for.

[jonnybarnes]

Thinking about it I agree, though maybe mention as much on the page. Something like "we are only checking for SHA-1/2, for a more complete check of your certificates and ssl/tls setup try SLL Labs."

[konklone]

Let's definitely do that.