4

In the process of getting a SSL certificate, I generated a CSR and the private key and for some reason had to share them.

What could a malicious person do with those two files ?

thesearentthedroids
  • 143
  • 3

1 Answers1

6

If you do it properly, nothing.

The usual process for getting a TLS (formerly SSL) certificate from a CA is:

  1. Generate server.privkey and server.csr (or equivalent) files on your machine. Keep the private key private.

  2. Send the server.csr (certificate signing request) to the CA to get signed and become a certificate.

  3. Take the certificate the CA gives you back and import it into your web server along with the server.privkey.

The CSR file is not sensitive and can not be maliciously modified without cracking the crypto (hard). You do not need to be overly careful about sharing this file.

The Private key, on the other hand, should be private. It should stay on your server. You should not share it with anyone. Again, this is private. All sorts of bad things can happen if bad guys get this. If you have already shared it with someone, I suggest you start the process over by generating a new keypair, a new CSR, and getting a new cert. This time, don't share the private key with anybody!

What's in a private key?

Your private key is the cryptographic identity of your server. When a browser connects to your site, your server sends down the certificate (containing your public key), and performs a proof that the it has the corresponding private key. Browsers accept this proof that it is talking to the real cutefluffyanimals.com, and not a spoofed version. The browser shows the green padlock and everything is good.

If a bad guy has a copy of your private key, then they also have the cryptographic identity of your server and can pretend to be you: intercept traffic going to your server, view information the user entered (including usernames/passwords), modify page content, pretend to be the server and respond directly to the browser, inject their own content or code or ads into your pages, etc. They can literally do anything because, cryptographically speaking, they are the real server. The browser will still show the green lock because the server it's talking to has the right private key.

Anybody who requires you to share your private key clearly doesn't understand how certificates work. Kick them in the face.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 1
    But what could someone do with that private key ? – thesearentthedroids Sep 27 '17 at 21:32
  • Everything. I'll update my answer. – Mike Ounsworth Sep 27 '17 at 21:32
  • Just to be sure, the certificate contains a domain name, so there is no way the browser be fooled if the DNS are not compromised ? – thesearentthedroids Sep 27 '17 at 21:56
  • @thesearentthedroids the CSR you send to the CA is cryptographically signed by your private key. Nobody can modify the domain name inside without the CA knowing that it has been tampered with. The certificate is cryptographically signed by the CA's private key. Nobody can modify the domain name inside without the browser knowing that it has been tampered with. – Mike Ounsworth Sep 27 '17 at 22:02
  • @thesearentthedroids: to be exact, an SSL/TLS server cert specifies the domainname or names plural (example: stackexchange's cert also includes stackoverflow, superuser, askubuntu, etc) and the browser won't be fooled even if DNS and/or IP routing _is_ compromised, which is a major feature. X.509 certs for other applications also specify identity, but that identity is not always in the form of domainname. – dave_thompson_085 Sep 28 '17 at 00:52
  • I think step 2 (communications between CA and server needs to be more secure for this to work. here is where it can go wrong. Attacker intercepts CSR before its sent to CA, looks at the domain xyz.com, generates their own private/ public key, creates a new CSR. with xyz.com domain, along side attacker public key, SIGNED by attacker private key.. sends it over to CA, completely valid CSR, CA replies back with valid cert of xyz.com that attacker completely controls sweet MITM coming // let’s encrypt for example verifies domain ownership before issuing cert – hnasr Mar 28 '21 at 01:19
  • @hnasr Step 2 is almost always done over TLS; for example pasting your CSR into a text box in a HTTPS website, or devices over the Enrollment over Secure Transport (EST) protocol. I agree with you that the CSR contains proof-of-posession of the private key to be certified, but it does not contain any authentication within the CSR file that it is coming from the real end user and not an attacker. You need to build authentication into the workflow for submitting the CSR -- like logging in to a website. – Mike Ounsworth Mar 29 '21 at 14:57