This can happen when sites use multiple certificates to manage the same page. A good example of this is https://www.gmail.com/ as requests to this website are redirected to https://mail.google.com. The certificate presented to the user is based on *.google.com, which does not match www.gmail.com.
If you're experiencing issues with the above type of scenario, you can create a new SSL access rule with the destination object set as either a request URL (for explicit deployments) or the server certificate URL or IP address of the site in question. The action in this rule should be set to a new server certificate validate object, with 'ignore hostname mismatch' as the chosen option. This will still cause the proxy to validate the Signing Authority, date and validity of the cert for the defined host.