letsencrypt
lexicon
Our great sponsors
letsencrypt | lexicon | |
---|---|---|
21 | 16 | |
30,850 | 1,442 | |
0.7% | - | |
9.0 | 8.8 | |
17 days ago | 2 months ago | |
Python | Python | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
letsencrypt
-
ACME with Google Domains using a DNS Zone in GCS DNS
This seems to be not implemented in certbot, yet: https://github.com/certbot/certbot/issues/6566
-
OpenSpeedTest in docker through DSM Reverse Proxy - incorrect upload speeds
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 run.bat file identified as batloader trojan by windows defender. Windows defender alerted me of a trojan which appears to simply be the startup batch script for certbot. Currently running full system scan, but I suspect it to be a false positive. Any ideas?
-
Snap Store administrators removed signal-desktop from Ubuntu Snap
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
-
Good Use Of Golang?
Here’s a good code reference (Python and rust): https://github.com/certbot/certbot
-
Let's Encrypt Certbot Not Working on FreeBSD
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
-
How to update Certbot on Debian 11
Last release: https://github.com/certbot/certbot/releases (on 28th August 2022 = 1.29.0)
-
Uacme: ACMEv2 client written in plain C with minimal dependencies
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-...
-
Let’s Encrypt Receives the Levchin Prize for Real-World Cryptography
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...
-
Setting up nginx+letsencrypt as a reverse proxy
# 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; } } }
lexicon
-
Dehydrated: Letsencrypt/acme client implemented as a shell-script
One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)
This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (< 100 LOC) and it worked extremely well.
[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...
[2]: https://github.com/AnalogJ/lexicon
-
Why Certificate Lifecycle Automation Matters
A reminder that if you an internal-only server where the typical http-01' verification connection method will not work, especially if you cannot easily/dynamically update DNS records, one can use dns-01* by using DNS aliasing/CNAME:
* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/
* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
So if you want a cert for www.internal.example.com, you will first have do a one-time change to have a _acme-challenge.www.internal… CNAME created to point to any other (sub-)domain where you can easily update things dynamically, e.g., www-internal.example-dnsapi.com.
When request the cert for "www.internal…", LE/ACME will look up the corresponding _acme-challenge record, and go to "_acme-challenge.www-internal.example-dnsapi.com. The nonce token will be there in the 'final' destination following the CNAME in a TXT, which shows LE/ACME that you control the DNS chain.
To do the DNS updating, you can use a CLI/Python library like Lexicon, which supports dozens of APIs:
* https://github.com/AnalogJ/lexicon
-
Easy HTTPS for your private networks
This leverages the ACME DNS server which has a REST API:
* https://github.com/joohoi/acme-dns
If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel:
* https://github.com/AnalogJ/lexicon
* https://pypi.org/project/dns-lexicon/
* https://dns-lexicon.readthedocs.io/en/latest/user_guide.html
- Wie kommt Google Safe Browsing darauf, dass alle Seiten auf meiner Dyndns Domain phishing Seiten sind?
-
Uacme: ACMEv2 client written in plain C with minimal dependencies
> It even comes preconfigured for various DNS providers[2]
Also, CLI utility that supports a bunch of APIs:
* https://github.com/AnalogJ/lexicon
-
what are better alternatives of noip?
Then, you can use ddclient, which supports many DNS services (including those providing DynDNS protocol), or you can write a Python script using the dns-lexicon module to manipulate the DNS records over the API.
- NextDNS Launches API
- Lexicon: Manipulate DNS records on various DNS providers in a standardized way.
- Lexicon: Manipulate DNS records on various DNS providers in a standardized way
- Some of the popular DNS management services as a self hosted service
What are some alternatives?
acme.sh - A pure Unix shell script implementing ACME client protocol
octoDNS - Tools for managing DNS across multiple providers
lego - Let's Encrypt/ACME client and library written in Go
dehydrated - letsencrypt/acme client implemented as a shell-script – just add water
extdns - External DNS for docker-compose
Cloud-Init - unofficial mirror of Ubuntu's cloud-init
duckdns - Caddy module: dns.providers.duckdns
dehydrated-bigip-ansible - Ansible based hooks for dehydrated to enable ACME certificate automation for F5 BIG-IP systems
SaltStack - Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
docker-dehydrated-lexicon - Just a container to help on requesting letsencrypt certificates with dns-01 validation