Overview#Typically Certificates are validated by checking the signature hierarchy.
When you don't know in advance to which hosts the user-agent might be connecting, checking hostname match and chain of trust is the best you can do.
In many native apps, though, you know your hosts in advance. This enables a higher level of security: You can make sure that it is your certificate that the server has presented. This is known as SSL pinning or Certificate Pinning.
Certificate Pinning offers extra protection against Man-In-The-Middle attacker, perhaps perpetrated using a Compromised Certificate, or via social engineering ("Free Wi-Fi! Just add this root cert to your device!").
So for example, if you go to google.com, your user-agent will trust the certificate if it's signed by VeriSign, Digicert, Thawte, or the Hong Kong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, no Hong Kong Post office.
Also, some newer user-agents (Chrome, for example) will do a variation of Certificate Pinning using the HSTS mechanism. They preload a specific set of public key hashes into this the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key.
Explicitly added Certificate Authority#A certificate which is signed by a Certificate Authority which was explicitly added to the Trust Anchor Store will not be affected by the Certificate Pinning checks.
This is deliberately done to allow useful and legal SSL interception. Such interception can be found in most enterprise firewalls but also lots of desktop AV and is needed to scan HTTPS traffic for malware etc. If this would not be done malware delivery would simply move to HTTPS