Possible to use letsencrypt to generate certificates from a Salesforce CA Request?

Question

Update 2016-03-04

letsencrypt still cannot sign CSRs without a Subject Alt Name (SAN). But it may be on their road map:

• Update --csr to check common name #1076
• Client should be able to accept CSR's in either PEM or DER format. #1082 .

Vote for the Salesforce Idea to Include Subject Alt Name (SAN) to CA-Signed Certificate Requests.

Original

https://letsencrypt.org/ is a Certificate Authority (CA) that provides free SSL Certs.

I have a Domain in Salesforce that I'd like to get an SSL Certificate for, and I created a CA Signed Certificate in Salesforce's Certificate and Key Management, and I downloaded the Certificate Signing Request (csr).

I installed letsencrypt on a Linux box (with Advice for using letsencrypt for Windows Users), and tried to generate a SSL Certificate with the following command using the csr, but I am getting an error.

~/letsencrypt $ ./letsencrypt-auto --csr subdomain_mydomain_com.csr

It has been noted that to use letsencrypt with a csr, the csr has to:

1. Be in der format
2. Contain a subjectAltName (SAN)

But I can't figure out how to add a SAN in Salesforce before creating a CA Signed Certificate nor converting the csr to der format. (I can't change a csr once it's been signed.)

Has anyone figured out how to use letsencrypt with Salesforce?

---

Update

@AlexTennant provided a snippet where OpenSSL converts a PEM CSR to DER format:

openssl req -inform pem -outform der -in foo.csr -out foo.der

I converted my CSR to DER format with the above snippet, but I ran into another issue when trying to generate a Certificate from letsencrypt:

AssertionError: Authorizations list is empty

https://github.com/letsencrypt/letsencrypt/issues/1052 suggests that this Exception is thrown when no SAN is given in the CSR.

https://github.com/letsencrypt/boulder/issues/40 suggests that since subjectAltName (SAN) is the new standard over commonName (CN), if a CN is given, it must also be in the SAN.

http://serverfault.com/questions/253960/adding-subject-alternate-names-san-to-an-existing-cert-signing-request-csr says that a CSR cannot be altered after it's been signed. If we could get the Private Key from Salesforce, we could generate another CSR with OpenSSL -- but this seems silly and unlikely that Salesforce would hand over the Private Key.

To me, the only option is to ask Salesforce to include the CN in the SAN when it generates a CA Signed CSR. Is this correct? Or are there other alternatives? And if so, do you have any recommendation on how to proceed asking Salesforce for this?

Many thanks!

Answer 1

To turn a PEM to a DER, you can use OpenSSL:

openssl x509 -in cert.crt -outform der -out cert.der

as per: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

It's my understanding that subjectAltName is optional for Let's Encrypt, but I can't seem to find anything in support of or against that.

Answer 2

You can convert the CSR to a DER using OpenSSL.

openssl req -inform pem -outform der -in foo.csr -out foo.der

Unfortunately this still doesn't solve the issue of the SAN not being populated, as far as I can tell this isn't supported by Salesforce but I'm still looking into it.

It does however look like this may not be an issue at some point in the future as letsencrypt is planning on updating the --csr option to check the CN rather than requiring a SAN in a future release.

Another option is to forego the official client entirely and use something like acme-tiny. It looks like from their examples the SAN is not required when using it, unlike the standard letsencrypt client (Disclaimer: I've not had a chance to actually try it myself).

The ACME protocol (what Let's Encrypt uses) requires a CSR file to be submitted to it, even for renewals. You can use the same CSR for multiple renewals. NOTE: you can't use your account private key as your domain private key!

#for a single domain
openssl req -new -sha256 -key domain.key -subj "/CN=yoursite.com" > domain.csr

The OpenSSL command they use to generate the signing request for a single domain does not include a SAN, just the CN (just like an SFDC generated CSR).