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. https://crt.sh/?q=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:billybb.ca
I ran this command:
It produced this output:
My web server is (include version):
nginx
The operating system my web server runs on is (include version):
ubuntu
My hosting provider, if applicable, is:
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):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.31.0
Hello just trying to provide additional details regarding my own listed topic. That is, there wasn’t any option to clarify the help for which I was seeking support? I am trying to host a public website from an ubuntu server setup in my basement running nginx and kind of struggling how to get SSL working (ie. HTTPS). Publically my website may be accessed using a static IP (http://209.197.188.133/). I have a godaddy website (billybb.ca) which forwards all public URL requests to my static public IP as either http: or https:. Let’s encrypt did not the idea of godaddy forwarding (billybb.ca) to my home static public IP, Not sure how to get around this. Before SSL it was easy to setup one’s own webserver but have no idea how to do this now with SSL. I really enjoy hosting my own website on my own server but unsure how to resolve the issue of requiring a DNS name unless adding and setting up a DNS Server onto the Ubuntu server my solve the problem? Would greatly appreciate any tips. Thank you.
Visible Content: 404 Not Found nginx/1.15.9 (Ubuntu)
Port 80 + /.well-known/acme-challenge/random-filename has the expected result http status 404 - Not Found.
So: What Certbot command did you used? What's the output?
Read:
A Good: All checks /.well-known/acme-challenge/random-filename without redirects answer with the expected http status 404 - Not Found. Creating a Letsencrypt certificate via http-01 challenge should work. If it doesn't work: Check your vHost configuration (apachectl -S, nginx -T). Every combination of port and ServerName / ServerAlias (Apache) or Server (Nginx) must be unique. Merge duplicated entries in one vHost.
The output from the terminal command you provided is as follows:
“The requested nginx plugin does not appear to be installed”
I am running Ubuntu 19.04 (disco) which maybe part of the problem. When going through the Let’s Encrypt install process Ubuntu 19.04 wasn’t in the list and therefore selected “Other”. Should I try and reinstall Ubuntu 18.04 LTS, which is an option included in the “Let’s Encrypt” OS drop-down list. Also providing the output for the letsencrypt.og file:
Today changed my godaddy DNS www.billy.ca to forward https://209.197.188.133. This doesn’t work right now because SSL is not setup but guessing this is a necessary first step.
/var/log/letsencrypt/letsencrypt.log
2019-07-28 00:17:04,043:DEBUG:certbot.main:certbot version: 0.31.0
2019-07-28 00:17:04,044:DEBUG:certbot.main:Arguments: [’-q’]
2019-07-28 00:17:04,044:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-07-28 00:17:04,072:DEBUG:certbot.log:Root logging level set at 30
2019-07-28 00:17:04,072:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-07-28 00:17:04,096:DEBUG:certbot.renewal:no renewal failures
2019-07-28 14:02:21,309:DEBUG:certbot.main:certbot version: 0.31.0
2019-07-28 14:02:21,310:DEBUG:certbot.main:Arguments: [’-q’]
2019-07-28 14:02:21,310:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-07-28 14:02:21,374:DEBUG:certbot.log:Root logging level set at 30
2019-07-28 14:02:21,374:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-07-28 14:02:21,400:DEBUG:certbot.renewal:no renewal failures
2019-07-29 09:12:21,800:DEBUG:certbot.main:certbot version: 0.31.0
2019-07-29 09:12:21,801:DEBUG:certbot.main:Arguments: [’-q’]
2019-07-29 09:12:21,801:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-07-29 09:12:21,873:DEBUG:certbot.log:Root logging level set at 30
2019-07-29 09:12:21,874:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-07-29 09:12:21,904:DEBUG:certbot.renewal:no renewal failures
2019-07-29 20:08:20,286:DEBUG:certbot.main:certbot version: 0.31.0
2019-07-29 20:08:20,286:DEBUG:certbot.main:Arguments: [’-q’]
2019-07-29 20:08:20,286:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-07-29 20:08:20,300:DEBUG:certbot.log:Root logging level set at 30
2019-07-29 20:08:20,300:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-07-29 20:08:20,301:DEBUG:certbot.renewal:no renewal failures
2019-07-30 00:22:49,517:DEBUG:certbot.main:certbot version: 0.31.0
2019-07-30 00:22:49,517:DEBUG:certbot.main:Arguments: [’–nginx’, ‘-d’, ‘billybb.ca’, ‘-d’, ‘www.billybb.ca’]
2019-07-30 00:22:49,517:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-07-30 00:22:49,544:DEBUG:certbot.log:Root logging level set at 20
2019-07-30 00:22:49,545:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-07-30 00:22:49,546:DEBUG:certbot.plugins.selection:Requested authenticator nginx and installer nginx
2019-07-30 00:22:49,546:DEBUG:certbot.plugins.selection:No candidate plugin
2019-07-30 00:22:49,546:DEBUG:certbot.plugins.selection:Selected authenticator None and installer None
Appreciate your help and patience; most grateful.
You had requested output to the command line:
sudo certbot --nginx -d billybb.ca -d www.billybb.ca
Refer to attached (Fig_1)
While attempting to obtain a valid certificate several times (trial-error) unfortunately exceeded the rate-limit which I was unaware. Hope the certificate feature may be reinstated?
I had Ubuntu Server 19.04 installed which is not a standard version in the Let's Encrypt drop-down and I don't need to necessarily complicate things. Over the weekend installed ubuntu 18.04 (removed 19.04) and started over. Tried to ensure nginx server was properly setup testing multiple service-blocks (hosting different local DNS). Everything is working including for the public DNS http://www.billybb.ca
Godaddy DNS forwarding has a few options including masking which hides the static IP in the URL and just shows the DNS name in the URL which is nice (preferred). Also tried configuring the godaddy DNS manger to route public internet traffic to a sub-folder on my nginx server instead of to the main folder (ie. 209.197.188.133/billybb.ca) which worked great for http://. Routing internet traffic to a sub-folder allows hosting multiple public websites; now to try and get this working for https://
Tried different configurations to get a successful certificate unfortunately reached a cert-bot rate-limit and could no longer continue testing/trouble-shooting.
Believe the nginx service-blocks are setup properly on my server for http:// and had hoped that if everything was setup properly for http:// in nginx, then certbot would find what it needs to implement https://.
Including content of the nginx sites-available and sites-enabled folder if this helps:
This limit is from Let's Encrypt, not Certbot, and only lasts for one hour. You can also use --staging or --dry-run for debugging and testing purposes.
Again thanks for the tips JuergenAuer and also thanks for pitching in mnordhoff. One-inch at a time.
mnordhoff your tip really helped a lot. Had no idea what an ‘A record’ was until you mentioned it, did some research, removed the godaddy URL forwarding option (works for http not https) and configured the DNS (billybb.ca) with a normal A record; godaddy allows this option as well. certbot was then able to successfully issue a certificate (attached image).
Checked my sites-enabled/billybb.ca file and certbot had added the certificate information:
server {
root /media/extusb/internet;
index index.html index.htm index.nginx-debian.html;
server_name billybb.ca www.billybb.ca;
location /
{ try_files /index.html =404;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/billybb.ca/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/billybb.ca/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.billybb.ca) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = billybb.ca) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name billybb.ca www.billybb.ca;
return 404; # managed by Certbot
To try and problem solve, removed the certificate, and tested the website “http://www.billybb.ca” without the certificate and works just fine confirming nginx appears to be properly configured for http. Tried twice more to create certificates; once reinstalling the original certificate (didn’t work) then tried creating a new certificate, however this did not work as well.
JuergenAuer warned that if this site was “secureserver.net”, which it is, (check at https://check-your-website.server-daten.de/?q=billybb.ca), https:// would not work? However figured that since now I had a valid certificate it might work. Appreciate any feedback you may provide. Feel I’m so close but so far.
You are probably right, again, that my port 443 is being blocked. HTTPS requires considerably more know how compared to HTTP, but learning a lot. This is a crude diagram of my network configuration.
Suspect the 443 blockage must be either in my LAN router or ISP WAN modem and continuing to investigate. My ISP modem is setup as a DMZ Host, and forwards all IP packets from the WAN to my LAN router. This seems to work ok for hosting HTTP on my Ubuntu Server and have no problem on my desktop using HTTPS for regular internet browsing.
The LAN router connects my internal internet devices including Ubuntu server. LAN also provides wifi. This all works fine for hosting HTTP on my Ubuntu Server. Tried opening port 443 on the ISP modem, however received message that the broadband was reserved for HTTPS? Thanks for your help thus far. Anyway still plugging away trying to solve this.
Found the 443 blockage the D-Link router between the ISP Modem and Ubuntu Server. Everything works now. Thanks for your support and help. Important lessons learned:
HTTPS requires a DNS with a Type A-Record
Port 443 on modems/routers quite often needs to be manually opened.
The “Let’s Encrypt” Ubuntu copy/paste procedures are genius; everything would have worked for me the first time if I had known about the Type A DNS record and importance of unblocking port 443.
