The purpose of certificates is to prove the identity of the remote party you are communicating with. Failing this would make it possible for impersonation to take place: active MITM attackers could intercept the traffic and alter it to make it pass as their own.
It's quite similar to verifying someone's identity by checking a passport. Suppose you want to verify the name of the person in front of you, who is showing you a passport.
You want to verify that you trust the authenticity of the passport itself. A local sports club membership card might not be enough. Checking this aspect of a certificate is what building a certification path to a trusted CA in the PKIX specification (RFC 5280/RFC 3280) is for; it also provides other aspects such as what purpose the CA was willing to allow it for.
You want to verify that the passport belongs to the person whose identity you're trying to check. (In this analogy, the server name is more akin to the person's picture, since you're trying to find the person's name, knowing what they look like (*).)
It's one thing to trust the the passport is real, but it should be issued to the person who is claiming its usage. Failing that, anyone who has got hold of a passport of a country you recognise could claim they're anyone in any country you recognise.
In the HTTPS world, this is done following the rules in RFC 2818 (Section 3.1), and more generally in SSL/TLS in RFC 6125.
- The last point is not strictly part of the certificate verification itself. You want to verify bind the picture in the passport to the person in front of you. In this analogy, the picture to person link is ensured by the authenticated key exchange in TLS, which guarantees that the remote party has the private key matching the public key in this certificate.
Having performed those three steps successfully, you can then bind the name in the passport to the physical person in front of you.
Certificates in SSL/TLS have the same role: you want to make sure the certificate comes from a CA you trust, make sure that it's issued to the server you want to communicate with, and make sure you're talking to the party to which that certificate was issued.
More specifically in your example, the certificate was issued to DI-PRE-UFCG, which is a different name to the one you're trying to contact and sec_error_untrusted_issuer indicates that the browser doesn't even recognise it as issued by an entity it trusts (which makes sense for a self-signed certificate that wouldn't be imported explicitly).
(*) I'm only making the analogy in that order because it's more natural in practice in my experience. You rarely start off by looking for a specific person by name, given a crowd and their passports, but this could make sense in some circumstances. You would have similar problems if someone had multiple aliases, but the one you're looking for wasn't the one of their passport.
