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.
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.