Open rnikiforova opened 10 years ago
Mind sharing the URL? I can test it more easily with the example. On Sep 9, 2014 5:38 PM, "rnikiforova" notifications@github.com wrote:
I've tested an URL that doesn't have any SSL certificate whatsoever and it returns that SHA-1 is used. I think it's because the site is on a shared hosting and it detects the certificate of another site on the same server.
— Reply to this email directly or view it on GitHub https://github.com/konklone/shaaaaaaaaaaaaa/issues/47.
Here’s an example: https://shaaaaaaaaaaaaa.com/check/adlebbeke.be
Based on the example url, that looks like a server that is setup to return the default *:443 virtualhost to all domains on the box (sometimes referred to as shared ssl, though I don't know a lot of shared hosts that still do this):
➜ shaaaaaaaaaaaaa git:(master) ✗ ./bin/shaaaaaaaaaaaaa adlebbeke.be
{
"domain": "adlebbeke.be",
"cert": {
"algorithm": "sha1",
"raw": "sha1WithRSAEncryption",
"good": false,
"expires": "2015-02-17T23:59:59.000Z",
"name": "*.fronteers.nl"
}
In a browser, this is going to result in a ssl_error_bad_cert_domain error, but the tool is returning the correct information. Could mitigate this condition by matching the input domain against the common name on the returned certificate and return an error. Thoughts?
I also think matching the domains would be a good idea.
I'm reluctant to start domain matching, because I think it would imply that I'm using the same (sophisticated) logic an SSL client would use, which I'm not. What I think I could do is show some details of the match below the topline result (like the domain name on the client cert, and the names on the intermediary certs), so that it's more actionable and visible what's going on.
I've tested an URL that doesn't have any SSL certificate whatsoever and it returns that SHA-1 is used. I think it's because the site is on a shared hosting and it detects the certificate of another site on the same server.