What is the valid content to accept acme-challenge?

Hi. I am following instructions here:

but nowhere is specified what I should answer when certbot CLI calls my server for validation here:


I answer “ok” cause the docs do not specify anything, but I am getting this error:

Detail: The key authorization file from the server did not match

Maybe I am missing something, or maybe the doc is lacking this information?

Thanks for any help.

As I understand it, you’re using the webroot plugin. What this plugin does is write a file to the path you provide, under the assumption that your web server is configured to serve files under this path as-is, like you’d expect something like apache or nginx to do with its stock configuration.

If that is not the case for you, maybe because you’re running some kind of application server that doesn’t do that by default, there are a couple of options. If you’re running some kind of reverse proxy (nginx, etc.) in front of your application server, you could configure requests that match the path /.well-known/acme-challenge/* to be served from your filesystem instead. Another approach would be to implement the reading of that file in your application code, with the HTTP response being the file contents.

Alternatively, you could use one of the various low-level ACME libraries and essentially implement your own ACME client. This option would be the most involved. ACME is the internet standard that’s used by Let’s Encrypt to automate issuance and validation. The relevant specification would be the acme-01 draft. This is also where the format and content of the response is specified (under 7.1 Key Authorizations).

Thanks for answer. I was able to make it work using DNS validation.
Honestly, I still do not understand how this method work, but is not important, the DNS solution makes so much more sense to me.

Now I have another similar issue.
It seem I have to use --csr command in order to have certbot verify a certificate I self signed.
I’m following this: Using certbot with --csr

This is what I get:

$ certbot certonly --csr unifi_certificate.csr.pem --staging --standalone
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Performing the following challenges:
tls-sni-01 challenge for portal.cotech.co
Waiting for verification...
Cleaning up challenges
An unexpected error occurred:
The request message was malformed :: Error parsing certificate request: asn1: syntax error: sequence truncated
Please see the logfiles in /var/log/letsencrypt for more details.

Again, I face a similar issue: what is my server at portal.cotech.co supposed to answer and where?

This error indicates that the CSR itself is malformed. This could be due to anything from using the wrong format (should be DER or PEM) to a bug in the software used to generate the CSR.

Can you successfully read the CSR using OpenSSL? For example, using this command:

openssl req -in unifi_certificate.csr.pem -noout -text

If you can’t find anything, feel free to post the CSR here - someone in the community might find a non-obvious issue that causes the CA server to trip over it.

As a side note, the challenge mechanism in dns-01 works quite similar to the HTTP challenge. The only difference is that instead of the key authorization itself, the response (i.e. the content of the TXT record) should be the hash of the key authorization.

Certificate Request:
Version: 0 (0x0)
Subject: C=UK, ST=London, L=Teddingdon, O=Pipelean, OU=unifi.cotech.co, CN=unifi.cotech.co
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption

thanks @pfg
I do not understand, I do not have to do any action on unifi.cotech.co? What call is certbot doing against the domain?

With the --standalone option, certbot handles the challenge verification for you. In your particular case, it spawns a web server on port 443 and responds with a special certificate that demonstrates domain ownership. Note that this option will not continue to work if you ever start running your own web server on port 443 - in that scenario, you would have to either stop your web server for renewal (so that certbot can listen on the port), or use one of the other methods (webroot, etc.) that work with existing, running web servers.

Regarding the CSR you posted, is that the output of the OpenSSL command I posted, or is that the actual file? If it’s the latter: That’s not a PEM or DER file. Otherwise, would you mind posting the file itself?

ok, one thing at a time :slight_smile:

  1. I’m running certbot from a virtual machine that is indeed the one running the server that answer to unifi.cotech.co. After your description, I understand is mandatory to run certbot from the machine linked to the domain I am trying to verify, right?
  2. on that machine, the server is a java webapp, that do NOT use port 443 for HTTPS (java convention is 8443) so I do not need to turn it off
  3. I posted the output of the openssl command against the .pem.
  4. this is the output of cat against the .pem


Why do you want to reuse a CSR? Why not let Certbot generate a new private key and CSR?

because that’s the only supported way for unifi controller software: https://help.ubnt.com/hc/en-us/articles/212500127-UniFi-SSL-certificate-error-upon-opening-controller-page
Support also say is the only method. Maybe they’re wrong,…

That's correct, at least in standalone mode.

Correct, if you don't use port 443, you can continue to use standalone.

I was able to verify that Go's x509 library (which is what the CA server uses) chokes on this particular CSR: Go Playground - go.dev

I had a bit of a déjà vu while doing this and eventually found this thread, where someone else was experiencing the same problem with a CSR generated by unifi:

Unfortunately, it doesn't look like a solution was posted. There's either an issue in unifi that produces invalid CSRs, or Go's ASN.1 parser has a bug. I tried to find the problem using various ASN.1 parsers, but couldn't find anything. Perhaps someone with more of an understanding of ASN.1 will find the problem.

@allrik: Did you ever find a solution for this? Thanks!

FWIW, the UniFi CSR bug doesn’t just affect Go; other software rejects it too.

This thread describes how to import a certificate already created without a CSR (such as those generated by certbot) into the UniFi Controller:

You can either use the Java keytool command or the GUI Keystore Explorer program.

[You can also just use PKCS12 files directly as long as you set the password the same, but for some reason most people find the Java keystore gymnastics to be easier, why idk.]


I was in the middle of doing that. I did generate PKCS12 file like this:

openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out pkcs.p12 -name {name} -passout pass:{pass}

Now I have 2 options: 1) import the keystore using keytool or 2) use PKCS12 directly.

For this option #2, @Patches you have some advice? I would love to avoid the Java keystore gymnastic :slight_smile:

Option #1 [BIG EDIT]
I tried to to everything using the same password when generating the PKCS12 fle and when importing. It seem to be the solution also this guy got and works for him

keytool -importkeystore -deststorepass {keystorepass} -destkeypass {keystorepass} -destkeystore /path/to/my/keystore -srckeystore /etc/letsencrypt/live/mydomain.com/pkcs.p12 -srcstoretype PKCS12 -srcstorepass {keystorepass} -alias unifi

Now {keystorepass} and the {pass} in the first command are the same.

That works, no error and unifi restart with no error (before it did remove and regenerate the “broken” keystore.

keytool -list -v -keystore keystore

This is the beginning of the output:

   Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: unifi
Creation date: Oct 16, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 2
Owner: CN=unifi.cotech.co
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US

See it at https://unifi.cotech.co:8080/
It is stuck on TSL handshake…

Now I am really out of options :\

ok, magic, now works. Maybe I should have just wait for insane unifi webapp startup time…

Of course, this does not seem to fix the Security Exception message people see when accessing the https://portal.cotech.co/

This is another story for another thread. Thanks everybody that helped.

You got it working with JKS, but for the record, all you have to do is replace the JKS file with a PKCS#12 file, and change type="JKS" to type="PKCS12" in your server.xml file if it is explicitly defined. (IIRC the server.xml shipped with the UniFi Controller doesn’t require this; I just dropped a PKCS12 file in place of the original JKS store with my LE certificate, chain, and key, encrypted with the password “aircontrolenterprise” and everything Just Worked.)

Looks like you’ve managed to fix this too. :grinning:

Is not fixed when you are redirected there by the Access point, and that page act as the Captive Portal of a protected network.
Now I know why. The issue is not in the certificate of portal.cotech.co (which was working perfectly since the beginning) or the certificate of the machine where the network controller software workds (the one I imported in the keystore). Both are irrelevant. The issue is that the portal is running on heroku and the Captive Portal pre-authorization whitre-list does NOT work with domain (As stated in webapp and doc) but must also have IPs.
The worst is that heroku have dynamic IPs so in the end the solution will be install the portal webapp on Digital Ocean.

In the end, all this tour on SSL and certbot has been “useless” for the sake of the project, but at least now I a little more knowledgable with SSL :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.