Emerging Member
Posts: 51
Registered: ‎01-19-2018
Kudos: 18
Solutions: 2

Lets Encrypt behind a Dynamic DNS

Looking for some instructions on how to add Lets Encrypt SSL to the controller when my controller is behind a dynamic DNS and has a private IP using NAT.

Everything I have seen requires a routable IP address so that the controller can respond.

WOuld be nice if it was included in the controller itself of course 

Member
Posts: 155
Registered: ‎07-14-2018
Kudos: 36
Solutions: 19

Re: Lets Encrypt behind a Dynamic DNS

[ Edited ]

In the past I used a nginx on a Linux box with different vhosts to generate certificates for the different devices and put them to the devices via scp/ssh.

 

Getting rid of the portforwardings and keep it simpleder I switched to DNS auth and get a letsencrypt wildcard cert.

 

At the moment my zone is hosted at DNS.he.net .

Unfortunately they doesn't offer a API, but there exist a he.net hook plugin for certbot which runs fine.

 

 

There should be other providers out there for that job that that offer an api (cloudflare for example).

Emerging Member
Posts: 51
Registered: ‎01-19-2018
Kudos: 18
Solutions: 2

Re: Lets Encrypt behind a Dynamic DNS

I have a couple of issues. First is that I access my controller from inside my network and it has a completely different FQDN than my DynDNS. Second is that I already port forward 443 to my exchange server which is required for external email access so cannot forward it to machine.

Was hoping they had some sort of manual verification like NameCheap does to verify you own the domain. Then I could do the rest semi-manually.

 

Member
Posts: 155
Registered: ‎07-14-2018
Kudos: 36
Solutions: 19

Re: Lets Encrypt behind a Dynamic DNS

 

You can  manual verifiy your domain ownership both with http and dns verification.
But you have to repeat it every 90 days when you lately have to renew your certificates :-(

 

 

What speaks against a wildcard cert using dns  verification   ?

 

I try to explain it  with an example:

- my domain "spflug.de"  is registered at a  provider  (it's prosite.de, but that doesn't matter)

   Per default they also hold zone information for  this domain.

- I  created an account at http://dns.he.net and added a domain "spflug.de" there.

   Then I manually duplicated the entries  (A,MX,... Records) into the   created  Zone.

- After that   I went back  to prosite and changed  the nameserver entries to   ns1.he.net, ns2.he.net, ns3.he.net, ns4.he.net

-  Not later than 1 day he.net should be responsible for  the zone information of the domain.

- optional: I created a second zone  for my   internal devices (e.g. int.spflug.de)

   

After the zone was moved  you are able to start with the real interessting stuff:

1. getting rid of your separate dyndns provider

     He.net supports dyndns for every A/AAAA record.   It can be used directly by the  usg:

Unbenannt.png

 

2.  I installed letsencrypt certbot on my  ubuntu box and got the dns.he.net hook script  from  

   https://raw.githubusercontent.com/angel333/certbot-he-hook/

 I placed it unter /opt/certbot-he-hook.sh  and  initial call the certbot script as follows:

 

HE_USER=EnterHEUsernamehere HE_PASS=EnterHEPasswordHere certbot certonly \
       --preferred-challenges dns \
       --email yourmail@address.com \
       --manual \
       --manual-auth-hook /opt/certbot-he-hook.sh  \
       --manual-cleanup-hook /opt/certbot-he-hook.sh  \
       --manual-public-ip-logging-ok \
       --server https://acme-v02.api.letsencrypt.org/directory  \
       --domain 'int.spflug.de,*.int.spflug.de'

For regular Updates you  create a cronjob that calls "certbot renew" once a month.

 

The certbot  add's a temporary TXT record for authentification in the zone  to verify you ownership and  removes it  after that.

The certificates are  placed  unter /etc/letsencrypt/live on the linux box.

You can use further scripting to place this certificates  to your cloud key, to your exchange or whatever you want.