I'm trying to use a site that's https but has it's own certificate, and when I add an exception it still shows it as unsecure, with an exclamation on the padlock and when I click the padlock it says "Connection not secure" and "You are not securely connected to this site" in Firefox. I get similar things in Chrome, where https is actually crossed out and it says "Not secure" and "Your connection to this site is not secure." I even added the root certificates provided by the site and nothing changed. I'm having a hard time finding info specific to this, but from what I can tell (mainly based on this answer, though it's over a decade old and I'm not sure if things have changed), it seems it is a secure connection with regard to being an encrypted connection with the site that a MITM couldn't intercept, and it's only "unsecure" in the sense it can't verify I'm connected to the site/server I think I am. Is that correct? Because I've verified the fingerprint of the site with someone who has the proper certificates for their browser to verify it, but I'm wary based on the wording of the messages that info I submit on it could be intercepted. It seems like it's just poor wording, in which case it should probably be changed to be more clear, but I'd like to be sure before using it.
-
Verifying a site's certificate is an involved process and by no means merely the site having a certificate is enough for it to be valid. Some common examples are expired certificates, and certificates that do not match the site name. Furthermore, if you enter the site while inspecting the browser's "developer tools" you should be able to see exactly what the browser doesn't like about the site. (At least in Chrome that is the case).– AmitFeb 5 at 16:05
-
On the more practical side: I would suggest you to definitely trust that your browser uses the word "unsecure" for a very good reason, and indeed it is best to avoid such sites. Of course, the site may be perfectly legitimate but just poorly configured and maintained. Still, an attacker wouldn't necessarily mind taking advantage of that - so it's important to understand that an insecure site doesn't necessarily mean a malicious site.– AmitFeb 5 at 16:23
-
As I mentioned, it's flagging it because the site uses its own certificate. It's a legitimate site and I've verified the certificate, I just don't know if that's enough, i.e. if the connection to the site is encrypted, or if the browser isn't making a secure connection.– vertigoFeb 5 at 20:17
-
By "own" certificate do you mean a self-signed certificate? Self-signed certificates render the site HTTPS trivially breakable since once the browser is allowed to use any self signed certificate for a site, a man in the middle can replace it with his own version of a self-signed certificate - completely identical to the original one apart from the public key. Now, sure if you have some way of verifying that you are using the correct public key, as you say via the fingerprint, etc. it may be okay... still, this is rather tricky because do you really bother to verify the fingerprint.– AmitFeb 5 at 20:29
-
... each and every time you make a new TLS handshake to the site? (which the browser or the site can practically initiate whenever they need / want to) That wouldn't be reasonable... so I think the risk is great, especially if you are sending any sensitive info to that site.– AmitFeb 5 at 20:30
1 Answer
As the comments explain, self-signed certificates (which I assume is what you mean by "its own" certificate, even though all trusted sites use their own certificates and it wouldn't work if they used somebody else's) are untrustworthy because it's highly impractical to verify the certificate is correct even once (in most cases), much less every single time you connect. Some browsers will let you trust the specific certificate for the specific site, but even then they will likely flag it; the browser has no way to know whether you, the user, verified anything at all. Additionally, self-signed certificates usually can't be checked for revocation.
The correct way to make a site's certificate trusted - if for some reason you can't use a certificate from a trusted certificate authority (CA) - is to add the certificate's CA to your list of "trusted root CAs". This is a highly dangerous operation - it will allow the owner of that CA's private key to forge a "trusted" certificate for any site (aside from a few that have pinning by the browser or another client) so you'd better trust that CA owner completely - but it should work. If you did this and it didn't work, either one or both certificates are invalid for some reason (outside validity period, issuer is not a valid CA cert, leaf cert if not valid for server authentication, certificate signature algorithm is too weak to trust, etc.), or you did something wrong (added the wrong certificate, added it to the wrong list, added it to a list not checked by your client, etc.). Note that e.g. Firefox has its own CA list independent of the OS certificate store, and also that e.g. MacOS requires you to mark a certificate as "trusted" even after installing it. Furthermore, it's sometimes not possible to trust a self-signed certificate at all; you need a separate signer certificate (valid to issue certs, not to authenticate sites, self-signed, installed in the client's trusted CA list) and a leaf/site certificate (valid to authenticate sites, not to issue certs, signed by the CA cert's private key, served by the webserver).
The "temporary exception" behavior that browsers offer upon encountering an untrusted certificate varies from browser to browser. Sometimes it makes that specific cert trusted for that specific site indefinitely. Sometimes it does so for only a short time, or only within that tab. Sometimes it starts the process to import the certificate's issuer's certificate (if available) into the list of trusted CAs. Maybe some do something else.
