40

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.

Improve this question
7
  • 11
    Note that you can export exact copies of them for any HTTPS sites using web browsers.
    – user23013
    Commented Jul 16, 2015 at 13:00
  • 2
    Looks like a have a lot to learn about SSL @user23013! - thanks, most useful.
    – halfer
    Commented Jul 16, 2015 at 13:27
  • 6
    It's called the public key for a reason :)
    – BlueRaja - Danny Pflughoeft
    Commented 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/…
    – Ben Lavender
    Commented 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
    Commented Jul 16, 2015 at 16:25

2 Answers 2

Reset to default
53

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.

edit

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.

Improve this answer
6
  • 1
    So, to clarify, sending a private key by email, is a big risk.
    – Brandon
    Commented Jul 16, 2015 at 15:51
  • 19
    Sending the private key in an e-mail is a big risk, never do this!
    – BadSkillz
    Commented 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.
    – Simon Richter
    Commented 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.
    – R.. GitHub STOP HELPING ICE
    Commented 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
    Commented Mar 21, 2017 at 4:15
33

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.

Improve this answer
3
  • 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
    Commented 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.
    – user2428118
    Commented 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
    Commented 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 .