Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I am self-hosting my own CA and have pointed certbot to it and the CA's root certificate.
My domain is:
I ran this command:
sudo REQUESTS_CA_BUNDLE=/usr/local/share/ca-certificates/extra/root_ca.crt certbot certonly --server https://tinyca.local/acme/acme/directory --email <email> --webroot -w /usr/share/jellyfin/web -d jellyfin.local
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for jellyfin.local
All authorizations were not finalized by the CA.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
log file is here
My web server is (include version):
The operating system my web server runs on is (include version):
Raspbian GNU/Linux 10 (buster)
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'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
I'm assuming you're using the tinyca application sourced here: GitHub - jclegras/tinyca: Very simple CA with APIDoes not seem to be an ACME CA..
It seems that application does not behave well conforming RFC 8555: even though the
http-01 challenge contains an error, it does not change its state from "pending". It should have changed to "processing" when the challenge was triggered and even with the error present, it did not change to "invalid".
Ultimately the error message in the log file is clear ("The server could not connect to validation target"), but I would not recommend to keep using tinyca. It does not seem to be a very good application and hasn't been updated since 3 years now.
You're running smallstep/certificates and your CA server is not able to connect to your domain
Smallstep is not really great at producing useful error messages, so we can't read the exact cause from that certbot ACME log. You could consider having a look at your smallstep server log, but based on my experience that won't be much helpful either.
.local is a reserved multicast DNS domain, and multicast DNS is often a very troublesome topic. It wouldn't surprise me if smallstep can't resolve the multicast DNS.
Note that your jellyfin server has to be listening on port 80 for this challenge to succeed, and jellyfin usually defaults to 8096, unless you've changed it.
You may have more success issuing a smallstep certificate not using ACME. You could use the CLI directly (this is even possible if your ACME server is remote) to issue a certificate without having to complete an ACME challenge (using the JWK provisioner).
For more information about smallstep we will likely refer you to their documentation.
@Nummer378 You sure it's smallstep? I would assume such a rather large application would behave better regarding challenge status in case of an error. Check the log. It keeps the state of the challenge in "pending" even when triggered and producing an error?
I'm running smallstep myself, and yes I'm fairly certain this is smallstep.
Smallstep's ACME implementation is fairly... limited. It violates the spec in dozens of places and yes it does like to have states in pending for a long time. It has some retry logic, similar to what ZeroSSL does.
I'll say, according to the RFC, the status of a challenge should be "processing" while retrying:
While the server is still trying, the status of the challenge remains "processing"; it is only marked "invalid" once the server has given up.
Not "pending" indefinitely.
Makes me wonder about all the people recommending SmallStep for local CA's. Now that I know this, I wouldn't recommend it, unless they fix their RFC8555 conformity.
Quick glance through the code, I think step-ca doesn't implement a processing state at all [1, 2]
I've actually struggled a lot setting up smallstep the way I want and I'm still missing quite a bit of features I think are necessary (for example OCSP/CRL support or even simple logging). But I don't want to go too far off-topic here .
Hi everyone, thanks for the input, I'm reading through everything now. And yes, I'm using Smallstep. And you're right, Jellyfin is using port 8096, which I haven't changed. I had forgotten about that.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.