uacme
letsencrypt
Our great sponsors
uacme | letsencrypt | |
---|---|---|
7 | 21 | |
411 | 30,817 | |
- | 0.6% | |
4.7 | 9.0 | |
about 1 month ago | 13 days ago | |
C | Python | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
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.
uacme
- Dehydrated: Letsencrypt/acme client implemented as a shell-script
- Uacme: ACMEv2 client written in plain C with minimal dependencies
-
Retrospective and Technical Details on the Recent Firefox Outage
> So you're saying telemetry should be handled as a separate process that has nothing to do with the rest of the browser, and treated like a hostile service? [... T]his was a dumb bug and it is completely unreasonable to expect some kind of adversarial design "just in case a freak bug triggers on telemetry network requests".
I absolutely agree that this a dumb bug having little to nothing to do with telemetry. It is not even the first case-sensitivity HTTP/3 bug I’m personally encountering in the course of completely casual use[1].
At the same time, you know what? I’m glad you suggested this, because I certainly didn’t think of it. Yes, in an ideal world, telemetry absolutely should be a separate process (or thread, or at least not share an event loop—a separate “hang domain”, a vat[2] if you want). And so should everything off the critical path.
I’m not saying Firefox is bad for doing it differently. I’m saying it’s silly that Firefox is forced to play OS to such an extent because the actual one isn’t up to its demands.
[1] https://github.com/ndilieto/uacme/pull/11
[2] http://www.erights.org/elib/concurrency/vat.html
-
Who should consider using BSD over Linux and why?
Hmm .... not sure i'd necessarily say that's where i'm coming from. i'd be happy with a mix'n'match OS if most of the individual components were created and maintained with thought and care. (As distinct from e.g. "Over the last couple of weekends I learned Rust, and here's my first full program, an encrypted chat server. Enjoy!") Like, SQLite is not maintained by the OpenBSD project, but i believe it's generally considered to be a high-quality codebase. And i recently started using uacme on my server; i don't feel competent enough in C to comment directly on the quality of the codebase, but this and this indicate to me that the author has a clue (and in fact, i feel confident that they have far more of a clue than i do).
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; } } }
What are some alternatives?
acme.sh - A pure Unix shell script implementing ACME client protocol
win-acme - A simple ACME client for Windows (for use with Let's Encrypt et al.)
lego - Let's Encrypt/ACME client and library written in Go
Posh-ACME - PowerShell module and ACME client to create certificates from Let's Encrypt (or other ACME CA)
dehydrated - letsencrypt/acme client implemented as a shell-script – just add water
certify - Professional ACME Client for Windows. Certificate Management UI, powered by Let's Encrypt and compatible with all ACME v2 CAs. Download from certifytheweb.com
Cloud-Init - unofficial mirror of Ubuntu's cloud-init
acme-companion - Automated ACME SSL certificate generation for nginx-proxy
dehydrated-bigip-ansible - Ansible based hooks for dehydrated to enable ACME certificate automation for F5 BIG-IP systems
glewlwyd - Experimental Single Sign On server, OAuth2, Openid Connect, multiple factor authentication with, HOTP/TOTP, FIDO2, TLS Certificates, etc. extensible via plugins
SaltStack - Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here: