Renew without implementing option?

Any chance of the option to renew, but not overwrite the as-yet-unexpired certificate?
Paypal-specific incentive for this - we have to upload new certificate to Paypal (with the previous one still remaining in their system) before we can obtain the new Certificate ID. This then has to go into our web application code for creation of the dynamically encrypted payment button.
With the current overwrite action, this results in an inevitable period of paypal downtime.
If the renew procedure could toggle between, say, two different --cert-name entries, and simply generate the certificate but leave Apache alone, we could maintain Paypal continuity, with a minute’s human intervention, when it suits us.
Or does anybody else have a way of overcoming this situation?

To clarify - we are interested in renewals performed by the Virtualmin Letsencrypt module, not the certbot cli approach - we could not produce a Paypal-acceptable certificate using the latter method, although we do use it for our mail server quite happily.

Amusingly, this was part of the original design of Certbot, which made a distinction between “renew” and “deploy” based on the idea that users would want to inspect their certificates manually before starting to use them. We ended up finding that almost no users ever wanted to do this.

There are various workarounds that are probably possible with Certbot. One is that you could edit your Apache configuration to point at a specific version of the certificate in /etc/letsencrypt/archive instead of /etc/letsencrypt/live. The old versions are always all retained in /etc/letsencrypt/archive, but we normally don’t suggest referring to them specifically because your web server won’t autoupdate to a new certificate following a renewal. :slight_smile:

If you point to a version in /etc/letsencrypt/archive, you can then manually change your Apache configuration to point to a newer one when you’re ready for it. The new versions will be visible there, so you can view them and upload them to PayPal.

Basically, we didn’t make this behavior the default (or even particularly conveniently available) because it requires so much manual intervention, and very few users see that as a benefit rather than as an inconvenience. But it looks like it would be a benefit to you in this case.

The files in /etc/letsencrypt/archive are like the ones in /etc/letsencrypt/live, but they’re numbered (with successive versions that increment on each renewal). You should always use a matching privkey, cert, and chain set because their contents correspond to each other. (Remember that at some point chain will change, although it probably typically only changes once every few years.)

Also, in the original design, “deploy” meant updating the symlinks in /etc/letsencrypt/live to point to the newest version in /etc/letsencrypt/archive. In the current implementation of Certbot, the symlinks always get updated immediately, without a significant delay between the issuance of the new certificates and the symlink update.

If you want, you or I can also create a script to change the symlinks back to point at a specified version, which might sort of simulate the old behavior.

I don’t understand what the difference between certificates produced by Virtualmin and certificates produced by Certbot is. Ultimately, they’re all certificates created by the Let’s Encrypt CA, maybe just in a different bundle format or something. If you send me examples of a “PayPal-acceptable certificate”, I can try to tell you how to produce that from Certbot…

Hi Schoen - thanks for your considered thoughts on this.
From my other thread, it looks as though the paypal issue is a non-issue, in that Paypal may accept a separate OpenSSL certificate.
My query has therefore effectively been answered.
Nevertheless, it would be helpful to learn the correct certbot cli parameters to use in case things change, so how would you like me to send you the certificate currently satisfying Paypal? I am loth to simply provide a URL here, as to overcome rate limits (within Virtualmin I hadn’t amended the configuration to include the test parameter) I had to create a certificate covering an additional domain. Next week I shall correct this.
Shall I email you the actual certificate?

Sure, I'm curious about that. Could you please send me one that PayPal accepts and one that PayPal doesn't accept? You can send them to my forum account name at eff.org.

Ok Schoen, thanks - I shall look at this tomorrow.

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