SSL/DNS name resolution trying to run website on my own server

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.

Hi @Hush

checking your domain there is no problem visible.

Your dns entry is correct ( https://check-your-website.server-daten.de/?q=billybb.ca )

Host T IP-Address is auth. ∑ Queries ∑ Timeout
billybb.ca A 209.197.188.133 Vancouver/British Columbia/Canada (CA) - Distributel-as11814 - Communications Ltd. Hostname: hs-scarlett-201405300133.3web.net yes 2 0
AAAA yes
www.billybb.ca C billybb.ca yes 1 0
A 209.197.188.133 Vancouver/British Columbia/Canada (CA) - Distributel-as11814 - Communications Ltd. Hostname: hs-scarlett-201405300133.3web.net yes

it’s not the error using a frame redirect or something else that can’t work.

And checking the standard urls port 80 answers:

Domainname Http-Status redirect Sec. G
http://billybb.ca/
209.197.188.133 200 0.400 H
http://www.billybb.ca/
209.197.188.133 200 0.390 H
https://billybb.ca/
209.197.188.133 -14 10.017 T
Timeout - The operation has timed out
https://www.billybb.ca/
209.197.188.133 -14 10.020 T
Timeout - The operation has timed out
http://billybb.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
209.197.188.133 404 0.390 A
Not Found
Visible Content: 404 Not Found nginx/1.15.9 (Ubuntu)
http://www.billybb.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
209.197.188.133 404 0.400 A
Not Found
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.

PS:

That’s not a “forwarding” (frame redirect to the ip address), it’s a normal and correct DNS A entry. So it’s independend from GoDaddy.

That’s wrong. Your setup has nothing to do with the fact that you run a home server. It’s the standard setup:

DNS A entry domain name -> ip address.

So start with

sudo certbot --nginx -d billybb.ca -d www.billybb.ca

and share the output if that doesn’t work.

PPS: And you don’t need an own DNS server.

3 Likes

Hello JuergenAuer,

First,and foremost greatly appreciate your offer to help in solving this problem. Admittedly I’d be lost without your expertise.

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

1 Like

Then you use certbot-auto, not certbot.

wget https://dl.eff.org/certbot-auto
sudo mv certbot-auto /usr/local/bin/certbot-auto
sudo chown root /usr/local/bin/certbot-auto
sudo chmod 0755 /usr/local/bin/certbot-auto

Now your dns setup is wrong. Now you use the wrong ip forwarding - https://check-your-website.server-daten.de/?q=billybb.ca

Host T IP-Address is auth. ∑ Queries ∑ Timeout
billybb.ca A 184.168.131.241 Scottsdale/Arizona/United States (US) - GoDaddy.com, LLC Hostname: ip-184-168-131-241.ip.secureserver.net yes 2 0
AAAA yes
www.billybb.ca C billybb.ca yes 1 0
A 184.168.131.241 Scottsdale/Arizona/United States (US) - GoDaddy.com, LLC Hostname: ip-184-168-131-241.ip.secureserver.net yes

And there you see the mess:

Domainname Http-Status redirect Sec. G
http://billybb.ca/
184.168.131.241 200 0.373 H
http://www.billybb.ca/
184.168.131.241 200 0.390 H
https://billybb.ca/
184.168.131.241 200 4.390 N
Certificate error: RemoteCertificateNameMismatch
https://www.billybb.ca/
184.168.131.241 200 4.327 N
Certificate error: RemoteCertificateNameMismatch
http://billybb.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
184.168.131.241 200 0.390
Visible Content: BillyBB
Info: Html-Content with frame found, may be a problem creating a Letsencrypt certificate using http-01 validation
http://www.billybb.ca/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
184.168.131.241 200 0.420
Visible Content: BillyBB
Info: Html-Content with frame found, may be a problem creating a Letsencrypt certificate using http-01 validation

Now /.well-known/acme-challenge has the following content and sends the wrong http status 200 instead of 404.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>BillyBB</title> <meta name="description" content=""> <meta name="keywords" content=""> </head> <frameset rows="100%,*" border="0"> <frame src="https://209.197.188.133/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de" frameborder="0" /> </frameset> </html>

So validation can’t work. Undo your dns change.

Please read

Never use the -q option, that hides potential problems.

1 Like

Hello JuergenAuer,

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:

billybb.ca located in etc/nginx/sites-enabled/

server { listen 80;
listen [::]:80;
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;
}
}

media/extusb/internet is where the index.html file is stored on the server which is located on a separate drive.

Hope something of what has been provided may be useful.

Terry

Hi @Hush,

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.

2 Likes

Let’s Encrypt validation doesn’t work when you’re using GoDaddy URL forwarding.

(For that matter, setting up HTTPS won’t really work either.)

You need to use a regular A record with your IP address instead.

2 Likes

As written - SSL/DNS name resolution trying to run website on my own server

If your dns setup show secureserver.net, that can’t work.

Change your dns-setup to your first configuration.

2 Likes

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.

Thank you

Which part isn’t working?

For me, connecting to https://billybb.ca/ times out. It seems like port 443 is probably being blocked by a firewall.

Hello mnordhoff,

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:

  1. HTTPS requires a DNS with a Type A-Record
  2. 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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.