Generate my own Private Key, Public Key and CSR using cPanel
Process the SSLForFree text files and the tests are ok
Pass only my CSR to SSLForFree, retrieve the SSL Cert.
Install the cert in cPanel.
I have not given SSLFF my Private or Public key.
I have not used SSLFF’s generated keys, only the SSL Cert.
Is this a secure way to use SSLFF?
My domain is: LicenseManager.us
I ran this command:
n/a
It produced this output:
n/a
My web server is (include version):
Apache
The operating system my web server runs on is (include version):
Webhost
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I think so.
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): cPanel w/o link to LetsEncrypt
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): not using Certbot
People have been telling me not to use SSLFF, as there’s a potentially dangerous ‘man-in-the-middle.’ In the past I used the Private Key they generated. I understand why that’s a mistake.
I am not in a position to automate this process yet, so I just want a definitive yes or no, is it save to use the process I described? That is, if all I give them is a CSR, and if all I take from them is the Certificate, is it safe? Have I avoided the man in the middle?
They may not have the private key of the certificate but they may control the (temporary) ACME account they need to create, so they can generate new certificates up to 30 days. Web browser based ACME clients
I have been at that link all day trying to generate a public key.
I don’t quite get it.
I see the command line syntax, but I don’t understand how to make it work.
Where do I run the ‘openssl’ command? Windows doesn’t know anything
about it. The ‘account.key’ portion of the command, is that a disk file
containing the downloaded private key?
The instructions on gethttpsforfree are assuming that you’re running these commands in a terminal on a Unix system. The commands need to be modified for Windows.
For example, where it says $PRIV_KEY, this is a Unix shell notation that substitutes the value of a variable. It doesn’t work in the Windows command interpreter. Instead, you would need to substitute the value of the variable.
Apart from the limitations of the web-based client itself, I think you are probably not part of the intended audience for the service because the author of the site says that it’s meant to be used by people who are already familiar with using OpenSSL on the command line. The gethttpsforfree service is really not a convenient substitute for a paid certificate authority’s web-based interaction.
Oh, I’m sure you can use SSLForFree with OpenSSL on Windows. It’s just that the SSLForFree instructions use notation like $PRIV_KEY — that’s not an OpenSSL issue, it’s a command-line environment issue. OpenSSL never sees the $PRIV_KEY on Unix because the shell substitutes the value before running OpenSSL at all. So what you need in order to adapt these instructions is less OpenSSL documentation and more knowledge of the environment for which the SSLForFree instructions were written.
A CSR can't be used to make new keys, so I don't think this is an issue. Even if SSLForFree could make new certificates that you didn't intend, if it never had the private key that corresponds to those certificates, it couldn't use those certificates in an attack.
...but as @tdelmas notes above, they control the ACME account that was used to validate that domain. Having successfully validated that domain, that ACME account can issue other certs for that domain using self-generated private keys, and it could use those in an attack. But that risk isn't unique to SSLForFree; if I'm understanding it correctly, it exists with any third-party client (and particularly with any of the web-based clients).
I'm sorry I think I disagree, if they don't have the private key of their certificate but have generated a new valid certificate, they can do an active man in the middle. Of course, they still need to be in a "good" position in the network for that, and it will be detected with certificate transparency. So the risk is low (because if anyone claimed that a web browser based did do that they will loose their reputation).
Oh yeah, you're still relying on them to have access to the account key and they can make certificates with a different CSR by reusing the validations. Thanks to you and @danb35 for this point.
@PeterPetropoulos, I wasn't thinking all of the details through when I said that there was no additional risk in this case. I agree that the risk is pretty low.