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.

2 Answers 2


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.

  • 1
    I was under the impression they did some due diligence to verify that people applying for certificates actually own the domains in question. I might be wrong about that, though. Commented Jul 4, 2014 at 1:10
  • 1
    Check this out: security.stackexchange.com/questions/38199/…
    – Alexandru
    Commented Jul 4, 2014 at 2:02
  • 1
    Then check this out: security.stackexchange.com/questions/36781/…
    – Alexandru
    Commented Jul 4, 2014 at 2:06
  • 1
    Well...to be fair, if a sufficiently resourceful nation-state is out for your blood, you're gonna have a bad time no matter what. Commented Jul 4, 2014 at 2:11
  • 1
    Right, although the App Store is less likely to be compromised than some CA in Turkey. Commented Jul 4, 2014 at 2:19

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.

  • I could, but it won't be transparent. In terms of multiplayer games, almost all users don't know how to configure a certificate and add it to the list of trusted certificate authorities, and if they had to even do that across every device that I distribute my client app on, then they'd probably decide to not use my app at all.
    – Alexandru
    Commented Jul 4, 2014 at 12:10
  • 1
    Since you wrote you intended to implement you own protocol, I thought you game was only playable by app where you could control the list of trusted CAs.
    – Drunix
    Commented Jul 4, 2014 at 12:56
  • Oh, I see. You mean to do all the pseudo-CA validation in the app itself, not to use the (for example) iPhone's built-in CA validation scheme.
    – Alexandru
    Commented Jul 4, 2014 at 13:00
  • Yes. In java apps you could for example supply your own truststore with your CA certificate ("secondary key") included or provide a custom X509TrustManager. Don't know how to do that on iOS.
    – Drunix
    Commented Jul 4, 2014 at 13:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .