This supposedly sends all the request to the VM. Inside the VM there is Nginx-proxy and acme-companion who issue certificates for a an app inside a container. It says in the acme-companion logs that the ssl certificate has been issued, and I agree I see it in the shared volume and every path looks like it is correct. But it still gives me these errors:
curl -v http://example.com
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.29.0</center>
</body>
</html>
* Connection #0 to host example.com left intact
Same with https.
It says that something is up with the TLS handshake:
openssl s_client -connect example.com:443 -servername example.com
CONNECTED(00000003)
4027586079700000:error:0A000458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:../ssl/record/rec_layer_s3.c:1599:SSL alert number 112
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 327 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Here is also the configuration for my nginx proxy for the site:
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it (and make our life a lot harder). In any case, all the answers to this questionnaire are required:
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.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on 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):
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):
Can't really share my domain, don't have a valid reason why, sorry.
The commands I ran:
I didn't run any, they were executed automatically by acme-companion.
The produced output:
Shows in the main message.
My webserver is: Ubuntu (idk what is the information you are looking for)
OS: Ubuntu 24 LTS
I have root access
I am not using certbot, I am using acme.
I can't see anything strange with the last nginx version you've shown, so without the actual domain name, which is mandatory according to the questionnaire, we can't debug further.
You might get lucky if some other volunteer somehow magically can point you to something without the domain, but chances are you won't get any further without mentioning it.
"ACME" is a protocol, Certbot was just an example of an ACME client (for some reason most of the new people here read over the "if" in the question..). In your case that "acme-companion" seems to be using the ACME client "acme.sh" according to their GH repo. The idea behind the version question is to provide the version of the ACME client in use, whether that's Certbot or another ACME client. But as you already have the certificate, this specific question is not that important.
It's quite weird when looking at the stream in WireShark..
After OpenSSL sends the ClientHello (with or without an SNI hostname), your server immediately quits the connection gracefully with a "FIN" TCP packet.. No actual TLS data gets returned after the ServerHello. It just disconnects from your servers end for some reason.
Are you absolutely sure that port 443 is properly mapped to NGINX? What kind of hosting are you on (you left out the hosting provider question for some reason..) VPS? Can there be some kind of firewall from your hosting provider in between the web and your server blocking access to port 443?
I am selfhosting it. I have 2 VMs one is a reverse proxy which sends the traffic to the other VM which has the containers for nginx-proxy, acme-companion and the webiste itself. How can I check whether I have some kind of firewall?
Well, that reverse proxy only sends HTTP port 80 requests to your VM. Do you have a server block in that nginx that also sends HTTPS port 443 to your VM? Or some other way to redirect port 443 back to that VM?
In the reverse proxy vm there is no server block for 443 requests. But on the non reverse proxy vm there is a server block for 443 that listens and is configured, here it is:
Yes, I saw that. But, if you need a reverse proxy to route HTTP port 80 requests to your backend VM then how are you getting HTTPS port 443 requests to your backend?
If your backend VM can handle HTTPS directly then why do you need a front end proxy for port 80?
Your nginx reverse proxy config is currently serving normal http on port 443. Double check that your current port 443 server block is setup to match the correct site domain name.