mirror of
https://github.com/0xJacky/nginx-ui.git
synced 2026-04-25 08:45:58 +03:00
[GH-ISSUE #407] ACME error - Could not find solver for: tls-alpn-01 #234
Labels
No labels
Q/A
bug
casdoor
dependencies
docker
documentation
duplicate
enhancement
help wanted
invalid
lego
platform:openwrt
platform:windows
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-ui#234
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Green2Matter on GitHub (May 24, 2024).
Original GitHub issue: https://github.com/0xJacky/nginx-ui/issues/407
Describe the bug
Not able to create SSL certificate using builtin ACME client
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Create certificate
Info (please complete the following information):
@0xJacky commented on GitHub (May 25, 2024):
no subdomain because the domain and the zone are identical: domain.com.It seems that the error is returned by the dns provider, have you try to issue the certificate again, or try another dns prodiver?
@Green2Matter commented on GitHub (May 25, 2024):
I've installed acme.sh and got certificate (using same API keys) after issuing:
acme.sh --issue -d domain.com -d '*.domain.com' --dns dns_ovh --server letsencrypt --keylength ec-384To me it looks like nginxui acme client doesn't submit correctly either keys or domain while sending request...
@0xJacky commented on GitHub (May 25, 2024):
You can try https://github.com/go-acme/lego with CLI mode, in nginxui we use this tool to obtain certificate, if the problem still exists maybe we should turn to the author of that project for help.
@Green2Matter commented on GitHub (May 25, 2024):
What version of lego package do you use? In debian there's available lego/stable 4.9.1-1 amd64.
When I have spare time, I'll try to install and test it...
@0xJacky commented on GitHub (May 25, 2024):
v4.16.1
@Green2Matter commented on GitHub (May 27, 2024):
So, after issuing command:
lego --email admin@domain.com --dns ovh --domains domain.com --domains *.domain.com runI received:
Thus, it seems like issue is within nginxui...
@DekFTW commented on GitHub (May 30, 2024):
I'm unable to get wildcard certificates, too. But they worked in the past with nginx-ui.
@0xJacky commented on GitHub (May 30, 2024):
Please provide the logs, thanks!
@Green2Matter commented on GitHub (May 30, 2024):
I will add also that dashboard's graphs (CPU and Network) aren't refreshed properly:
Graphs are visible only on page load and after a few seconds - with first auto refresh, they are gone...
@0xJacky commented on GitHub (May 30, 2024):
Did you use nginx to proxy the nginx-ui?
@0xJacky commented on GitHub (May 30, 2024):
This issue is common if the websocket is not available, you can press F12 to open the console of the browser, switch to the Network tab and check if the server send the analytics data through websocket properly.
@0xJacky commented on GitHub (May 30, 2024):
I will upgrade lego to the latest version(v4.17.3) in next beta verison of nginx-ui, but I can't ensure this will solve your problem.
@Green2Matter commented on GitHub (May 30, 2024):
"nodes?token" https status is 101 (switching protocols) and there are empty ("{}") messages sent. Same behaviour is on non proxied (port 9000, raw nginxui data) service as is on proxied https - which uses http2.
"nginx_log?token" has same status (101) and in messages: '{"type":"error","server_idx":null,"directive_idx":null}'
In both cases payload consists of the same token.
@Green2Matter commented on GitHub (May 30, 2024):
Ok, I've re-applied your Nginx config for nginxui and now I receive messages but dashboard graphs (except Disk I/O) remaining empty...
But non proxied (port 9000) doesn't receive any message...
@0xJacky commented on GitHub (Jun 1, 2024):
Did you try to reinstall nginx-ui? I mean remove the database.db and app.ini in /usr/local/etc/nginx-ui, and use the installation script to reinstall it.
@Green2Matter commented on GitHub (Jun 1, 2024):
That's what I did:
Content of app.ini:
And reinstallation didn't change anything...
@0xJacky commented on GitHub (Jun 1, 2024):
Did you visit http://ip:port/install in the browser?
@Green2Matter commented on GitHub (Jun 1, 2024):
Yes, of course. User and database were created at that step...
@0xJacky commented on GitHub (Jun 18, 2024):
Hi @Green2Matter, I updated the lego version to v4.17.3 in the nginx UI v2-beta.25, and you can try this version to see if the problem still persists.
@Green2Matter commented on GitHub (Jun 25, 2024):
Hi @0xJacky unfortunately it didn't help. Still there's the same error...
@0xJacky commented on GitHub (Jun 25, 2024):
I am sorry about that, can you please provide us the logs of Nginx UI?
By executing the following command:
@Green2Matter commented on GitHub (Jun 25, 2024):
logs (sanitised) when trying to issue cert:
For a test with standalone lego, I was using exactly same ovh credentials...
@0xJacky commented on GitHub (Jul 20, 2024):
Hello @Green2Matter, I apologize for keeping you waiting for so long. I have just synchronized the lego configuration file and noticed that there are updates regarding ovh in lego. I have now released a new Nginx UI v2.0.0-beta.25. You can directly reinstall v2.0.0-beta.25 through the Online Update and restart Nginx UI, or reinstall using the script, then re-add the ovh DNS credentials. You should see new options like OVH_CLIENT_ID and OVH_CLIENT_SECRET.
Please ensure that the environment variables in the DNS Credentials you add are consistent with the environment variables you use when executing lego in the terminal.
I hope this resolves your issue.
@Green2Matter commented on GitHub (Jul 20, 2024):
Hi @0xJacky, thanks for an update but I'm a bit confused.
I've been running Nginx UI v2.0.0-beta.25 for a weeks already. And ok, I reinstalled it and got new OAuth2 credentials option. But this has never been required to issue certificate. For example, acme.sh works without them perfectly.
I think all boils down to this error:
Lego doesn't send command understandable for OVH servers...
@0xJacky commented on GitHub (Jul 20, 2024):
Please try the following steps:
SSH into the server.
Stop the Nginx UI service:
Execute the following command:
Do not close the SSH session. Meanwhile, access Nginx UI in your browser and attempt to request a certificate again using the DNS Challenge method.
See if you can successfully request the certificate this time.
@0xJacky commented on GitHub (Jul 24, 2024):
Hi @Green2Matter, can you try this method? I think we're very close to the casue of the issue.
@Green2Matter commented on GitHub (Jul 24, 2024):
Hi @0xJacky!
Sorry for late reply, I couldn't test it earlier. Anyway, with this new variable enabled - it did work! See below log.
Will you publish new nginx-ui version?
@0xJacky commented on GitHub (Jul 24, 2024):
Great! I’ll add a switcher at an appropriate location for users to set LEGO_DISABLE_CNAME_SUPPORT. This will allow users who use CNAME domains and cannot issue certificates to try disabling LEGO’s CNAME support and obtain certificates correctly.
Reference: Traefik Community - Traefik cannot issue certificate for CNAME’d wildcard domain.
For now, you can exit nginx-ui, restart it using systemctl, and wait for the next version of the Nginx UI.