I just requested a CSR from my shared web hosting provider, to generate a certificate which I will send back to them to install. (The certificate itself is to be generated properly by an organisation I work for who can provide certificates for our official use.) The hosting company promptly sent me the CSR but also the private key! They even CC'd someone else, and it's in Gmail so Google has presumably already ingested it for advertising purposes.

In my humble opinion this seems like a terrible thing to do. I am about to write back to them rejecting this one, and asking to renew the CSR and this time keep the private key - private.

Before I make a fool of myself, I'd like to confirm that the private key for an "SSL" (TLS) certificate should never leave the server?

I've been working in security-related industries for many years, and used to be a crypto programmer, so I feel I know the topic a little - but I know things change over time.

I have read this related question: What issues arise from sharing a SSL certificate's private key?

Meta Update: I've realised I've written a poor-quality question format for Stack Exchange - as it's now difficult to accept a specific answer. Apologies for that - all answers covered different and equally interesting aspects. I did initially wonder how to word it for that purpose but drew a blank.

Update: I have followed this though with the host and they did "apologise for any inconvenience", promised to keep future private keys "safe" and issued me a new, different CSR. Whether it's generated from the same exposed private key I am currently unsure of. I now also wonder, as it's a shared host, if they've sent me the key for the entire server or if each customer/domain/virtual host gets a key pair.

It's an interesting lesson how all the crypto strength in the world can be rendered null and void by a simple human error. Kevin Mitnik would be nodding.

Update 2: In response to an answer from user @Beau, I have used the following commands to verify the second CSR was generated from a different secret private key.

openssl rsa -noout -modulus -in pk1.txt | openssl md5
openssl req -noout -modulus -in csr1.txt | openssl md5
openssl req -noout -modulus -in csr2.txt | openssl md5

The first two hashes are identical, the third is different. So thats good news.

  • 10
    "and it's in Gmail so Google has presumably already ingested it for advertising purposes." You realize that Google runs their own CA, and could insert basically any CA cert they like into Chrome? In this scenario, Google is probably one of the least interested/interesting parties. Commented Apr 12, 2017 at 22:27
  • 13
    Yes I'm not worried about Google per-se (I've entrusted my life to them!) but just highlighting the extra journeys our personal content travels on nowadays, even after apparent arrival at its destination.
    – scipilot
    Commented Apr 12, 2017 at 22:51
  • 7
    My apologies for not posting this as a comment - I don't have enough rep. But you can compare your new CSR against the original private key with a few openssl commands: sslshopper.com/certificate-key-matcher.html. If the modulus for each is different, then you should be ok. I'm not sure I would trust the vendor's security practices, though. Security is entirely about trust, after all.
    – Beau
    Commented Apr 14, 2017 at 0:04
  • 1
    At this point, switching to a company that actually understands the nature of a private key might make more sense, IMHO. A cert issuer that happily sends private keys via email to several recipients does not appear to know what it's doing and has shown itself to not be as competent. Is using certbot a problem? That's what I use for my server.
    – code_dredd
    Commented Apr 15, 2017 at 12:19
  • 1
    @Pharap the value of an individual's private information is highly overrated. Really, nobody cares about the secrets you may hold so dear, Facebook crushes, chat logs and probable nudies stored on your WhatsApp backup. It's hard to admit we're just not that interesting, and most of us are just plain ordinary boring. The real value comes with huge amounts of aggregated data, where your individuality dissolves into nothingness compared to the dataset. Unless, of course you're Putin's hot teen girlfriend or a F500 CEO, our indivisual private data is just not worth any effort.
    – hlecuanda
    Commented Apr 16, 2017 at 3:02

6 Answers 6


If I were in your place I would refuse to accept this SSL certificate. The reason for that is, if someone broke into either of the emails that received the private key, they would be able to download it, and then impersonate the server in different attacks on clients, like man in the middle or similar. Also in the case that one of the receiving email addresses was written incorrectly, someone may already have the private key. There are also probably many more scenarios where this private key could be downloaded and used by an attacker.

Also notifying the company about not sharing the private key should be important, to make sure that the company won't sent the private key anywhere else - the private key was sent to you, and some other CC's in this email, but you can not know whether the company didn't sent a separate email with the private key somewhere else.

There is a reason why the private key is called a private key

Please note that this is mostly my personal opinion, and that I am not an expert with SSL.

  • 3
    Yes good point about educating them.
    – scipilot
    Commented Apr 12, 2017 at 12:54
  • 2
    Wouldn't at this point switching to a company that actually understands the nature of a private key make more sense? A cert issuer that happily sends private keys via email to several recipients does not appear to know what it's doing and has shown itself to not be as competent, IMHO.
    – code_dredd
    Commented Apr 15, 2017 at 12:18
  • @ray well if you switch the company, then you are more secure, but if instead you will educate them, all of their customers will be secure. If educating them wont help, then yes it would be sensible to switch company, but at this point it would seems obvious
    – vakus
    Commented Apr 15, 2017 at 13:38
  • 2
    @vakus If you want to invest in educating someone who should already know better, that's up to you. Just remember that the poor security practice visible to you, being outside the company, hints at deeper issues you may never discover (e.g. how do you know they didn't Bcc that key to other addresses, or worse?) and, therefore, unable to educate them on. You need to decide how much risk you intend to place your customers in for the sake of "educating" them. Educating them does not mean you must stay as their customer. Leaving might give them more incentive to actually fix themselves
    – code_dredd
    Commented Apr 15, 2017 at 13:49

Yes, you should absolutely reject the CSR. Additionally, you should change your hosting provider as it looks like they don't know what they are doing.

It is already bad enough that they sent you the private key via e-mail i.e. via an insecure medium. However, they also Cc'ed it to someone else, which is a complete breach of confidentiality.

Furthermore, I wonder why they sent you the private key -- it's supposed to be installed on the server, which is something they can do by themselves.

  • They cc'd the other contact on the account (non tech). And yes I wondered why too, that was really my question. There is still no reason - just making sure I didn't miss a memo here.
    – scipilot
    Commented Apr 12, 2017 at 12:55
  • 5
    Ok, so it isn't like they sent the private key to someone unknown to you. Still, the main point holds.
    – dr_
    Commented Apr 12, 2017 at 12:57
  • 21
    @dr01 Sure they did. All the mail server admins, router admins and firewall admins that were along the way of the mail and wanted to read it.
    – DRF
    Commented Apr 12, 2017 at 20:42
  • 12
    @dr01 I think if you send information in email, unless it's encrypted, you're voluntarily disclosing it to every computer it bounces off of until it reaches its destination.
    – Aaron Hall
    Commented Apr 13, 2017 at 18:27
  • 1
    +1 for telling OP to switch provider, who has demonstrated its level of ignorance in their own field.
    – code_dredd
    Commented Apr 15, 2017 at 12:24

Yes, you definitely should reject the CSR.

As to whether you should reconsider the hosting provider, it depends.

They even CC'd someone else,

Is there any reasons why the hosting company should know your internal company structure? Is the person doing this a designated account manager that has been specifically assigned to your company and are responsible for knowing who's who in your company? Did your company provide sufficient briefing to the account manager of how your company is structured and who's authorized to do what? If not, then it may be partly your (company's) fault for not making it clear to them how they should send the key to you.

In most hosting accounts, if you don't have a designated account manager who is familiar with your line of business, you should have made it very explicit to their technical support how to send the keys to you, who should receive it, and whether or not you want to receive the key in the first place. Don't assume that a technical support personnel knows your company's situation, and never assume that a technical support personnel who isn't your designated account manager to remember who you are from a previous interaction.

and it's in Gmail

You do realize that sending a CSR through email is also not very secure right? It's quite possible for someone (an insider working in Gmail or an APT), to intercept the email containing the CSR, replace the CSR the host sends you with their own CSR, and sign the hosting company's CSR to the hosting company themselves. This would allow them to later use the forged certificates to MITM between you and your users and the hosting company.

A CSR must be delivered over authenticated channel (e.g. they submit the certificate to a HTTPS site you control or they should sign the CSR with a GPG key they publish on their site), or at the very least you should do a fingerprint verification and both you and your host need to have a way to identify and authenticate the other party. Setting up an authenticated channel can be quite an involved process, and isn't something that's going to be available in lower cost hosting provider or those that doesn't specialize in high security business hosting.

If you don't specify how your company requires the CSR to be delivered, and especially if you are not handled by an account manager who should know what kind of business you are doing, then most hosting company would reasonably assume that you are a minimum security company. Most people working in minimum security company would consider having a copy of the private key to be higher value than the security of not controlling the key, it's not unreasonable for them to assume so from you.

  • It's quite possible for someone ... to intercept the email containing the CSR - Do you have a link or something with more details about this? I am trying to follow how this would work.
    – Zoredache
    Commented Apr 12, 2017 at 18:42
  • 4
    @Zoredache It's super easy. You work at Google. You run a script to look for undelivered email in the Gmail database that was sent to users in the last 5 minutes and contains what appears to be private key payloads. You temporarily move this email to a staging area so it isn't delivered, then craft the alternate payload. Then you place the modified email with your malicious payload back into the database where the user will see it as just another, expected, good email.
    – ErikE
    Commented Apr 12, 2017 at 20:11
  • 1
    @ErikE Sure if the private key is sent there is a problem, but LieRyan's answer says a CSR alone in an email can be abused. I am not following how you could use MITM given only a CSR. Unless you are thinking the attacker can intercept the CSR and is also setup to MITM all access to the server that the cert is actually being issued for.
    – Zoredache
    Commented Apr 12, 2017 at 20:55
  • 3
    @Zoredache Transfering a CSR (without private key, of course) in itself poses no security risk. The requestor has generated a private-public key pair that he wants to bind to a to-be-protected entity (e.g., use with a https site for www.example.com) and kindly asks a trusted signer to sign and thus confirm that this connection between public key and bound entity exists. What does need to take place in a secure out-of-band way is rather the verification process that the CSR was issued by someone in trustworthy control of the to-be-protected entity. Commented Apr 12, 2017 at 21:24
  • 1
    @Zoredache: yes, I was referring to someone who also can setup a MITM, such as an admin of any system in the web host's datacenter/upstream network path, or someone who runs a widely used Public DNS. Someone who can intercept your mails could at least modify your email so it contains two CSRs, the real one and a forged one, and tell you a plausible a cover story like having redundant load balancer where they install separate certificate and that the HSM does not support private key export.
    – Lie Ryan
    Commented Apr 13, 2017 at 0:34

Before I make a fool of myself, I'd like to confirm that the private key for an "SSL" (TLS) certificate should never leave the server?

It depends, there can be good reasons for it to leave the server. For example you may want to use the same cert on serveral servers or you may want a backup key for key pinning.

But it absoloutely should be treated as a valuable secret, only stored on machines you trust and if it does need to move between systems it should be done so in an appropriately secured manner.

My advice would be to move away from these clowns immediately.

  • 1
    Good point, I've even done this myself in the past. I felt appropriately nervous doing so and used SSH to transfer it directly to the second host.
    – scipilot
    Commented Apr 12, 2017 at 22:41

They probably wanted for you to have the entire key/certificate pair in case you wanted to use it elsewhere.

Having the private key floating around is a legitimate security worry, particularly if you are not going to use it. Explain that this certificate is only for the hosting provider, and ask them to re-issue the CSR and send it without a private key. Verify that the CSR thumbprint changes.

It kind of sounds like they treat the certificate as a way to make a green lock appear more than as a security device, which is probably a warning sign. Consider different hosting if it is possible and/or if your site handles very sensitive information.


They are utterly incompetent at security. A private key is, err, private, by definition. It serves to legally identify its owner. They have made forgery and impersonation possible.

You should be sending them the CSR, after generating it yourself from your private/public key-pair, and they should send you the signed certificate and its authentication chain. Nothing else.

If they are sending you private keys and CSRs, their entire model is broken.

Change providers, and get your money back. At least. They have compromised your security, so an action for loss and damages may lie. At least you can threaten them with it to ease the money-back process.

  • 1
    I'm pretty sure it doesn't legally identify its owner, just technologically.
    – anon
    Commented Apr 13, 2017 at 18:47
  • 8
    I think you've misunderstood the role of the provider here (unless I have): they're not issuing the certificate, they're installing it onto a server to which the OP has only restricted access. The OP cannot generate the key-pair, because they do not have access to install the private key into the web server configuration. If they did so, they would need to transmit the private key to the host. The host generating the key pair and sending the CSR seems to be absolutely the right process, but they missed the point by sharing the private key.
    – IMSoP
    Commented Apr 13, 2017 at 19:54
  • @QPaysTaxes A digital signature with a private key is legally enforceable as entirely equivalent to a personal signature on a contract or cheque.
    – user207421
    Commented Apr 14, 2017 at 0:52
  • @IMSoP If more than one person has the private key it isn't private. If the role of the provider is so construed it is radically insecure. Sending it around at all violates PKI entirely.
    – user207421
    Commented Apr 14, 2017 at 0:53
  • 1
    @EJP Yes, I got that. But you missed the point in the original question that the one person who should hold this particular private key is the web host. We all agree that they did wrong by sharing it, but your suggestion that the OP should generate their own key pair makes no sense, because the private key has to end up in the server configuration, which only the hosting company has access to.
    – IMSoP
    Commented Apr 14, 2017 at 12:28

You must log in to answer this question.

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