11

I am looking into our current website certificate-management process and am looking for steps that may be unnecessary and can be simplified. The current process was created by our sysadmin who now left, and I am confused about step 1 below.

Context: I am hosting a webapp (windows VM with IIS webserver) on a (sub)domain that belongs to a customer (on the customer's domain), so I have no control over their DNS settings or certificate-management.

Because we do want to support HTTPS for this customer we have the following process in order to create a SSL certificate to bind in IIS to our webapp.

  1. In IIS we create a CSR (cert request) using the subdomain name (of the customer's domain) and customer organisation details.
  2. We send the CSR to the customer, they sign it with their CA of choice and send the .cert back to us.
  3. We 'complete' the CSR in IIS and there comes the cert in IIS. We can then export this cert to have it as a .PFX (with private key and password) and bind it to our IIS webapp. (the customer uses a DNS Record to point their subdomain to our IIS webserver)

My question is: What could the reason be that we (the previous sysadmin) would create the CSR etc, instead of just letting the customer create the certificate fully on their side, and when it's created, just send it to use for installation on the webserver.

Why this 2-phase approach that involves lots of waiting and customer-inaction in the process?

What are the drawbacks to letting the customer fully create and manage their certificate, so the only thing we have to do is just import their certificate and bind it in IIS to our webapp.

Improve this question
5
  • it is the third point where something is unclear. why you are exporting it?
    – fraxinus
    Commented Nov 28, 2022 at 6:46
  • the previous sysadmin wanted to have the pfx in a backup storage. So besides the VM, there is an encrypted disk where all the certs (also) are stored.
    – user2713516
    Commented Nov 28, 2022 at 7:08
  • I see. Maybe a solution with a half-responsive client.
    – fraxinus
    Commented Nov 28, 2022 at 7:22
  • Assuming the customer is OK with that, you could also obtain the certificate directly, without going through the customer. For DV certificates, control over the server pointed to by the domain is usually enough to obtain them.
    – marcelm
    Commented Nov 28, 2022 at 10:57
  • How is it more waiting? In one case, you send the csr and wait for them to send you the certificate. In the other case, you tell them you need a cert (and priv key) and wait for them to send it to you. It seems like the same amount of waiting.
    – jjanes
    Commented Nov 29, 2022 at 4:03

3 Answers 3

Reset to default
34

My question is: What could the reason be that we (the previous sysadmin) would create the CSR etc, instead of just letting the customer create the certificate fully on their side, and when it's created, just send it to use for installation on the webserver.

If the customer created everything on their side, they would also need to create the private key and send it to you - which means that they have a copy of your private key and also increases the likelihood that they key is stolen or compromised.

The point of a CSR is that you can send them the details of the certificate you want (e.g, the name/URL that it's for), and your public key - but your private key never gets sent anywhere.

Improve this answer
2
  • thank you for the elaboration. I didn't realise the CSR also meant the creation of the private key on my webserver.
    – user2713516
    Commented Nov 27, 2022 at 11:26
  • 12
    @user2713516, more precisely, having the private key is required to create the CSR.
    – Paul Draper
    Commented Nov 28, 2022 at 2:25
15

What could the reason be that we would create the CSR?

In the first phase you do not create just a CSR, but a key pair. The CSR is derived from the public key of that pair, to be signed with the private key of a CA. It is not possible to use a certificate without this private key, and the private key might leak if transmitted with the certificate.

The customer uses a DNS Record to point their subdomain to our IIS webserver.

Why this 2-phase approach that involves lots of waiting?

Considering this is a subdomain of a public domain, there is an option without the waiting. You could use Let's Encrypt and automate the entire certificate creation and renewal process. This requires the customer has already added the DNS record. After that, you could utilize some of the ACME Client Implementations for Windows / IIS.

Improve this answer
0
6

Although the main point (reduced attack surface) has been covered already, I'd like to mention a couple of other aspects:

  • Digital Forensics and Incident Response (DFIR): in case an incident takes place and the private key is compromised, how easy is it to prove that it was the client's copy of the key that was stolen and not your company's one? Clients usually don't have adequate monitoring in place, which may prove to be a big problem in investigating an intrusion
  • Brand protection: in any case, since you are not sure whether every client is competent security-wise, it is much better to handle critical data yourself (i.e. handle the key/certificate lifecycle), even if this introduces more work load, than having to defend your company's reputation because a sloppy client lead to an abused site that affected thousands of users
  • Contractual agreement: although not obvious, it may be what the service agreement with the clients require (aside from the CSR signing part)
Improve this answer

You must log in to answer this question.

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