Use existing private key?


#1

Hello, while I love let’s encrypt philosophically I haven’t used it before for three reasons:

A) Normally I prefer ecdsa certs and it seems let’s encrypt doesn’t do that (yet)
B) I don’t like the idea of an automatic script that connects to external resources modifying a daemon configuration.
C) I don’t like 3 month certs, partly because I use DNSSEC and DANE and prefer to only update the DNS record associated with the 443 port when I do my yearly domain renewal and tls cert renewal.

However for a current project, I want to try Let’s Encrypt.

I’ll use 2048 (or 3072 if allowed) RSA for A - I use 3072 self-signed for mail servers.
For B - it looks like certbot has a certonly option that lets me run it manually and manually make the changes as needed.
For C though - the way DANE works, you preload the new fingerprint in DNS about a day or so before putting the key/cert into service (three times the tlsa TTL but a day is way more than that)

I can do that with Let’s Encrypt if I can generate the private key myself once a year, create the DANE fingerprint from the private key, and then tell certbot to fetch a signed cert for that generated private key.

Is that possible? I can script creation of my own CSR if needed. But I need to know that certbot doesn’t mind me specifying the private key I want it to fetch a signed cert for.

That would let me keep the same private key when generating new cert every 3 months so I only have to rotate the DANE fingerprint once a year, which is my preference.

Is there an option to certbot to specify the private key to used? (and does 3072 RSA work? okay of it doesn’t)


#2

acmetool is one substitute for Certbot that can do EC certificate private keys, supports certificate private key re-use, and will not alter your server configuration.

Based on your expressed views (which I share) I believe that changing clients may be the best way for you to go.


#3

Let’s Encrypt can issue ECDSA (P-256 or P-384) certificates, but the current intermediates and roots are RSA. ECDSA intermediates and roots are on the to-do list.

3072 is allowed. I think the maximum is 4096? 2048-bit RSA is not likely to get broken any time soon, though.

Yes. Well, technically, there’s an option to specify the CSR to use. However, Certbot current’y doesn’t support automatic renewal with custom CSRs, so the usability is worse, and you may be happier with a different client. :slightly_frowning_face:

Related thread:


#4

If there’s an option to specify the CSR to use I’m golden - that’s what I already do with commercial CAs - I have shell script that generates the private key and the CSR.

So for Let’s Encrypt with certbot I can probably just do the same thing but then manually run certbot to fetch the new cert every 8 weeks or so (I don’t like automated scripts that modify daemon configuration. I just don’t like them)

2048 isn’t likely to be broken soon - but that assumes the pRNG that generates it doesn’t have an inherent weakness in the generation that isn’t yet known to the masses. Look how long it took for the Debian “weak key” bug in OpenSSL to be discovered. I’m sure some people knew about it before it was discovered.


#5

Exactly. You’d just repeat the command used to create the certificate the first time, including the --csr option and your CSR, and it would dump the certificate in the current directory.

Usually people are unhappy to hear that, but if you don’t want to use automatic renewal anyway, I guess it’s fine.

Larger numbers weren’t safe either though.


#6

Some more information on this topic in a recent thread:


#7

I’ve been successful issuing RSA and ECC certs with specified private.key and CSR using LE64


#8

No they weren’t, but the point is that there can be bugs that allow cracking a key to take less than time required for brute force. Going a little larger than minimum may help in those cases. Or going ECDSA, which from another reply looks like might be possible now, and is nicer to lower power devices like phones than fat RSA certs are.

Anyway I think I have it all figured out now, a bash script that does everything I need re-using the old PVT key unless it is old and then generating a fresh one when it is getting close to a year in age.

Reading up on the certbot now, it seems the CSR option either isn’t documented or the certbot in EPEL doesn’t have it because certbot -h doesn’t show it.


#9

It should be shown when certain options are passed, like “certbot -h certonly” or “certbot -h all”.


#10

Okay everything with my script seemed to work, but this interesting note:

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /home/alice/0001_chain.pem
    Your cert will expire on 2018-07-22. 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”

Is there an option to set the name of that file when it is created? Everything else I have generated exactly the way I want it (putting keys / certs in the /etc/pki/tls structure I use)

I can move that to where I want it, but I would like to update things so next time I don’t have to. Next time being in July.


#11

This gist has the script I used, except I used actual country / state / city / e-mail when generating CSR.


#12

certbot-auto -h renew
shows:
--cert-name CERTNAME
Certificate name to apply. This name is used by Certbot for housekeeping and in file paths; it doesn’t affect the content of the certificate itself. To see certificate names, run ‘certbot certificates’. When creating a new certificate, specifies the new certificate’s name. (default: the first provided domain or the name of an existing certificate on your system for the same domains)

You could test CERTNAME as:
“my.file.name”
and even as:
“/my.location/my.file.name”
and let us know which ones work.


#13

@rg305 That doesn’t apply when using the --csr option. The --cert-name option is used to set the lineage name, i.e., the characters you’ll get in /etc/letsencrypt/live/ and in the renewal configuration file. But those files aren’t used at all when using --csr, including the renewal command you’re mentioning. That doesn’t float either, as there won’t be a renewal file generated.

However, these options seem to be especially created for the --csr option:

paths:
Flags for changing execution paths & servers

–cert-path CERT_PATH
Path to where certificate is saved (with auth --csr),
installed from, or revoked. (default: None)
–key-path KEY_PATH Path to private key for certificate installation or
revocation (if account key is missing) (default: None)
–fullchain-path FULLCHAIN_PATH
Accompanying path to a full certificate chain
(certificate plus chain). (default: None)
–chain-path CHAIN_PATH
Accompanying path to a certificate chain. (default:
None)


#14

I showed the output of:
certbot-auto -h renew
simply to explain where I got the “help” from.

NOTE: -h is short for --help


#15

Ah I’m guessing that’s the option I need to add next time I run the script. Thanks.


#16

Let us know which ones work.


#17

adding the --chain-path option did what I want - but there’s another pem made that is the cert with the chain in one file, some servers like that (I think dovecot does for example) which is probably what the other option does.

But anyway the gist has been updated and now does everything need, include generating the TLSA records for DANE for me.


#18

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