New Filenames after Renewal

Help
1

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: konzack.design (mail.konzack.design)

I ran this command: (none, it happened with auto renewal)

My web server is (include version): none, but I use the Cerificate for hMail

The operating system my web server runs on is (include version): Windows Server 2019 10.0.17763

My hosting provider, if applicable, is: Netcup

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): no, since it's not about the website.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Certbot 1.24.0

On registration of the certificate it created cert1.pem, chain1.pem, fullchain1.pem and privkey1.pem

With renewal, instead of renewing in the already existing files it created new files with the names: cert2.pem, chain2.pem, fullchain2.pem and privkey2.pem

The new files worked fine, but the old files didn't work anymore.
Is there no way to auto renew without having to update the files in hmail every 3 month?

2

You are linking to the wrong files.

Certbot keeps versioned files under /archive, and symlinks the active files into /live

You should be referencing the /live files.

Edit: See User Guide — Certbot 2.1.1 documentation "Where are my certificates?"

4 Likes
3

Hello @GloosIsBae, welcome to the Let's Encrypt community. :slightly_smiling_face:

These 3 files contain the renewed certificate, thus have to update.
(or links to them the actual certificate files)

Focus on @jvanasco reply!

1 Like
4

Side note there is a newer version of Certbot 2.1.0 Release, unless other more knowledgeable Let's Encrypt community volunteers suggest updating you shouldn't have to do anything. It is just a FYI.

5

problem is, that I can't choose shortcuts to files in hMail. It automatically takes the file path linked in the shortcut if you choose one.

6

Sounds like a defect of hMail.
I found hMail has its own forum that maybe of use hMailServer forum - Index page

1 Like
7

As @Bruce5051 said, that sounds like a defect in hMail and you should raise an issue with them.

Certbot accepts a --deploy-hook argument that only runs on successful renewal. You could use that to write a script that copies the file contents into a new file specifically for hmail's use, overwriting the previous contents.

The current system of version based archiving, alongside a symlink to the unversioned active certificate files, is well established and largely required throughout the current ecosystem of related applications. It does not support your usage pattern and is unlikely to change.

2 Likes
8

That said, you might be able to script copy the linked files to some other static location [that hMail can then load from].

Until they get hMail "fixed".

2 Likes
9

The issue is mostly around the symlinks strategy certbot uses for file organisation. You can use other ACME tools to achieve the same result e.g. Hmailserver and new version 5 CTW - #2 by jljtgr - Certify The Web - Support Community - So for instance export the certificate into the private key file and the fullchain file into the desired output location (with the required file names), then restart the hmail service.

3 Likes
10

deploy-hook works fine. I've put it into cli.ini and am using it to combine chain and key file. https://gist.github.com/Bachsau/9213971a085cf3f55154ccec68411df2#file-deploy-sh

11

Personally, I do not recommend adding a deploy hook to cli.ini, as it will be in effect for ALL certificates. This is of course fine if you just have a few certs all requiring that specific hook, but often this is not the case.

I recommend adding the script to the --deploy-hook option on the command line. The reconfigure subcommand is almost done and is probably included in the next release of Certbot (I hope!), which should be 1.33.0 and 2.3.0. With that subcommand it's possible to reconfigure and thus add the deploy-hook command to any existing certificate without the need to force a renewal to do so.

4 Likes
12

Normaly, if you have a way to do things, you want it to apply in all cases. Furthermore, if you change your configuration, it shall apply to existing and new certificates alike. In my eyes, including all settings in the renewal files was a bad decission in the first place, and a way to disable this would be more useful than a reconfigure command.

It is great to have the option to set specifics for any given certificate, but I'm not so happy with Certbot incorporating global settings in those specific configuration files without an explicit order to do so. Currently, settings given on the command line and in the configuration file are handled in exactly the same manner, which means they override and reset certificate specific settings. I think it would be more useful if you could have a set of defaults in a configuration file, which could be overriden by certificate specific settings, which could be overriden by the command line.

13

Not every certificate is for the same service. Some are for webservers, some are for mailservers. Your deploy hook is concatenating the private key with the cert. This is mandatory for just a few fringe services. So no, I don't agree with your statement at all.

Why? Some certs are RSA, some certs are ECDSA. Some certs use the dns-01 challenge, some certs use the webroot authenticator for the http-01 challenges. So much different combinations are possible, which should be stored per certificate.

The fact that your situation does not warrant such a configuration, does not mean other users should suffer for it.

3 Likes
14

This is probably OT here, but they wouldn't have to. If there was a configuration file that could hold defaults instead of overrides, people could still set specifics on the command line, which would then be copied to the renewal configuration file to replace the default for that single certificate.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.