cloudflare-ddns-updater VS letsencrypt

I don't want to face difficulties if my ISP changes my IP address for whatever reason. So I'm planning to get something like this or this set up. I want to make sure I have my 'A' records set up correctly first.

Second this. I run this script with a cron job to update my Cloudflare as well and never had any problems with it.

I just use this script running on a VM to keep CloudFlare pointed to my public IP. Couldn’t figure out a way to get the UDMP to do it natively.

Well originally my plan, which I glossed over in my previous message, was to set my domain 'ABC' to point to my home IP, with a few CName, A or AAA records pointed to specific devices I wanted to access externally from my house (PC's I can RDP into for example), and I wanted to set up a subdomain (which I think would be an A and/or AAA record) which pointed to my Wix site so the only domain for it would be something like 'Wix.ABC.com', but it's looking like that won't be possible. I know Wix has options to set up A, AAA and Cname records on domains connected to a Wix website but as far as I'm aware they don't have an API for users to update them and I've never seen an 'app' to dynamically update them like the Cloudflare DDNs script. If I end up just buying a new domain for my Wix site then I guess making a subdomain from the ABC domain link to it wouldn't be much use.

If you want an easy Cloudflare DDNS script https://github.com/K0p1-Git/cloudflare-ddns-updater Unless you have an allocated DNS server already

Cloudflare API and this script on a nightly cron.

My only thoughts would be to purchase a domain from somewhere like GoDaddy and move the DNS nameservers for the domain over to a free Cloudflare account. Then use a script with the Cloudflare API to update your DNS entries to point to your NGINX host.

Here's the script I am using Cloudflare DDNS Updater

I never seemed to be able to get ddclient to work with cloudflare. I’d vouch for K0p1’s Cloudflare ddns script. It’s been working great for me

This seems to be not implemented in certbot, yet: https://github.com/certbot/certbot/issues/6566

If you do go with NPM or Traefik, under the covers it's using certbot to request/renew your certificates through Let's Encrypt using the DNS-01 challenge, meaning you can get wildcard certs and don't have to futz around with port forwards. Again I'd think Caddy has similar functionality, I just have not used it personally. Raw NGINX you probably don't want to try out yet considering it requires manually doing the configs

certbot won't be missed. The code quality is pretty poor.

https://github.com/certbot/certbot/issues 5000 bugs and it most of it can be replaced by much smaller tools

Here’s a good code reference (Python and rust): https://github.com/certbot/certbot

I am trying to migrate off of Linux and back to FreeBSD, but I hit a problem today. The Let's Encrypt Certbot is not installing. A bit surprising, given how important it is. So I thought I would notify the community Here is my bug report. https://github.com/certbot/certbot/issues/9394

Last release: https://github.com/certbot/certbot/releases (on 28th August 2022 = 1.29.0)

Right? It’s so ridiculous how you’re supposed to use Snap to install certbot. The (well, one of..) GitHub discussion is just beyond the pale:

https://github.com/certbot/certbot/issues/8345#issuecomment-...

It goes way beyond, since Let's Encrypt influence the ecosystem a lot and the standards that are used.

If you use Let's Encrypt, you are likely using Certbot, which means that everybody uses a tool that a central authority strongly recommends to you.

I wonder how they generate the key, for example, it may be using secp256r1: https://github.com/certbot/certbot/blob/5c111d0bd1206d864d7c...

# nginx-ingress-https.conf events { } http { include mime.types; server { listen 443 ssl; listen [::]:443 ssl; server_name sg.horlick.me; ssl_certificate /etc/letsencrypt/live/sg.horlick.me/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/sg.horlick.me/privkey.pem; # taken from https://github.com/certbot/certbot/blob/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf ssl_session_cache shared:le_nginx_SSL:10m; ssl_session_timeout 1440m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"; ssl_dhparam /etc/ssl/certs/dhparam.pem; sendfile on; tcp_nopush on; tcp_nodelay on; location / { proxy_pass http://host.docker.internal:9090/; proxy_http_version 1.1; proxy_cache_bypass $http_upgrade; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port; } } }