Removing hard-coded file name requirements

For reasons which are WAY too stupid to get in to here, we’d really like to have certbot be able to use certificate and private key file names that don’t end with the .pem extension. Unfortunately, this seems to be a hard-coded requirement (see
https://github.com/certbot/certbot/blob/master/certbot/storage.py#L587, https://github.com/certbot/certbot/blob/master/certbot/storage.py#L695, https://github.com/certbot/certbot/blob/master/certbot/storage.py#L744, etc.).

Can this be removed? Or perhaps be expanded to include other extensions such as .crt or .key?

1 Like

A small --deploy-hook script might be sufficient to copy the files you need elsewhere with different extensions.

I guess I’ll explain a bit more.

We received a public records request for EVERY .pem file we have. Including our private keys. If we end up having to release them, we’ll revoke all of the corresponding certs and reissue them with new keys. Of course, another records request could be made and we’d have to repeat this process forever.

Note that if a .pem file is created – even temporarily – we have to retain it and potentially disclose it. Don’t even ask what happens if the .pem file is a symlink to another file name. Is the contents of a symlink “public record” the contents of the file it points to, the name of the file it points to, or both? WHO KNOWS!

I can’t believe we have to think about this, but here we are.

1 Like

Wow. That is absolutely horrifying.

I do not think there’s a way to solve your problem with Certbot, besides maybe using the (non-automated) --csr mode of operation?

Incidentally, acme.sh does not name any of its files with the .pem, so maybe using an alternate Let’s Encrypt client like that one could be the way out.

4 Likes

It’s hard for me to understand how the filename determines whether or not the content is releasable under a public records law. (I understand that it might determine whether or not the content is within the scope of an individual public records request.) If you call the private key files .key, couldn’t the requestor similarly request all “key files”? All files “containing PKCS#1 data”? All “ASN.1 PKI-related files”?

If you can send me a private message and let me know which agency and jurisdiction this is, I can also see if I can try to get you in touch with any additional legal assistance on the underlying subject matter question.

(I also agree with @_az’s answer: the filenames in Certbot are extremely hard-coded in this regard and there is no straightforward way to permanently change them without making large changes to the Certbot code base.)

2 Likes

Hi @supersat

which country?

Looks like there is someone without enough know how a certificate works. Publishing / sharing private keys should never be required. Sounds like an error or like a “honeypot”.

1 Like

This is in the United States. There have been lawyers working on this for a while now. If we could ignore the request, we would.

1 Like

If their “loophole” is that .pem is also used for other “purposes”, then it simply needs to be clarified that these particular .pem files are not related to those uses/types/purposes.
A file extension is just text characters it doesn’t make/change the contents of the file.
Need I ask: Are these Lawyers all Idiots?

noun
Informal. an utterly foolish or senseless person.
-https://www.dictionary.com/browse/idiot#

This is more of a legal question than a technical question, since any subpoena could be widened to encompass any sort of obfuscation you could apply. However, FOIA requests are allowed to exempt or redact specifically excluded sensitive information in every US jurisdiction I know of, so why aren’t your lawyers telling you how to redact the private keys instead?

1 Like

I wrote an ACME client, acmebot that allows full control over the generated filenames as well as the output directories for the keys and certificates.

It also does a few other things that certbot doesn’t…

1 Like