Isn't this the same as using a certification authority?

Question

Taken from Wikipedia, here is the pretext to my question:

A certificate authority (CA) is an organization that stores public keys and their owners and every party in a communication trusts this organization (and knows its public key). When the user's web browser receives the public key from www.bank.example it also receives a digital signature of the key (with some more information, in a so-called X.509 certificate). The browser already possesses the public key of the CA and consequently can verify the signature, trust the certificate and the public key in it: since www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot create the signature needed to verify its authenticity.

I get that certification authorities help thwart man-in-the-middle attacks, but I don't understand the point of spending money to use a certification authority's certificate if browsers just hardcode the CA's public keys to validate it outside of HTTPS communications which seem to be somewhat browser-dependent because...assuming I use RSA encryption with SHA1 and OAEP padding on my server, isn't it just as secure if I:

• Generate a secondary private and public key pair
• Keep secondary key a secret, write it down somewhere and lock it inside a vault
• Always sign my server's primary public key with the secondary private key
• Hardcode the secondary public key in my client applications
• Use my secondary public key to check if the server is the server they say they are by checking that the public key they issue to me is signed with my secondary private key?

I am thinking of using this model over a TCP socket server where I can specify my own protocol and essentially be my own "browser"...

Essentially, is this all that's behind a CA? That's pretty sad...it honestly feels like a money-grab scam when you can just become your own CA. I mean, if the CA is compromised, browsers need to get patched, keys reissued, etc. If my client application becomes compromised, I don't need to wait while the hole is closed, I can quickly push out a new public/private key pair and send the public key of my pseudo-CA to client applications.

Answer 1

What you're describing is called certificate pinning; essentially, you ignore the whole CA process and just give the user application a certificate to trust. It's actually widely recommended for non-browser applications (e.g., mobile apps) for the exact reason you stated - if you rely on a CA and it goes down, you're in pretty deep trouble, whereas it's relatively easy to fix it quickly with certificate pinning by pushing a new certificate. Or better yet, you can have two certificates in your app, and rotate them if one goes down, then push a new certificate in the next update.

Of course, web browser makers can't amass and verify a collection of everyone's certificates ever, so they choose to trust a few centralized servers that then verify everyone else, and this is mostly successful at keeping users out of trouble. That's why the CA system exists.

I should clarify that you're still trusting a third party - it's just a different third party that doesn't charge you for the privilege. For instance, if we're talking about an iOS app, the app is signed by the App Store. That's what's preventing an attacker from swapping out your hard-coded certificate with another certificate.

Answer 2

What you intend to do by signing your primary key with a secondary key is essentially using your own CA. In theory, a CA is a third party trusted by the participant who tries to verify the identity of his communication party to reliably verify this identity. In practice, in web context this decision which CAs are trustworthy is not made by the end-user itself but by the browser vendor who includes the CAs root certificate (although a few users make their own decisions by modifying this preset list). In your setup, you control what the trustworthy issuers are, because you control your end users software. You don't even need another protocol, you could just use x509 certificates and configure that only your own CA is trusted.