Where are my certificates? (csr version)

[bmw]

When running certbot certonly and a custom CSR, we don't tell users where everything was saved. Relevant output is:

Server issued certificate; certificate written to /home/bmw/src/certbot/0000_cert.pem
Cert chain written to <fdopen>
Cert chain written to <fdopen>
Reporting to user: Congratulations! Your certificate and chain have been saved at /home/bmw/src/certbot/0001_chain.pem. Your cert will expire on 2017-05-08. 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"

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /home/bmw/src/certbot/0001_chain.pem. Your cert will expire on
   2017-05-08. 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"

Problems:

1. We should stop saying ...written to <fdopen>.
2. We should update the two sequential "Cert chain written to..." messages to differentiate between what we call chain and fullchain.
3. We shouldn't save what is usually called chain and fullchain as 0000_chain.pem and 0001_chain.pem respectively. We should call the latter file xxxx_fullchain.pem.

We may want to add/update a reporter message (which is any message under "IMPORTANT NOTES:") to tell users where their cert and chain are. This may not be necessary though as all the values they need are in the fullchain path currently given in the reporter output.

[ohemorange]

It looks like this may be a bug?

Because we have the comment # Unless we're in .csr mode and there really isn't one, which is in the else of if fullchain_path, but we do pass in cert_fullchain in _csr_obtain_cert after it's returned from le_client.save_certificate. So unless we know that le_client.save_certificate is returning None for cert_fullchain and we're just passing it forward for fun, _report_new_cert's comment is incorrect. But based on the output above, it's maybe not actually None.

[ohemorange]

Ok I think the comment is incorrect, and we always do have that fullchain path. So I don't know what's up with that.

[ohemorange]

Actually this may be important, why was that comment in there ever? The way the tests were written also makes me think that at some point we were maybe not saving a fullchain during the csr path. @pde?

[stale[bot]]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[bmw]

All of these problems still exist.

[alexzorin]

I believe we should do this as part of the current UX project, as it is affected by other CLI logging changes.

[alexzorin]

More comments from https://community.letsencrypt.org/t/file-overwrite-and-skip-for-fullchain-path-chain-path-and-cert-path/137154:

1. The sequentially numbered files depend on the state of the cwd which makes it unfriendly/unpredictable for the user. Why does Certbot do this?
2. Specifying the paths doesn't let you overwrite existing files. Worth reconsidering why.
3. What's the logic when some paths are specified and some aren't? Does it make sense to generate 0000_cert.pem if --fullchain-path was specified and --cert-path wasn't?

[ohemorange]

The sequentially numbered files depend on the state of the cwd which makes it unfriendly/unpredictable for the user. Why does Certbot do this?

Because we're reusing the same function that we use for init_save_key: util.unique_file. "Safely finds a unique file." The idea is that we don't know what's up in a common directory and we don't want to overwrite anything, so we nice a unique file. Since we made it for the key, it's not designed to be for a user to handle it.

Specifying the paths doesn't let you overwrite existing files. Worth reconsidering why.

Probably we were worried about users accidentally overwriting files. We could instead ask for confirmation, maybe.

What's the logic when some paths are specified and some aren't? Does it make sense to generate 0000_cert.pem if --fullchain-path was specified and --cert-path wasn't?

This might be a holdover from when the paradigm was "if it's not completely clear, try to guess what the user meant and err on the side of not messing up the system" rather than what we try to do now, which is "if it's not completely clear, ask the user what they meant." I don't even know where that logic is off the top of my head, but if we're doing the former, we can certainly clean that up.

[ohemorange]

Cst output was a disaster. It is no longer a disaster as of #8852., but it could still be better. We should look into changing how it outputs files for 2.0.

[github-actions[bot]]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[github-actions[bot]]

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.