ERR_CERT_AUTHORITY_INVALID invalid certificate authority error. Ignore it?

Almost any web based tool in the office will have it. And we ignore it by default, without thinking about it.

And it was ok to do so. Before cloud days.

NOT ANYMORE…

Lets think about it for a bit.

Before Cloud
we connected to all of these web (https) based tools via Intranet, internal network. In most cases it was no way traffic would go through Public Internet, as it was no public connectivity to the tools.
Now, Cloud days
some of these tools are in Public IP range, and can be access via Internet.
In fact, sometimes the only way to access the web based tools hosted in the cloud is via Internet, as some smaller firms do not have Fast Connect, Direct Connect or VPN connectivity to their cloud. Only way to go is via Internet.
Or sometimes we just do not have visibility whether connection comes via public or private network, just because both options are available. (we can traceroute to confirm, but hey, how often we do it)

In cases where https traffic traverse internet it is NOT OK AT ALL to ignore Invalid or self-signed certificate error
like ERR_CERT_AUTHORITY_INVALID or SEC_ERROR_UNKNOWN_ISSUER.

Security wise It could be one of the most dangerous errors.

What is the problem?

In very simplified way.. During a secure connection a web tool needs to provide a certificate issued by a trusted certificate authority (CA) in order to ensure that the user is connected to the intended target and the connection is encrypted. If you get a “Your connection is not secure” error page, it means that the certificate provided was issued by a certificate authority that is NOT known by browser and therefore cannot be trusted.
Certificate Authority are world known companies like DigiCert or Comodo, and the list of them is static. This list is populated on browser instillation.

As purchasing certificate from Certificate Authorities and it’s installation is complicated, costly procedure which requires renewal, and involve people from multiple areas, – most of certificates which are used in web based local tools are self-signed certificates, i.e. certificates which are generated by simple openssl command, not by known Certificate Authority.
When https traffic traverse Internet and you see this error, it is hard to tell:

• whether problem is just your self-signed certificate (not big deal), or
• something on your network is intercepting your connection and injecting certificates in a way that is not trusted, malicious way. If this is the case, you might be affected by man-in-the-middle attack and somebody sniffing/listening your https traffic in un-encrypted form.

How to fix it?

• One way would be to get valid Certificate, but again.. it is pretty involved task.
• Another way would be to wrap that https traffic into another layer on encryption, which does not involve concept of Certificate Authorities. Ssh forwarding is good option here. But ssh forwarding can also become maintenance headache, and it adds performance overheat.
• Another option – use tool which does not involve https.

Oracle Enterprise Manager (OEM) is one of those web based tools.
OEM is very functional, and sometimes you have to have it. ssh forwarding is solution for it.

But if you need just to check DB performance, try Oracle DB Monitor (ODBM):
https://github.com/AVM-Consulting/oracle-db-monitor

It is very simple, customizable and functional tool. More details in README.