Cloudflare, Namecheap, LetsEncrypt, Nginx, RPI3 and NAT


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

My domain is:

I ran this command: wget

It produced this output:
> wget
> --2017-01-25 18:55:27--
> Resolving (…
> Connecting to (||:443… connected.
> ERROR: cannot verify’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 ‘’.
> To connect to 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):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

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

  • domain: 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).

  • I setup namcheap to use the cloudflare nameservers
  • after many failures, i changed the status on cloudflare to “Paused” in order to just use dns. I thought this might help in tracking down my issues
  • I installed the dehydrated client( along with a hook for using cloudflare to respond to dns-01 challenges (
  • after setting the environment variables and running “./dehydrated -c -d -d -t dns-01 -k ‘hooks/cloudflare/’”, certs were generated in “/etc/dehydrated/certs/”
  • setup nginx to use those keys

server {
listen 443;
ssl on;
ssl_certificate /etc/dehydrated/certs/;
ssl_certificate_key /etc/dehydrated/certs/;

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



server {
listen 80;
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?


Nginx- New Certificate Obtained but Not In Use

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/;
	charset UTF-8;
	access_log /var/log/nginx/;
	error_log /var/log/nginx/;
	# First include our certificates and chain of trust
	ssl_certificate /etc/letsencrypt/live/;
	ssl_certificate_key /etc/letsencrypt/live/;
	## verify chain of trust of OCSP response using Root CA and Intermediate certs
	ssl_trusted_certificate /etc/letsencrypt/live/;

	# 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
	ssl_prefer_server_ciphers on;
	add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
	ssl_stapling on;
	ssl_stapling_verify on;

server {
	listen 80;
        return 301$request_uri;


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.


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


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 )


Yip sounds indeed like that is possibly the cause.


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


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


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