I am concerned about the hacking of a root CA and want to buy 3 SSL certs from completely different providers who will independently validate my identity. Then at presentation time, I will send all 3 "certifications" to the client.

What approaches exist to accommodate this need from either a protocol perspective, or crypto (where the keys are joined in some way)?


  • An existing HTTP web client, chrome extension, or SOCKS/Proxy that does additional validation
  • A proof of concept for another implementation not yet invented (e.g. a new version of TLS incorporating new encryption)

The possible solutions I've thought of include:

  • Client makes 3 HTTPS requests, where each request is encrypted with a different certificate. The response should be a random number that is equal in all 3 responses.

  • 2 keys are signed and contain a x509 custom field that references the serial number of the "validated" certificate

  • The keys are mathematically combined in an interesting way that reduces the multiple requests into a single request. (RSA or ECC/Subgroups)


  1. Does such a protocol exist in draft form anywhere?

  2. Is there a way to mathematically combine the validation of N certificates without losing security?

    a. I'm interested in crypto that authenticates me 3x as a web host

    b. Increases the integrity of the data with a 3x signed data stream

    c. Increases the privacy of the data with 3x the encryption

(Note I know DANE might satisfy part of this requirement, but I'm looking for a non DANE / HTS solution)

  • Are you intending to having this functioning in a standard web context? (i.e. HTTPS in a browser)
    – Nic Barker
    Aug 29, 2015 at 2:25
  • Yes, please provide better context. The question as it exists sounds more like a proof of concept, whether you can verify the content of a source by means of 3 separate CA's. This would be trivial with 3 certificates and asymmetric encryption. Implementing such a task into a secure and functional site would be the challenge and would (assumed) need to be implemented by a trusted third party (the browser). Aug 29, 2015 at 2:33
  • @NicBarker It would be hard to do, but I'll take any approach. Aug 29, 2015 at 3:55
  • @DavidHoude Added additional context Aug 29, 2015 at 3:56
  • In the context of risk management I would recommend to think again before expending such an effort. If one's able to break into a root CA it's very likely that they will also be able to break into your system.
    – Noir
    Aug 29, 2015 at 16:26

1 Answer 1


There is no standard way to do what you envision and I'm not aware of any proposals of relevance. The currently established PKI structure allows only for a single certificate chain (i.e. a single issuer for a certificate) and the TLS protocol like used allows only for a single leaf certificate. In theory one might create a certificate with multiple issuers using certificate extensions and in theory one could extend the validation process in TLS to check for multiple issuers. But again I'm not aware of any serious proposals in this area.

Serving different certificates via multiple HTTPS requests needs also some kind of extensions or hacks, because the server needs to know which of the certificates it needs to send. With new TLS extensions the client could ask for a specific certificate. Without the client might re-use existing extensions like SNI for a different purpose, i.e. give slightly different target host names. Or one could provide different IP addresses in the DNS and each IP address servers a different certificate. Or one could randomly rotate certificates. In all these cases the client has to be aware that it should try to get multiple certificates and how much certificates it should get and how to combine the information. This means some knowledge is needed about the server which is either coded into each certificate (i.e. certificate extension) or which the client got from the external resource in a secure way.

Because there is no standard or even proposed standard to do this you either need to invent your own or try to get the best from the current standards. Since hacking of a root CA is your main concern you might be already protected enough with the existing standard HPKP, i.e. certificate pinning on first use. This way no compromised CA can create a usable certificate in your name which gets accepted by browsers which visited you already, because the attacker would need your private key to misuse the certificate. And if HPKP is not enough you could apply for your public key to be included in the browser as it gets shipped. And this public key pinning is not restricted to a specific CA but only to your key pair, which means the key and thus the HPKP information stay the same if you use the same key in another certificate signed by a different CA. Thus you can easily change CA if one gets distrusted by the browser. Not all browsers currently support HPKP but it gets better. So this is probably the best you could get without trying to establish yet another standard or create a little used browser extension. If HPKP is not an option for you the you might add the reasons for this to your question.

You must log in to answer this question.

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