Well, that looks terrible. What service is responsible for such unlogical system?
3 Likes
The service responsible for this mess is a custom written one that creates config_dir and work_dir relative a path created after its current version that is 3.3...
Each time a new version is deployed, the old path may or may not exist anymore
Should I ask... why?
2 Likes
And the new version doesn't migrate the certs from the old version location to the new version location I'm guessing? That would be a very logical (mandatory even) feature of such a strange implementation if you'd ask me.
And this too. It feels very strange for such a specific versionated setup..
3 Likes
If you must can't you just recreate those "old" folders to allow the cert renewal to continue as is. Then develop a new script to copy fresh certs to the "new" location?
That is far from ideal but because you mentioned "hundreds" of certs this might offer a migration path as you develop a stable solution.
2 Likes
And then fix the conf files with awk magic for this new stable location right, before trying a renewal ?
If those 3.3.0 folders have already been renamed then can't you just restore them from backup? And then the cert renewal would continue as before.
I see your webroot-path in the renewal config is a static folder so looks like your server should know where that is regardless of the current app folder being 3.3.0 or 4.0.0 or whatever. I am guessing but looks likely.
You could test that assumption and idea by running one renew like this
sudo certbot renew --dry-run --cert-name h9qkct2hr8.qa.egnyte-appliance.com ... (other options)
The (other options) in that command are whatever you need for ccnfig-dir or any other overrides. You would point those at your 3.3.0 as you have been.
If that all works you then develop a way to copy the cert files you need (usually just fullchain.pem and privkey.pem) from the 3.3.0 folders to the new location. And then work on a more permanent solution later.
You have a poorly constructed system of some scale. There are tradeoffs in all options. Really all we can do is suggest ideas and inform some technical details of Certbot. Only you have the full picture of your system and how you want to manage it. There are often many good ways to manage such a problem.
You may want to consider hiring someone with specialized expertise. If @schoen is available he could work you through it. He used to be on the Certbot dev team.
2 Likes
Thanks for this suggestion @MikeMcQ
When you said this
The (other options) in that command are whatever you need for config-dir or any other overrides. You would point those at your 3.3.0 as you have been.
I wanted to understand, there is config_dir parameter in renewal.conf and same option is specified on certbot command line. So, which one will certbot look at while trying to renew the certificate. Should both be the same ?
1 Like
Command line takes precedence
If they are not the command line value will update the conf file if the cert is renewed. I don't remember if that is updated with --dry-run. Possibly not.
2 Likes
Command line takes precedence
That would mean, if the service places the certificates at new path /opt/certservice/4.0.0... and issue renew with --config-dir pointing to this new location, renew would find the certificates and ignore the broken path specified in renewal.conf ?
I am hesitant to say more. You need to test and evaluate your (peculiar) infrastructure.
I do not have full visibility to your system. There may be other complications.
Take backups and test with individual certs (using --cert-name X) until you are sure you have something viable.
3 Likes
That implies that a new cert was issued.
There would be no broken paths in the renewal config once a new cert has been issued.
The new issuance would overwrite the renewal config file with the latest information.
2 Likes
That implies that a new cert was issued.
I meant if the service places old certs at this new path /opt/certservice/4.0.0 and then calls renewal with --config-dir pointing to this new path while renewal.conf still points to the old broken path
Then it depends on the command line used by the service.
Anything provided on the command line will overwrite conflicting settings in the renewal config file.
But at this point, it shouldn't even bother trying to renew something so broken - it should just issue a new [duplicate] cert.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.