The error in the screenshot indicates not that the certificate itself is invalid or cannot be validated or is installed wrong, but rather that the host part of the URI (eg. the DNS name or the IP address if the IP address was entered to access the site) does not match the subject CN (canonical name) or a SAN (subject alternative name) in the certificate. Alas, you've blanked out all the information that would help isolate why exactly this is happening in your case, but it is easy to explain in general terms.
If a certificate is issued for
www.example.tld, and the site is accessed using
https://example.tld, the certificate will not validate. The inverse is also true: if it is issued for
example.tld, it will not validate when presented to verify
One solution to overcome this is the SAN field. This allows you to specify multiple names for which the certificate is valid, so that you can present it for each domain and subdomain you specify. However, if the name isn't mentioned in the certificate (or the user agent is horribly out of date and doesn't understand SANs), the certificate is invalid.
Wildcard certificates are a second solution to this problem. They will validate for all subdomains of a domain. For example,
mail.example.com can all validly present a certificate with a subject CN of
example.com with a SAN
The IP address of a site can also be the subject CN or an SAN for a certificate, allowing your SSL certificate to be valid even when a site is accessed with something like
https://192.0.2.1/. It is rare that providers will do this, and none will do it unless the IP address is recorded as being assigned to you or your organization (and not your ISP) in the appropriate RIR records or at least the WHOIS records as delegated.
One of these things will be the reason the certificate you presented is not the right one.