I just ordered a cheap Comodo PositiveSSL Certificate via a UK reseller, and I was rather surprised to find that the following files were emailed to me automatically, in a zip file:

  • Root CA Certificate - AddTrustExternalCARoot.crt
  • Intermediate CA Certificate - COMODORSAAddTrustCA.crt
  • Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt
  • Your PositiveSSL Certificate - domain_name.crt

Additionally the cert itself (the last file) is added in text form at the end of the email.

It's for a site that does not need a lot of security - it does not handle credit cards or other highly confidential information. I set up a strong passphrase on the associated private key.

Am I right in assuming this cert is useless without the private key and passphrase? Or, given that email can be considered compromised, would an attacker wishing to decrypt my site traffic be at an advantage if they have these files?

I am minded to re-generate the certificate immediately, but I worry that Comodo will just "helpfully" send me a new zip file. I would much rather download all these files from the reseller's SSL website.

  • 11
    Note that you can export exact copies of them for any HTTPS sites using web browsers.
    – user23013
    Jul 16, 2015 at 13:00
  • 2
    Looks like a have a lot to learn about SSL @user23013! - thanks, most useful.
    – halfer
    Jul 16, 2015 at 13:27
  • 6
    It's called the public key for a reason :) Jul 16, 2015 at 16:13
  • It is useful to know that some e-mail clients like Outlook may block attachments of these types for security. As previous comments advise as long as the recipient doesn’t have the private key it’s safe. support.office.com/en-au/article/… Jul 16, 2015 at 16:18
  • @BlueRaja, heh! I've got a bit of PPK knowledge, but with SSL, I've not previously considered which part is public. I've never heard of an SSL cert being referred to as a public key before - now I know.
    – halfer
    Jul 16, 2015 at 16:25

2 Answers 2


You are right assuming the certificate is useless without the private key, so sending it in the mail is no big security risk and is common practice actually. The certificate is supposed to be public, connecting to your website would also provide me with your certificate, so no need to hack your email there.


When starting the connection the server sends the certificate which incorporates the public key. The client will generate a (symmetric) session key used for encrypting the rest of the communication and encrypt this with the public key. Now only the server with the corresponding private key can decrypt this session key and use it to decrypt and encrypt the following data.

This way it doesn't matter if someone else has your certificate, as long as they don't have the private key belonging to it, they won't be able to decrypt the session key and won't be able to impersonate your server.

  • 1
    So, to clarify, sending a private key by email, is a big risk.
    – Brandon
    Jul 16, 2015 at 15:51
  • 19
    Sending the private key in an e-mail is a big risk, never do this!
    – BadSkillz
    Jul 16, 2015 at 15:54
  • 7
    That is also why you generate the key locally and send a Certificate Signing Request to the CA, which contains the public key only. Jul 17, 2015 at 6:44
  • Sending the public key over an insecure channel like email is also a risk if you're going to use that key as a basis for trust. This is not an issue for CA-signed certs, but it would matter for self-signed certs, or for CA certs for an organization-internal CA you want to use as a basis for trust, etc. The problem is not the exposure of the key, but the possibility that it could be tampered with in transit. Jul 17, 2015 at 23:30
  • The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol.
    – user207421
    Mar 21, 2017 at 4:15

Yes, what you are getting in the zip file is exactly what every visitor to your site would get every time they start a TLS session - the public keys with certifying information. The private key is the only thing that should be kept hidden from unauthorized access.

  • Righto, I think I need to do some reading. At least my CA reseller isn't doing anything silly though, I am now reassured :-).
    – halfer
    Jul 16, 2015 at 13:30
  • "exactly what every visitor to your site would get every time they start a TLS session" - but only if your server is properly configured. There are way too many web sites out there that don't send all the immediate certificates needed to construct the certificate chain, which is not noted by the operators because their browser has picked them up previously from a properly configured web site. (Certificate errors will be shown to visitors whose browser hasn't picked up the certificates elsewhere yet.) Test tools like SSL Labs will help you find errors like this. Jul 17, 2015 at 10:11
  • @user2428118, I found SSL Labs, and was very impressed. It'd be great to have something similar that emails a periodic re-test every fortnight, and although SSL Labs has an API, they forbid re-offering it to the public. Would have made a good side project!
    – halfer
    Jul 17, 2015 at 22:03

You must log in to answer this question.

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