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 ran it a second time because I didn't save the log originally, so it asks about renewal
Command output
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certificate not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/smallpepperz.com.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for smallpepperz.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/smallpepperz.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/smallpepperz.com/privkey.pem
This certificate expires on 2021-11-01.
These files will be updated when the certificate renews.
NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
My web server is (include version):
nginx/1.19.4
The operating system my web server runs on is (include version):
macOS Big Sur
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):
Both certbot and nginx are in docker containers, if that's relevant. It uses a docker compose file with the latest versions of certbot/certbot and nginx. Docker version 20.10.7
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
1.17.0
I generated a certificate for my domain, and the setup process seems to have been successful. The issue I'm having is that my browser warns me the certificate is invalid, and WhyNoPadlock along with similar sites say my certificates are for *.mproxy.io. I have not heard of mproxy, and a google search turns up nothing. Nginx shows no errors when starting.
Let's have a look at the entire nginx config with: nginx -T
I suspect that although the vhost config for HTTP (TCP port 80) was sufficiently matched to obtain the cert, the vhost config for HTTPS (TCP port 443) isn't correctly configured to serve that name (and is serving the first/default configuration).
OR (even worse)
This is your first attempt at connecting to your system via HTTPS (TCP port 443) and the NAT device is either accepting the connections itself or passing them to another device (not to your Mac).
TLS is difficult enough...
Combining HTTP and HTTPS in one server block is NOT for the beginner.
I consider my self much more than that and even I don't bother doing that.
[the gain, if any, isn't worth the added complexity]
And as there is no mention of any other cert, I can only suspect the path has been deviated.
Whereas HTTP (TCP port 80) does reach your system.
HTTPS (TCP port 443) does not.
HTTPS is being intercepted by something/somehow along the way.
A device that can somehow synchronize its' active wildcard certificate (*.mproxy.io) with the Internet.
I've split the server into two vhosts, which doesn't seem to have changed anything. According to the google wifi app (I have a google mesh network), both 443 TCP and 80 TCP are being forwarded to the correct local IP. Is there a way to check how far the https request is getting/where it's being stopped?
I don't know of anything that can explicitly follow one particular TCP port to the detail necessary to answer your implied request. traceroute can show route hops along the way using ICMP packets or UDP packets typically in the port range 334xx-336xx. I've never tried using TCP port 443 for that. I guess that is worth trying.
I get:
traceroute -Tp 443 smallpepperz.com
traceroute to smallpepperz.com (97.115.71.97), 30 hops max, 60 byte packets
1 [redacted] 1.751 ms 2.037 ms 2.397 ms
2 [redacted] 2.591 ms 3.143 ms 2.601 ms
3 * * *
4 99.167.38.110 (99.167.38.110) 12.985 ms 6.719 ms 13.329 ms
5 12.242.116.11 (12.242.116.11) 12.878 ms 20.684 ms 14.723 ms
6 * * *
7 ae-1-37.bar3.Portland1.Level3.net (4.69.218.234) 87.812 ms 108.035 ms 108.389 ms
8 4.68.38.154 (4.68.38.154) 90.331 ms 87.980 ms 82.873 ms
9 207.225.86.162 (207.225.86.162) 86.021 ms 86.053 ms 84.985 ms
10 97-115-71-97.ptld.qwest.net (97.115.71.97) 81.925 ms 81.642 ms 81.660 ms
11 97-115-71-97.ptld.qwest.net (97.115.71.97) 83.125 ms 82.338 ms 84.727 ms
12 97-115-71-97.ptld.qwest.net (97.115.71.97) 86.020 ms 85.266 ms 82.912 ms
Does that device respond to port 443?
If so, can that port be changed to another?
[I suspect the WiFi mesh device is the one that is using port 443 (with `*.mproxy.io` cert)]
Remember that your external internet traffic will come in via your router, then go to google wifi via ethernet, so it's still possible your router is not forwarding port 443 to the correct place. I've got google mesh as well and so have to forward ports from the router to the mesh network, then on the mesh network forward to a service specific host. [Edit: so your router is probably forwarding port 443 to your monocle home automation stuff]
Or the router isn't forwarding port 443 at all and is the one responding (with "Monocle-Gateway").
[If only we knew what a Gateway wearing a Monocle is/does!]
Looks like Monocle (a smart home thing) is using port 433 for its own internal SSL stuff. I just had my Docker container expose it as port 444 locally and forwarded that to 443 externally, and it seems to be working (I think)