I ran this command: ./certbot-auto certonly --csr /var/lib/unifi/unifi_certificate.csr.pem
It produced this output: An unexpected error occurred:
The request message was malformed :: Error parsing certificate request. Extensions in the CSR marked critical can cause this error: https://github.com/letsencrypt/boulder/issues/565
My operating system is (include version): Debian 7
My web server is (include version): ?
My hosting provider, if applicable, is: ?
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
Could you provide the CSR (/var/lib/unifi/unifi_certificate.csr.pem)? As the message suggests, this is likely due to an issue with the CSR, so it would be hard to say more without the actual CSR in question and/or more details on how it was generated.
(CSRs do not contain private keys or any other information that Let’s Encrypt does not make public anyway.)
Unfortunately, the error I’m getting when I try to parse that CSR is not particularly useful (“asn1: syntax error: sequence truncated”, use this to reproduce).
My best guess would be that it’s due to the “C=Deutschland” field in your subject; the country field should be a two-letter string (DE for Germany). In fact, trying to generate a CSR with that subject fails with my version of openssl (with “140735108980816:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:a_mbstr.c:158:maxsize=2”), though it will happily parse the CSR. I suspect the code used by Let’s Encrypt might be stricter here and that’s the issue.
If the software you’re using to generate the CSR allows you to get rid of all subject fields other than Common Name (CN), I’d recommend you do that, as Let’s Encrypt would remove those from the signed certificate anyway. If that’s not possible, “DE” should be an acceptable value.
It seems like even OpenSSL can't handle that CSR properly (I didn't think that was actually possible ) . Trying to parse it (with openssl asn1parse -inform pem -in your.csr) results in this output:
My search for this particular message turned up this old post from the OpenSSL mailing list. It appears that the CSR is corrupted in some way. The post contains some ideas on what could be causing this:
This is exactly the symptom of a file being treated as text
when it isn't, in particular by transfer protocols like (S)FTP
and maybe HTTP, or other tools like ZIP. A Unix-style "newline"
(0A) gets converted to a DOS/Win/Inet style CR LF (0D 0A).
Similarly C internally uses one byte '\n' newline, but ON
DOS/Win textfiles use CRLF, so fopen/fwrite/etc. in text mode
converts 0A to 0D0A on output, and 0D0A to 0A on input.
If you are running your C program on DOS/Win, you need
to open the file in binary mode i.e. fopen (foo, "wb").
(But if you're running on cygwin on Win, it's more
complicated; cygwin tries to bridge the gap between Unix-format
and Win-format, AFAIK mostly by 'mount' options.)
Even on other platforms it is good to specify this for
clarity/documentation/robustness even if not strictly needed.
As a check it should be 916=0x394 bytes.
Alternatively, if you want a text file, which is usually
more portable and human recognizable: get the cert data,
base64 it and add the -----BEGIN/END lines to make it
PEM format, and write (and read) that as text.
If you could share more details about how this CSR is generated, transmitted, etc., we might be able to figure this out.
While all certificates issued by Let's Encrypt (or any public CA) must have all domains appearing on the certificate in a SAN field, it's not strictly necessary for the CSR to contain the SAN extension, and the CA server will use the CN field as a kind of fallback. (Of course that'll only work with certificates for a single FQDN.)
You'd think so, with the certbot docs saying as much (and mentioning that you need a SAN field as well ), but apparently it'll happily convert from PEM to DER before submitting the certificates. Will look into filing a doc issue for this.
(In case anyone's curious, this is the CSR I just used successfully to get a certificate from staging via certbot and --csr.)
@pfg, thanks for sharing the info, I thought that was a MUST (SAN and DER) and not a... well it is a must but our client and boulder are smart enough to fix it for you ;).
Instead of buying a ssl certificate, I decided to use Let’s Encrypt. But apparently, the .pem (and .der) files created by the ace.jar program cannot be parsed properly.
I can post the .der too, if it would be of any help.
Have you tried using the DER file rather than the PEM? With any luck, the corruption is specific to the PEM and things will work fine when using the other file.
Another option would be to figure out where exactly this tool stores the private key, export that and use it to generate a new, non-corrupted CSR (using something like openssl req -new -sha256 -key privkey.pem -out wh-gbs.uni-ulm.de.csr -subj "/CN=wh-gbs.uni-ulm.de") which you’ll be able to submit with certbot. No idea where to start looking, though.
I consulted the support, explained them the error and asked them for the location of the private key file. But it seems, that it will take some time to respond to my question.
I’ll give further informations about this as soon as I receive a message.