SSL/TLS certificates will last 47 days max by 2029

submitted by

www.theregister.com/2025/04/14/ssl_tls_certific…

5
17

Log in to comment

5 Comments

That's interesting and cool.

Let's encrypt is an exceptional success story.


Hopefully the fact that OTF (and by extension LetsEncrypt) just lost a ton of funding doesn't turn this into a giant clusterfuck.


Automating the ssl certificate for my django project in docker is still one of my greatest feat, So, I can understand the frustration of managing multiple services.

Tell me more please

Hey, I was busy with some issues, so I wasn't able to be active in online spaces. I'm sharing the final tailored draft I documented for my personal use. Please let me know if something doesn't seem to be on point or needs explanation.

I will also attach the workflow image if possible.


for dev and prod we have different configuration which is used depending on the environment.

for dev

```nginx
#for dev
server {
listen 80;
server_name localhost; client_max_body_size 10M;

location /.well-known/acme-challenge/ {
    root /vol/www/;
} 

location / {
    proxy_pass http://django:8000/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

location /static/ {
    alias /app/static/;
}

location /media/ {
    alias /app/media/;
}

}
```

for prod we use configuration
```nginx
#for prod
server{
listen 80;
server_name _;

return 444;

}

server{
listen 443;
server_name _;

ssl_certificate /etc/letsencrypt/live/${DOMAIN}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/${DOMAIN}/privkey.pem;    

return 444;

}

server {
listen 80;
server_name ${DOMAIN} www.${DOMAIN}; client_max_body_size 10M;

location /.well-known/acme-challenge/ {
    root /vol/www/;
}   

location / {
    return 301 https://$host$request_uri;
}

}

server {
listen 443 ssl;
server_name ${DOMAIN} www.${DOMAIN}; client_max_body_size 10M;

ssl_certificate /etc/letsencrypt/live/${DOMAIN}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/${DOMAIN}/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
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;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Referrer-Policy "no-referrer";

location / {
    proxy_pass http://django:8000/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    add_header P3P 'CP=""';
    proxy_redirect off;
}

location /static/ {
    alias /app/static/;
}

location /media/ {
    alias /app/media/;
}

}
```

So what's the issue ?


Issues arises when we are deploying the project to production and server(nginx) is booting for the first time inside the docker. We can't use prod configuration as it require updating some variables and path such as ssl(TLS) cert path, which isn't the big problem as such because we can do it anyway and refresh the nginx once we are done with acme challenges but that would be just quick fix than doing it right way and will be creating too many loose ends.

fixing it


With some testing and looking here and there came up with

  1. While booting/creating nginx container use nginx/manager.sh which verify if certificate is present, if not load the nginx.dev.conf.
  2. Nginx container is up and running.
  3. Certbot container is created and managed by certbot-init.sh

```bash
#!/bin/sh

set -e

echo "Getting certificate..."

certbot certonly
--webroot
--webroot-path "/vol/www/"
-d "$DOMAIN"
--email $EMAIL
--rsa-key-size 4096
--agree-tos
--noninteractive

if [ $? -ne 0 ]; then
echo "Certbot encountered an error. Exiting."
exit 1
fi

#for copying the certificate and configuration to the volume
if [ -f "/etc/letsencrypt/live/${DOMAIN}/fullchain.pem" ]; then
echo "SSL cert exists, enabling HTTPS..."
envsubst '${DOMAIN}' < /etc/nginx/nginx.prod.conf > /etc/nginx/conf.d/default.conf
else
echo "Certbot unable to get SSL cert,server HTTP only..."
fi

echo "Setting up auto-renewal..."
apk add --no-cache dcron
echo "0 12 * * * certbot renew --quiet" | crontab -
crond -f
```

  1. and acme challenges is completed.
  2. New certificate is placed at "/etc/letsencrypt/live/${DOMAIN}/fullchain.pem".
  3. Production conf( nginx.prod.conf ) is loaded as
  4. Meanwhile this whole operation is monitored by a script which is setup during the creation of nginx container. This script make sure that nginx refresh when ever there is changes in the configuration file.

bash inotifywait -m -r -e modify,move,close_write /etc/nginx/conf.d/default.conf /etc/letsencrypt | while read path action file; do echo "Change detected in $file: $action" echo "Reloading nginx!" nginx -s reload done &

Auto-renew the certificate


Auto-renew is easy to setup we just mash up a cron job and a certification change detection script along with nginx/manager.sh and certbot-init.sh .

nginx/manager.sh

bash inotifywait -m -r -e modify,move,close_write /etc/nginx/conf.d/default.conf /etc/letsencrypt | #--> '/etc/letsencrypt' for certificate renew while read path action file; do echo "Change detected in $file: $action" echo "Reloading nginx!" nginx -s reload done &

certbot-init.sh

bash echo "Setting up auto-renewal..." apk add --no-cache dcron echo "0 12 * * * certbot renew --quiet" | crontab - crond -f




Comments from other communities

Are compromised private keys that big of a problem to cause all this headache?

Geez.

This will keep getting shorter until it turns into a calculus problem.

You won't even get a certificate, just a token from some SSL token warehouse. Why should I trust it? Because some random company says so!

Lol, wouldn't put it past them. Like TLS session keys we have now, but every session key has to be requested from the SSL token warehouse.



There are lots of companies and vendors that don't automate cert renewal. They are all going to be forced into automation with this change.

The concern is that a compromised device could leak a cert that is then used for attacks.

The concern is that a compromised device could leak a cert that is then used for attacks.

Yeah. Everyone gets that.

The question was whether this is worth the damage seen in the wild thus far.

And I'm curious too: show me how it's not some market trying to FUD and FOMO us into yet more rigamarole for the sake of security and also sales. Security is rich in "better safe than sorry" snake oil.

Are we trading certs lasting 'too' long, a problem that may not yet exist, for a much harder problem of properly securing the renewal chain?

Are we going to have very secure keys but on code with 181 sploits in the supply chain, that we neither know about nor can fix because of rug-pulled compatibility if we did?

You can still use self signed certs. You just can't use it on the public internet.

You can, but it might scare off some of your audience.






Let's encrypt is about to get even more market share. Suddenly companies will have even less reasons to pay money for a cert.


And I'm over here with a internal only SSL cert that's good for 1000 years


We could be heading into daily (or hourly) cert auto-renewals. Clients will have to catch up. But one day, can see it all being hands-free.


God I hate this, dropping it to one year is fine but a month and a half? Fuck that shit.

Id you can use acme/cert boy it's fine. But some of us have to manage decades old equipment that doesn't support it and no we can't just put a reverse proxy in front we tried.

Complaining about job security, unbelievable... 🙃



What a pain in the ass. I will probably just disable HTTPS and use a VPN or SSH tunnel for my stuff then.

This raises a good point. The path of least resistant typically becomes the norm.


Jesus, dude… ACME is not hard to set up.

Setting up a VPN is far far more complex



Just use auto-renewal tools Duh.



Insert image