TLS/SSL – Does my public CA have my private key??? – part2

I’ve recently encountered a situation where a smaller company needed a VPN server, using SSTP, so they tried to set up an SSL certificate for their service to encrypt their client VPN tunnels with. It was a Windows server, and the certificate just didn’t appear in the RRAS setup window. Checking the certificate store revealed the simple reason: the certificate did not have a private key assigned!

Turned out they had a different server with the working certificate and they though they just import the CRT file that they received from the public CA (here Let’s Encrypt), and expected it to work just normal.

Remember, the public Certification Authority – like DigiCert, Commodo, Let’s Encrpyt, etc – doesn’t get your private key, you technically send them your public key to be signed.

Let’s just go through the CA creation process quickly:

1. First you generate a certificate signing request (CSR) on your machine. During the process the computer creates both the private, and the public key, then packs the public key in an “envelope” containing the private key itself, and some additional information, like the domain name, key length, extensions, etc. Then encodes it in BASE64 so it is in a normal text format. You can tell it by
2. Then you send it to the public CA, they decode it, verify that you are who you say you are, using different methods: Domain Validated certificate is provided by them when they only verify that you own the domain the certificate is for by asking you to put a DNS record or a specific text file on your website that they can check. Organization Validated or Extended Validated methods are more complex, slower methods, the CA asks for company documentation, etc. to sign the certificate to you. In some browsers these type of certificates make the address bar turn green, providing a more visual proof of trustiness’ for the clients.
3. After validation, the CA sends you back a signed certificate that contains their signature, the extensions and the public key packed in as well.
4. You import the certificate that contain the CA signature, adding the CA provided goodies (signature, Root CA cert). Now you have a trusted private-public pair.

Knowing this it is obvious that importing only the CA signed certificate is not enough: clients can encrypt messages and send it to you but you don’t have the private key to decrypt those.

The only two options in this case are either exporting the private-public key pair from the original server and importing it in the VPN server, or generate a new key pair on the VPN server and get that signed by the CA, essentially having a brand-new cert created.