77

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.

scipilot
  • 873
  • 1
  • 6
  • 8
  • 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. – trognanders Apr 12 '17 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 Apr 12 '17 at 22:51
  • Is the private key encrypted? – David Schwartz Apr 13 '17 at 01:20
  • @DavidSchwartz No, it didn't appear so. – scipilot Apr 13 '17 at 09:07
  • 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: https://www.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 Apr 14 '17 at 00:04
  • That's very useful Beau - I used these commands to prove that the new CRS they provided was generated with a different private key - which is good news, as I don't have to reject it too. – scipilot Apr 14 '17 at 01:01
  • Don't apologise, I think it's my fault for writing an opinion questions - this question is turning into a valuable wiki article :) – scipilot Apr 14 '17 at 01:02
  • BTW it's quite (un)funny the sslshopper.com page has an "upload private key" field! And a big warning not to use it. – scipilot Apr 14 '17 at 01:03
  • 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](https://certbot.eff.org/) a problem? That's what I use for my server. – code_dredd Apr 15 '17 at 12:19
  • @BaileyS Google the company might not be interested, but Dave the Google employee with access to the email server might be. There have been cases of Google employees abusing their access to people's gmail accounts before – Pharap Apr 16 '17 at 01:33
  • 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 Apr 16 '17 at 03:02
  • 1
    @hlecuanda Well. [this guy](http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats) certainly was. I'm glad to hear that my gmail-based communications with my pentagon-hacking friends are safe though. I'll be sure to tell Betty to be careful though, someone might have realised which head of state she arranged the hotel room liason with. – Pharap Apr 16 '17 at 05:00

6 Answers6

119

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.

dr_
  • 5,060
  • 4
  • 19
  • 30
  • 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 Apr 12 '17 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_ Apr 12 '17 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 Apr 12 '17 at 20:42
  • @DRF I meant *voluntarily* disclosed the private key to third parties. – dr_ Apr 13 '17 at 06:42
  • I wonder if the private key is used for the entire shared server in which case you'd be able to impersonate not only your domain but anyone else using the same server. – André Borie Apr 13 '17 at 10:47
  • 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 Apr 13 '17 at 18:27
  • 1
    +1 for telling OP to switch provider, who has demonstrated its level of ignorance in their own field. – code_dredd Apr 15 '17 at 12:24
  • @AaronHall It's voluntary only if you know how email works, otherwise it's blissful ignorance. I think we have settled that the hosting provider is run by incompetents. – dr_ Apr 16 '17 at 21:03
50

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.

vakus
  • 3,743
  • 3
  • 20
  • 32
  • 3
    Yes good point about educating them. – scipilot Apr 12 '17 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 Apr 15 '17 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 Apr 15 '17 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 Apr 15 '17 at 13:49
18

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.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • `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 Apr 12 '17 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 Apr 12 '17 at 20:11
  • HTTPS won't help anything unless it has client authentication at which point though you might as well just sign the CSR with the client certificate and have less work. The only secure way to deliver a CSR is using out of band authentication. Depending on how secure you want this to be it could be as easy as a phone call and reading the fingerprint or as annoying as having to show up in person. – DRF Apr 12 '17 at 20:53
  • 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 Apr 12 '17 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. – Hagen von Eitzen Apr 12 '17 at 21:24
  • Yes I do realise normal email itself is also unacceptably insecure, it just feels like these days email is less treasured by individuals and acceptance of third-party access is more normal. It used to be only really postmaster/sysadmins who had access to the mail contents while they're were queuing, in simple traditional email. Now it's far more complex with many more attack surfaces and a lower-level of personnel with potential access (I feel). By Gmail I also meant webmail, so e.g. Ad Block Pro and all other browser plugins are probably "reading" my emails. – scipilot Apr 12 '17 at 22:33
  • It's a very good, and original, point that I did not specify to them how to deliver it. You are probably right, I set the bar implicitly low. But I only asked them for the CSR,which I believe to be shareable, so this hadn't raised my normal awareness level, e.g. in the past I've asked for hosts save credentials to a file in the hosted environment which I can access (via SCP). – scipilot Apr 12 '17 at 22:37
  • I should have mentioned the cc'd person is the "Account Holder" and I'm the "Technical Contact" so they seem to always cc them. I have not trained that person, as I wasn't expecting an issue. – scipilot Apr 12 '17 at 22:38
  • 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](https://developers.google.com/speed/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 Apr 13 '17 at 00:34
  • "Setting up an authenticated channel can be quite an involved process" - Do you count keybase.io as an authenticated channel? – John Dvorak Apr 13 '17 at 09:40
16

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.

Peter Green
  • 4,918
  • 1
  • 21
  • 26
  • 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 Apr 12 '17 at 22:41
13

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.

trognanders
  • 2,925
  • 1
  • 11
  • 12
6

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.

user207421
  • 245
  • 1
  • 7
  • 1
    I'm pretty sure it doesn't _legally_ identify its owner, just technologically. – Nic Apr 13 '17 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 Apr 13 '17 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 Apr 14 '17 at 00: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 Apr 14 '17 at 00:53
  • @EJP Huh, I had no idea. That's pretty cool! Out of curiosity, can you cite a specific law/ruling that made it so? Is it global, or widespread, or US-specific? – Nic Apr 14 '17 at 00:56
  • @QPaysTaxes It is the *purpose* of digital signatures to be lawful. It is well established law in USA, Australia, UK, ... I am not a lawyer and cannot provide the references you seek. – user207421 Apr 14 '17 at 11:04
  • 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 Apr 14 '17 at 12:28