when I checked the fingerprint of an website with openssl
echo "" | openssl s_client -proxy proxy-vip:3128 -showcerts -connect saucelabs.com:443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;/-END CERTIFICATE-/a\\x0' | sed -e '$ d' | xargs -0rl -I% sh -c "echo '%' | openssl x509 -fingerprint -noout -sha1"
I get the following result:
SHA1 Fingerprint=F7:62:50:60:C2:DC:A9:29:96:B5:99:C2:DB:2A:71:BD:EA:57:0B:F9
SHA1 Fingerprint=2E:49:16:B0:7F:3D:E9:0C:8D:DE:25:66:FD:9B:9B:40:0D:89:BB:BA
SHA1 Fingerprint=03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
But, if I check the fingerprint within the browser, the result is:
80:27:83:5F:A8:81:6B:97:E2:60:FF:B3:A9:7B:69:E1:F2:38:9A:7A
Why did I get different results?
Short answer is that you're getting different fingerprints because they are actually different certificates :)
Longer answer:
The server at the IP for saucelabs.com is serving the content from apps.saucelabs.com to the openssl s_client utility. You can see this if you print the subject CN of the certificate (note the addition of -subject to the final openssl command).
$ echo "" | openssl s_client -showcerts \
-connect saucelabs.com:443 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;
/-END CERTIFICATE-/a\\x0' |\
sed -e '$ d' | xargs -0rl -I% sh -c "echo '%' | \
openssl x509 -fingerprint -noout -sha1 -subject"
SHA1 Fingerprint=F7:62:50:60:C2:DC:A9:29:96:B5:99:C2:DB:2A:71:BD:EA:57:0B:F9
subject=CN = app.saucelabs.com
SHA1 Fingerprint=2E:49:16:B0:7F:3D:E9:0C:8D:DE:25:66:FD:9B:9B:40:0D:89:BB:BA
subject=C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G2
SHA1 Fingerprint=03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
subject=C = US, O = GeoTrust Inc., OU = (c) 2008 GeoTrust Inc. - For authorized use only, CN = GeoTrust Primary Certification Authority - G3
And if you compare that to the info in your browser, you'll note that your browser is getting the certificate for saucelabs.com instead of the one for apps.saucelabs.com which you're getting redirected to.
The server is using SNI to decide which server to send your request to. Apparently, without an sni, the server at saucelabs.com serves the content from apps.saucelab.com. Now, if you want to see the certificates for saucelabs.com then go ahead and send an sni message like your browser does (note the addition of -servername option to the s_client command):
$ echo "" | openssl s_client -servername "saucelabs.com" \
-showcerts \
-connect saucelabs.com:443 2>&1 | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;
/-END CERTIFICATE-/a\\x0' | sed -e '$ d' | \
xargs -0rl -I% sh -c "echo '%' | \
openssl x509 -fingerprint -noout -sha1 -subject"
SHA1 Fingerprint=80:27:83:5F:A8:81:6B:97:E2:60:FF:B3:A9:7B:69:E1:F2:38:9A:7A
subject=CN = saucelabs.com
SHA1 Fingerprint=2E:49:16:B0:7F:3D:E9:0C:8D:DE:25:66:FD:9B:9B:40:0D:89:BB:BA
subject=C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G2
SHA1 Fingerprint=03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
subject=C = US, O = GeoTrust Inc., OU = (c) 2008 GeoTrust Inc. - For authorized use only, CN = GeoTrust Primary Certification Authority - G3
And there's the 80...7A hash your browser shows you :)