I've seen Firefox poping up the message "Untrusted Connection" where self signed certificates are involved.

However, I could not understand what the following means (in bold) : XXXX.XXXX.XXXX:8443 uses an invalid security certificate.

The certificate is not trusted because it is self-signed. The certificate is only valid for DI-PRE-UFCG

(Error code: sec_error_untrusted_issuer)

Also firefox shows the following under "I understand the risks" If you understand what's going on, you can tell Firefox to start trusting this site's identification. Even if you trust the site, this error could mean that someone is tampering with your connection.

Can anybody please explain what does tampering with connection in this scenario mean ? Also what does valid for DI-PRE-UFCG mean ?

Thanks in advance

3 Answers 3


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.



The possibility of a someone interfering with the connection is mainly a concern for Man in the Middle(MITM) Attacks. When the user attempts to connect to the server if an attacker is able to get inbetween the server and client by sppofing the IP, the DNS, or even possibly the MAC address (If the attacker in on your LAN) there is a way that the attacker can present a bogus ssl certificate and website facade or proxy the website connection. Now that unsuspecting user clicks trust the certificate that is not signed by a legitimate Certificate Authority(CA) (i.e. Verisign) the attacker then will have access to the cleartext (unencrypted data) and be able to sniff/record all the traffic between the user and SSL enabled webserver.

Lucky for most of us browers come preinstalled with a list of CA's that you can generally trust and when one of those CA's that signed a cert is not on that list or if the certificate is self signed you will get that sort of error asking "are you sure?".

As for the string you mentioned I beleive DI-PRE-UFCG probably has something to do with the SSL website you are connecting to and a mesage that this exception is only valid for the CA DI-PRE-UFCG that signed that particular certificate.

I hope that helps,



Depends which site you log into. If it's a bank and a self signed cert obviously there's a MITM attack problem going on. If it's a small forum or something and they just generated their own self signed cert then no problems.

If you want a better SSL method then go to convergence.io and install the firefox plugin. Look up Moxie Marlinspike's BlackHat 2011 SSL presentation for more information, you'd be surprised how many stolen private keys are floating around from cert authorities that can be used to sign your own fake MITM site. Some of them just leave them out in plain view for anybody to download. Yes, private SSL signing keys just lying around.


You must log in to answer this question.

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