Cloudflare, Namecheap, LetsEncrypt, Nginx, RPI3 and NAT

Help
1

Please fill out the fields below so we can help you better.

My domain is: coderuck.us

I ran this command: wget https://coderuck.us

It produced this output:
> wget https://coderuck.us
> --2017-01-25 18:55:27-- https://coderuck.us/
> Resolving coderuck.us (coderuck.us)... 172.127.48.62
> Connecting to coderuck.us (coderuck.us)|172.127.48.62|:443... connected.
> ERROR: cannot verify coderuck.us's certificate, issued by ‘O=Mini Webservice Ltd,ST=Some-State,C=PL’:
> Self-signed certificate encountered.
> ERROR: certificate common name ‘’ doesn't match requested host name ‘coderuck.us’.
> To connect to coderuck.us insecurely, use `--no-check-certificate'.

My operating system is (include version): Raspian Jesse

My web server is (include version): Nginx

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

I bought a cheap ($0.88) domain from Namecheap to use to play around with LetsEncrypt. My set up is:

  • domain: coderuck.us purchased though namecheap
  • dns: cloudflare
  • raspberry pi 3 running latest raspbian jesse
  • Nginx
  • dehydrated LE client with cloudflare hook for dns-01 validation
  • ports 80 and 443 forwarded from external router
  • ddclient setup for dynamic dns ip update

I initially tried to set this up using namecheaps dns but after experimenting and googling around, I abandoned it for cloudflare (maybe this was a mistake, maybe i could've used http-01 validation for generating the certs but there was a lot of negativity from other googlers).

server {
listen 443;
server_name coderuck.us;
ssl on;
ssl_certificate /etc/dehydrated/certs/coderuck.us/fullchain.pem;
ssl_certificate_key /etc/dehydrated/certs/coderuck.us/privkey.pem;

#Include actual web application configuration here.
root /var/www/html;

}

and

server {
listen 80;
server_name coderuck.us;
location / {
return 301 https://$server_name$request_uri;
}
}

nginx came up clean and I thought I was in business. When i went to the site from my internal network, everything worked as expected. the "secure" lock was displayed and I can view the certificate and show the it is from Lets Encrypt. When I hit it from outside my network, I get the "Your connection is not private" and a "NET::ERR_CERT_COMMON_NAME_INVALID" error.

I feel like I maybe missing something simple but can't seem to figure it out. Can anyone help?

Thanks,
Charlie

2

You haven’t included your full chain of certificates, specifically ssl_trusted_certificate. This is how your nginx conf for the site should look. Also your certs should be located in /etc/letsencrypt/live/domainname/

server {
	# SSL configuration
	#
	listen 443 ssl http2;

	root /var/www/mywebsite.com;
	server_name mywebsite.com www.mywebsite.com;
	charset UTF-8;
	access_log /var/log/nginx/mywebsite.com-access.log;
	error_log /var/log/nginx/mywebsite.com-error.log;
	
	# First include our certificates and chain of trust
	ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem;
	## verify chain of trust of OCSP response using Root CA and Intermediate certs
	ssl_trusted_certificate /etc/letsencrypt/live/mywebsite.com/chain.pem;

	# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
	ssl_dhparam /etc/nginx/ssl/dhparam.pem;
	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:128m;
	ssl_session_tickets off;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	# ciphers recommended by https://mozilla.github.io/server-side-tls/ssl-config-generator/
	ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
	ssl_prefer_server_ciphers on;
	add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
	ssl_stapling on;
	ssl_stapling_verify on;

}
server {
	listen 80;
	server_name mywebsite.com www.mywebsite.com;
        return 301 https://mywebsite.com$request_uri;
# END OF HTTP PORT 80 HOST CONFIG - CLOSING BRACE BELOW THIS LINE
}
3

My guess is that it’s nothing to do with the full chain - rather than you have a device (possibly your router) that isn’t forwarding port 443 - and is actually the device with the “mini webserver ltd” certificate on it.

3 Likes
4

Seems the real problem is it's using a self signed certificate.

Screen Shot 2017-01-26 at 12.36.46 PM.png1580×516 87.6 KB

Screen Shot 2017-01-26 at 12.39.52 PM.png1085×886 84.2 KB

5

Yes - and since the config is for the correct certs from Let’s Encrypt, hence my guess was that self signed cert is on a router which isn’t just forwarding https traffic (fairly common on a home router which I’m guessing this is for an RPI3 )

1 Like
6

Yip sounds indeed like that is possibly the cause.

7

Thanks that was the issue. A slightly more detailed explanation is

  • I thought I was forwarding all traffic from my uverse router to my own router
  • what I was really doing was forwarding all traffic except for port 443 to my own router
  • so when i tried it on my home network, it only hit my own router (which was setup properly) and it worked
  • external traffic hit the uverse router first and returned the bad cert
2 Likes
8

Excellent, glad you got it sorted. All looks good on my end now :wink:

9

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