Trusting internal self signed certificates

Tom Lous
2 min readJul 13, 2022


Https connections are fortunately the defacto standard these days for the public internet, powered by a phletora of certificate authorities from Comodo, GeoTrust or even Let’s Encrypt.

The problem for a lot of data- and platform engineers arrises when the internal sites are also https, but powered by self-singed certificates created by the company.

Could ‘they’ make this better and link every kubernetes web interface with letsencrypt. Probably, yes. However the fact of the matter is that it’s often a hassle, outside of the data engineer’s influence and frankly not a major issue.

In the past you could ignore these insecure warnings from your browser, or overrule them, but nowadays it’s a big hassle and frankly it stumped me for an hour until I could get it resolved with a latest Chrome update.

So for all you lazy engineers that don’t want to deal with the hassle, but also don’t want to do a bunch of manual actions to make it work, I’ve created this little bash script, which is mainly targeted at Mac-users, but maybe Linux users don’t have this issue and/or can work their way from my messy bash scripts.

Be ware that it should only be used for domains & certificates you explicitly trust. And probably only exists within some closed off VPN environment.

First let’s say our internal hostname is:

We need to get the (self signed) certificate locally as a file.

echo -n | \
openssl s_client -connect -servername 2>/dev/null | \
openssl x509 > ~/.ssh/certs/

You should inspect the file and see if you really got a certificate file stored.

Next we need to mark this certificate as trusted. You can do this by dragging the file into your keychain and marking it as trusted, but that seems very UI heavy, so here is a script that does the same

security add-trusted-cert -r trustAsRoot -k ~/Library/Keychains/login.keychain-db -p ssl -p basic -p timestamping -p IPSec -p eap ~/.ssh/certs/

This adds the cert to the keychain and marks it trusted for these parts. You can choose from ssl,smime,codeSign,IPSec,iChat,basic,swUpdate,pkgSign,pkinitClient,pkinitServer,timestamping,eap but these seem more then enough for our purpose

So now you can browse to your website and…

… still get the NET::ERR_CERT_AUTHORITY_INVALID message 🤦‍♂

You can check and see that the certificate is indeed marked as trusted, this works for almost all browsers, except for Chrome.

In Chrome there is one more trick:
When you see the error page, make sure it has the focus and just type thisisunsafe

You won’t see the characters popping up, but on the last letter the page reloads and this site is now always accessible via Chrome without the hassle.



Tom Lous

Freelance Data & ML Engineer | husband + father of 2 | #Spark #Scala #ZIO#BigData #ML #Kafka #Airflow #Kubernetes | Shodan Aikido