So I've googled quite a bit for this but it appears that my google-fu fails me - apologies if this is a trivial and already answered question, I could not find anything about this

I'm trying to diagnose an SSL certificate hostname mismatch. When I visit the url in question, it redirects me to another page that has the correct SSL certificate. However, some clients are reporting that they are receiving an SSL certificate hostname mismatch error. My only assumption is that the redirecting page has the wrong certificate and some clients are letting it slide because it resolves with a new page that has the correct certificate.

(The how and why of the issue isn't really the question)

The question:

From the outside in (aka, as a client in the world) - how would one view the certificate that was delivered by a page that automatically redirects to another page?

  • 1
    Another useful resource is the SSL Server Test from Qualy's SSL Labs.
    – TRiG
    Jan 18, 2019 at 14:34

6 Answers 6


Use openssl s_client piped to openssl x509:

$ openssl s_client -connect foo.example.com:443 < /dev/null | openssl x509 -text

(Add -servername foo.example.com to the s_client command if the server uses SNI.)

The redirection of stdin from /dev/null for the first invocation of openssl will prevent it from hanging waiting for input.

  • 2
    You can also pipe the output to openssl x509 -text to actually see what's in the server's cert, and redirect the input of the initial openssl command from /dev/null so the command doesn't hang: openssl s_client -connect ... < /dev/null | openssl x509 -text. Look for the "X509v3 Subject Alternative Name" field. Jun 22, 2015 at 22:20
  • @AndrewHenle Great addition. Feel free to edit that into my answer if you'd like.
    – EEAA
    Jun 22, 2015 at 22:31
  • Worked like a charm - I've only spent a limited amount of time with openSSL, yet everytime I need to do anything ssl related it always boils back down to it haha...Thanks for the tip! Jun 22, 2015 at 22:49
  • 6
    If the server uses SNI, you should add -servername foo.example.com to the s_client options.
    – Bruno
    Jun 23, 2015 at 15:24
  • 1
    @Bruno+ update: since OpenSSL 1.1.1 in 2018 -servername is now default (though it doesn't hurt to redundantly specify it). Also, if you have Java 7 up installed (which is rarer now than it used to be) keytool -printcert -sslserver $host[:$port] Jun 23, 2020 at 7:25

In Firefox 57, if you open the Developer Tools and go to the Network tab:

  1. Make sure Persist Logs is checked
  2. Visit the URL of interest
  3. Click on the top row (i.e., the one corresponding to the request to the server you're interested in, which resulted in the redirect response)
  4. Click on the Security tab (half-way down, still within Network)

This will let you view certificate info such as the issuee common name, issuer details, validity period and fingerprints.

This worked for me on a site responding with a 301 redirect to another HTTPS website. (Unfortunately the accepted answer just gave me the certificate for the final destination page.)

  • Thanks for a native Browser method. Did you try the -servername option with openssl? That can give a different result, even if it's the same name.
    – mwfearnley
    Jul 4, 2018 at 12:54
  • @mwfearnley No! With openssl, I just copied and pasted from the answer and gave up after it didn't work :) Thanks for the suggestion.
    – mpavey
    Oct 16, 2018 at 20:50
  • Firefox 71. Had to check Disable Cache also in order to make the Security tab visible. Jan 8, 2020 at 12:25

Also, there is a graphical tool for Windows with detailed text trace: SSL Certificate Verifier Tool and tool description: Verifying The SSL Certificates with a tool and here is an example of how it handles redirects:

enter image description here


As an alternative to the separate programs mentioned in other answers, you can also disable automatic redirection in your browser.

The option to do this varies by browser, here are methods for Firefox and Chrome:

  • Not sure who downvoted this? Jun 23, 2015 at 16:32
  • Yeah, this is exactly what I wanted, a completely in-browser solution. Sep 27, 2016 at 19:34
  • 4
    This didn't work for me in Chrome. I can see the 302 in the network trace, but I don't see how to inspect the certificate from the network traces. If I click the Security tab, Chrome instead shows me the cert from the current webpage (the redirection target).
    – Carl Walsh
    Jan 3, 2017 at 16:31
  • 2
    @jpa The link you provided for Chrome appears to explain how to preserve the network log after a redirect has taken place, rather than how to prevent Chrome from following the redirect.
    – mpavey
    Aug 1, 2017 at 19:11
  • 2
    down voted- this answer is not useful on Chrome. The linked resource shows how to enable "preserve log" which still does not allow the SSL cert of the redirecting domain to be introspected. Does not actually answer OP.
    – Brad Wood
    Feb 8, 2021 at 22:04

Try mangling the url, so it fails to redirect. eg: https://www.example.com/>

Depending on the server you may be able to hit a URL that returns an error instead of redirecting. For example if you're visiting an IIS server appendending > to the URL will show an error page, but the cert can then be viewed in the normal way as this prevents the redirect occurring.


Attempting this again today, what worked for me on Windows was:

  1. Go to https://www.ssllabs.com/ssltest/ and enter the domain (not URL) you want the certificate for.
  2. Let the SSL report process.
  3. In the output click the Download server certificate button.
  4. Save the output to a *.cer file.
  5. Double-click the file and voila!

Download server certificate button

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .