create-fullchain-privkey-pem-for-X breaks cleanup

[OrangeDog]

Because this formula creates an extra file under live, the certbot delete command cannot cleanup properly, leaving things in an invalid state.

Attempting to create another certificate for the same domain gives a "live directory exists" error.

[boltronics]

I'm curious; why does create-fullchain-privkey-pem-for even exist?

• Nginx has the separate ssl_certificate and ssl_certificate_key directives.
• Apache httpd's mod_ssl has the separate SSLCertificateFile, SSLCertificateKeyFile and SSLCertificateChainFile directives.
• It could be useful for HAproxy, but HAproxy (despite what the documentation suggests) expects the certificates to be bundled in a different order, possibly leaving someone attempting to use this with a headache.

What software is it for? The intended use case should probably be documented somewhere.

[myii]

@boltronics While I haven't used this formula to do it, the create-fullchain-privkey-pem-for state runs the commands to provide a single .pem to use with Pound. In fact, following through from the blame, the original author of that section explains just that: #12 (comment).

[boltronics]

Thanks. I just looked over git history, not GitHub PR history. It should be documented.

Is Pound still a thing? It looks dead to me, but HAProxy is quite popular, so the decisions around this could use a review.

I don't think it's a great idea for there to be important secrets duplicated on server using this formula for no reason. Probably a pillar key could be used by the user to indicate if it should be deployed.

[myii]

Thanks. I just looked over git history, not GitHub PR history. It should be documented.

Absolutely.

Is Pound still a thing? It looks dead to me, but HAProxy is quite popular, so the decisions around this could use a review.

Yes, it's still there (I still use it, not that that's important). It disappeared for a while in Debian/Ubuntu (around bionic) but has made a comeback after certain updates were made:

• https://launchpad.net/ubuntu/+source/pound/+publishinghistory

I don't think it's a great idea for there to be important secrets duplicated on server using this formula for no reason. Probably a pillar key could be used by the user to indicate if it should be deployed.

Ideally, opt-in. However, opt-out would avoid a breaking change for those dependent on this.