39

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.

halfer
  • 821
  • 1
  • 7
  • 12
  • 11
    Note that you can export exact copies of them for any HTTPS sites using web browsers. – user23013 Jul 16 '15 at 13:00
  • 2
    Looks like a have a lot to learn about SSL @user23013! - thanks, most useful. – halfer Jul 16 '15 at 13:27
  • 6
    It's called the **public** key for a reason :) – BlueRaja - Danny Pflughoeft Jul 16 '15 at 16:13
  • @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 '15 at 16:25
  • 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. https://support.office.com/en-au/article/Blocked-attachments-in-Outlook-3811cddc-17c3-4279-a30c-060ba0207372 – Ben Lavender Jul 16 '15 at 16:18
  • @halfer A certificate is signed by the CA and contains your public key and some meta data, like your domain name. – CodesInChaos Jul 17 '15 at 06:25
  • Lordy! I'm pleased people like my question, but if we got +18 for beginners' questions on Stack Overflow, it'd make the databases melt. `:-)` – halfer Jul 17 '15 at 15:33

2 Answers2

51

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.

BadSkillz
  • 4,444
  • 25
  • 29
  • 1
    So, to clarify, sending a private key by email, is a big risk. – Brandon Jul 16 '15 at 15:51
  • 19
    Sending the private key in an e-mail is a big risk, never do this! – BadSkillz Jul 16 '15 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 Jul 17 '15 at 06: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 Jul 17 '15 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 '17 at 04:15
  • @EJP The traditional RSA cipersuites do have the client generate a secret, encrypt it and send it to the server. So if you have the server's private key you can decrypt the secret and regenerate the session keys. DHE and ECDHE cipersuites avoid this problem. – Peter Green Apr 13 '17 at 15:40
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.

mricon
  • 6,298
  • 23
  • 27
  • 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 '15 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](https://ssllabs.com/ssltest) will help you find errors like this. – user2428118 Jul 17 '15 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 '15 at 22:03