When to use private keys and when to avoid in SSL?

Question

So I have a few questions that has been kicking around in my head that I've filled with assumptions that may be incorrect.

1. From what I understand, we need private key (in the format signedcert+privatekeycert) in every server in an infrastructure that communicates with another server with SSL. Because the private key needs to be there to decrypt messages received for SSL.
2. Verification is done either by trusted authorities, trusted intermediaries based on certain modes of operation: verify-full (verifies both intermediates & roots), verify-ca (just roots). But you still need private keys for every server unless you are doing one-way SSL right?
3. What is a chain "bundle"? in some documentation they wrote something like the cert files configured for nginx requires chain bundle. I'm not sure what that means exactly when they said chain bundle in the certificate file between certificate-signed to intermediate CA to root CA. I'm assuming it just means ---begin certificate--- ---begin certificate---- ---begin-certificate---- three certificates in a chain (signed -> intermediate -> root).

Thanks for any help clearing up these misconceptions in my head.

Answer 1

1. ... Because the private key needs to be there to encrypt messages for SSL.

The private key is needed whenever a party needs to authenticate itself using a certificate. This includes web servers but might also include clients in case of client certificates. The key is not used to encrypt the messages but is used to proof ownership of the certificate using a digital signatures. This proof of ownership is essential to protect against man in the middle attacks. The private key might also be used in the key exchange, but only in the RSA key exchange. The result of the key exchange are shared symmetric keys. Only these get used to encrypt the messages and not the private key.

2. Verification is done either by trusted authorities, trusted intermediaries based on certain modes of operation: verify-full (verifies both intermediates & roots), verify-ca (just roots). But you still need private keys for every server unless you are doing one-way SSL right?

I'm not sure what you mean with verify-full and verify-ca. The verification if a certificate is issued by a trusted CA is done by building a trust chain from the leaf certificate (i.e. server certificate in case of a web server) to a locally trusted root CA. This trust chain is build and verified using the issuer information and signature on the certificate. The chain might involve multiple intermediate certificates from the leaf certificate up to the locally trusted root. These intermediate certificate might be send by the peer or might be known locally already, but the end of the trust chain (root CA) must always be locally trusted already.

See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for a nice description on how the chain gets build and verified.

3. What is a chain "bundle"? ...

The chain bundle contains all the intermediate certificates which the server should send additionally to the leaf certificate. These are the intermediate certificates which are needed by the client to build the chain from the leaf certificate to the locally trusted root CA certificate.

Answer 2

A few things about servers with paired key encryption.

Servers will need both a public and private keys. The private key is used by the server to decrypt data encrypted with the public key. The public key can be shared openly without risk. Once data is sent back to the server it uses the private key to decrypt the data.

Now with certificates specifically (and also many pair key management systems) there are additional protections in the server to make a private key non-exportable. This can be achieved either in software with the support of the operating system as in the base certificate store. It can be done with hardware that doesn't allow the private key to be exported such as a from an HSM or TPM.

To your items 1, 2, and 3.

1. This is backward. The private key is used to decrypt messages and sign outgoing items. You would use the other parties public key to encrypt a message before sending it back out. There is then the whole system for efficient communication which then moves the communication process over to a shares symmetric key but that's a different story.

2. Trusted authorities exist so that a group of shares root certificates can be disseminated in advance and the system can work. Root CAs are beholden to a code of conduct that says they will perform due diligence for all certificates issued. The recent removal of CAs and expiration of Root certificates from compromised CAs speaks to how tenuous this system is. CAs have nothing to do with the encryption itself, only on the methods of trusting certificates that are used by servers and browsers as we as revoking certificates. Note that not all operating systems perform revocation checks.

3. Chain bundles are all of the signed certificates that you need for a certificate issued at the lowest level to be verified. This brings up another topic which is that certificates can be issued with purposes, and one of those purposes can be to issue (sign) more certificates. Ordinarily a Root CA will have a master certificate that is locked away from everyone, and if that certificate is compromised then the whole company's business comes to an end. The CA then issues themselves an intermediate certificate which can be revoked more easily without everyone's certificates being invalidated. The certificate you buy is restricted from issuing further certificates. If you set up your own private Root CA in a company you would want to mirror this and create do all of your issuance from an intermediate certificate.