Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Will I have a more secure / encrypted connection if I had a self-signed chain of certificates instead of using only one single self-signed certificate?
[Root CA -> Intermediate 1 -> Intermediate 2 -> my.api.com]
vs
[Root CA -> my.api.com]
Or does that have no impact on encryption?
For the security of the connection it does not matter if you have intermediate certificates and how many. The strength of the encryption depends on the cipher used in key exchange and encryption which is mostly independent of the certificate and fully independent of any chain certificates. Certificates are mainly used for authentication to prevent man in the middle attacks and all which is relevant here is that the attacker cannot fake any of the certificates involved, i.e. does not have access to any of the private keys and cannot trick a certificate authority (or hack it) so that it issues a trusted certificate for the specific domain.
No, it does not affect the encryption.
A chain of self-signed certificates can help make a connection more secure, but that's just because it makes certificate handling in your organisation easier and therefore more likely to work correctly without having the browser ask for user intervention, NOT because the strength of the encryption increases.
Certificates are used to make sure that the public key you receive from the server really does belong to the server, and not to a Malory, who sits somewhere in the middle between you and the server.
If you use just a single self-signed certificate, your browser will complain that the authenticy of the certificate can't be established. You'll get exactly the same warning message when Malory replaces your certificate with his own, so if you're using self-signed certificates, you can't readily distinguish between normal operation and a mitm attack.
You can add your private certificate to the browser or os certificate store to make the browser accept it, but managing certificate renewal, replacement etc is a pain if you do it like this in contexts where you have even just ten or twenty machines to support.
So a solution that requires less effort is to add a private root certificate instead, which you'll need to touch much less often. Certificate handling becomes easier, which means it can be done with less effort, which means it's more likely to be done correctly, or at all, which means users are less likely to see browser warnings for untrusted certificates they'll just click away. So in a roundabout way, I'd say there are security advantages in using a chain of self-signed certificates in a context where you are resonsible for the upkeep of a number of machines that need access to your resource.
Of course, if anyone gets access to your private certificate authority, you've just given them potential access to every ssl-encrypted connection your users make, so there's serious disadvantages too.
Generally, however, there's really no reason why you should self-sign certificates, unless you have trust issues with the default certificate authoriities. Lets Encrypt gives you free certificates that work in every browser, out of the box.
No it is not "more secure", and it has no impact on the encryption itself.
An Intermediate certificate simply say that that Intermediate Certificate Signer 1 trusts your my.api.com certificate. A client should trust the entire certificate chain before allowing the connection to proceed.
It is not so much the encryption’s security, but more about what happens once the signing CA gets compromised. The root CA can revoke the intermediate CA, and create a new one, without being affected itself. Validating the fingerprint of the root CA makes a lot of sense in that scenario, because online crtificate revocation checking is weak in general.
