Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: $le_path/certbot certonly --standalone --preferred-challenges http --agree-tos --renew-by-default --config $config_file -d $domain --non-interactive --http-01-port $http_01_port
It produced this output: certs are renewed but linking to old
My web server is (include version): haproxy
The operating system my web server runs on is (include version): debian 10
My hosting provider, if applicable, is: virtual machine
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): none
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0
I have a script which renews certs automatically on my HAPROXY server.
It gives output after each renew:
"Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/www.example.com/fullchain.pem and /etc/letsencrypt/live/www.example.com/privkey.pem
But when I go to folder “/etc/letsencrypt/live/www.example.com” and list files “ls -la” there is a sumbolic links to old versions: “cert.pem -> …/…/archive/www.example.com/cert3.pem”
Why there are symbolic links, why it can’t work without them? and how can I fix this?
I have a script which should renew multiple certs and combine them to pem for haproxy.
I took the script from here and edited it a bit: https://gist.github.com/T0MM0R/8503d077c5e30030fe41af514bbde9c9
It clearly has some problems, but still those errors in the script should not affect the fact that there are these symbolic links. here is one output: (and the log below shows that certbot is saving to archive folder)
date: invalid date ‘9:48:07 2020 GMT’
/etc/haproxy/le-renew-haproxy.sh: line 27: bc: command not found
Checking expiration date for www.example.com…
/etc/haproxy/le-renew-haproxy.sh: line 31: [: : integer expression expected
The certificate for www.example.com is about to expire soon. Starting Let’s Encrypt (HAProxy:54321) renewal script…
The standalone specific supported challenges flag is deprecated. Please use the --preferred-challenges flag instead.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.example.com/privkey.pem
Your cert will expire on 2020-05-30. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew all of your certificates, run
“certbot renew”
If you like Certbot, please consider supporting our work by:
Creating /etc/haproxy/certs/www.example.com.pem with latest certs…
Reloading haproxy
This is from the letsencrypt.log file:
2020-03-01 10:55:58,361:DEBUG:acme.client:Storing nonce: 0001iBvbIYSv5KxsDUBeolAH4Q-vTYNWhfVN-ahmomcik
2020-03-01 10:55:58,367:DEBUG:certbot.storage:Writing new private key to /etc/letsencrypt/archive/www.example.com/privkey2.pem.
2020-03-01 10:55:58,368:DEBUG:certbot.storage:Writing certificate to /etc/letsencrypt/archive/www.example.com/cert2.pem.
2020-03-01 10:55:58,368:DEBUG:certbot.storage:Writing chain to /etc/letsencrypt/archive/www.example.com/chain2.pem.
2020-03-01 10:55:58,368:DEBUG:certbot.storage:Writing full chain to /etc/letsencrypt/archive/www.example.com/fullchain2.pem.
2020-03-01 10:55:58,387:DEBUG:certbot.plugins.selection:Requested authenticator standalone and installer <certbot.cli._Default object at 0x7fa96207530>
2020-03-01 10:55:58,389:DEBUG:certbot.cli:Var http01_port=54321 (set by user).
2020-03-01 10:55:58,389:DEBUG:certbot.cli:Var rsa_key_size=4096 (set by user).
2020-03-01 10:55:58,391:DEBUG:certbot.cli:Var pref_challs=http (set by user).
2020-03-01 10:55:58,396:DEBUG:certbot.cli:Var authenticator=standalone (set by user).
2020-03-01 10:55:58,399:DEBUG:certbot.cli:Var standalone_supported_challenges=http-01 (set by user).
2020-03-01 10:55:58,400:DEBUG:certbot.storage:Writing new config /etc/letsencrypt/renewal/www.example.com.conf.new.
2020-03-01 10:55:58,402:DEBUG:certbot.reporter:Reporting to user: Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.example.com/privkey.pem
Your cert will expire on 2020-05-30. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew all of your certificates, run “certbot renew”
2020-03-01 10:55:58,402:DEBUG:certbot.reporter:Reporting to user: If you like Certbot, please consider supporting our work by:
also there is a weird issue with the “README” file, it sometimes appears in the haproxy/certs folder and causes haproxy to not to reload without errors. So I have to manually delete it.
These symlinks are used by Certbot to keep track of the successive versions of a certificate. The idea is that Certbot will always point the symlink in live to the most recent version in archive, so that configuration files can point at live. Do you have an example that shows that this is not happening, or were you just concerned that the symlinks are present at all?
(If you modify the symlinks, Certbot will get confused and may fail to renew your certificates properly.)
Hi,
I think I fixed this, symlinks were correctly. My bad, I am just a rookie.
The problem was in that renewal script, and also that my debian didn’t have “bc” installed…