How does Let's Encrypt create the private key?

Server
#11

@AliceWonder, our key generation in the client is

key = OpenSSL.crypto.PKey()
key.generate_key(OpenSSL.crypto.TYPE_RSA, bits)

OpenSSL uses /dev/urandom on the host system. We don’t think that we have expertise that would make users safer by tampering with the entropy sources for key generation instead of using OpenSSL defaults.

If users have specific requirements about entropy sources, they are definitely welcome to use daemons that seed the local kernel CSPRNG differently or modify their OpenSSL behavior to use different or additional sources. Our intuition is that nothing that we know how to do or suggest is guaranteed to make things better in this area. (If anybody thinks they have a generally-applicable improvement for key generation behavior, the OpenSSL project is a better project to propose it to.)

#12

I believe that entropy contribution is always helpful. Even if the entropy is sent by an attacker it can’t reduce the randomness of the private key generated.

So, sending entropy from the ACME server to the lets encrypt client can help in a enviroment with very low entropy and It can’t harm if the entropy was hypothetically harmful.

#13

@rme, that mechanism was suggested for the ACME protocol in the past (mostly to benefit embedded devices and perhaps some VM images that might have poor seeding), but I think it wasn’t incorporated in the version of the protocol that we use. If you’d like to advance that suggestion, I would suggest bringing it up in

because doing this would require protocol changes and support on both the client and server side.

#14

Hmm is not that what haveged does?

#15

@rugk, yes, and users are welcome to use it if they think it’s valuable.

The notion of the entropy pool “running dry” is not one that I think is well-supported by expert opinion. The problems that we’ve seen in the wild have had to do with CSPRNGs not being properly seeded in the first place, or being used before they were seeded, rather than with subsequently “running out” of entropy.

#16

Okay, just asked again, becaue you replied to @AliceWonder who exactly said that and you explained something completely different (not mentioning haveged with a single word :slight_smile: ).

#17

well I have some Idea for entropy stuff

it’s not perfect but it may help.

how about that every PC who has a microphone installed uses this as an additional source of entropy especially since microphones have tolerance and there is defferent noises everywhere, the running PC, ppl talking, whatever it should be rather hard to do something about that.

#18

Specifically what tends to happen is the builder of an OS image wants a separate key for every system that uses that image. So they put key generation in a “first boot” script but especially on a system with no hard drive the “first boot” can be an extremely predictable process giving the kernel little to no opportunity to gather real entropy which can lead to the keys being much less random than they should be.

One lesson from this is to try and avoid using keys generated on first boot. Much better to let the letsencrypt client generate a new key than to use one that was generated on first boot by your OS image.

#19

Mostly we talk about servers/VMs and possibly things like embedded devices here, because all other devices should have enough entropy as they are in daily use.
And I highly doubt that you have a microphone at your server or linked to your VM… :smiley:

#20

nah but if your server has a sound card you could put a mic to it (if it is self-managed) and it shouldnt be so hard to link your PC mic to your VM.

#21

This is not done by the LE client - it would not make sense anyway.
From the start of the VM on it collects entropy and when the LE cert is generated (so after the user entered the commands to start this and so on) this entropy is used by OpenSSL to generate the cert.

#22

I think I should mention another thing here, because it’s clearly important to know if you want to answer the question how the LE client generates this cert:

The LE client regenerates the key pair every time it renewals the certificate.

That’s especially important to know if you want to use HPKP.

#23

We have some code to eventually allow either behavior; there’s no intention to force people to change their keys if they don’t want to (although we don’t yet have a command-line flag to renew without changing private keys). It’s true that changing the key could break pinning, and that’s one reason people might not want to do it.

3 Likes
#24

that is nice… >adding for at least 20 chars<

#25

@schoen maybe one more step towards automation for HPKP would be to start with making it so that when you obtain and generate an ssl cert, key and files at /etc/letsencrypt/live/domain.com/* you also generate an optional HPKP pin text file at say /etc/letsencrypt/live/domain.com/hpkp.txt and all it contains is the the pin hash from the private key’s SPKI field. Folks then can script it themselves to whatever they need reading the /etc/letsencrypt/live/domain.com/hpkp.txt contents to form their HPKP headers for their web servers ?

It’s what I am doing for my LEMP stack’s auto vhost SSL generation for self-signed SSL http://centminmod.com/http-public-key-pinning.html and probably what I’d do once I integrate Letsencrypt and webroot authentication into my stack :slight_smile:

1 Like
#26

@eva2000, I agree something like that would be pretty useful. We’ve had some preliminary discussions about how to implement HPKP or to help people do it themselves; one idea is to have a mode where the installer actually modifies the server configuration to set the header (presumably this wouldn’t be a default because it’s so dangerous!), but indeed some people might just want to get the information about what the header would be, in the right format. Your approach is one good one; another idea is just to have a verb or option that prints this interactively (like show-hpkp-instructions or --show-hpkp-instructions or --pinning-instructions?)

Do you know if we have an existing GitHub issue about this? If not, maybe we can open one (like “HPKP assistance”).

2 Likes
#27

@schoen ah yes you could generate text files separately for 3 formats

  • hashed pin only text file
  • apache formatted hashed pin header
  • nginx formatted hashed pin header

folks could pick which they need to use themselves - as HPKP is dangerous probably something end user wants to implement themselves. Having instructions / help could also serve to inform and outline what HPKP is and dangers and how to implement.

As to issue tracker closest is https://github.com/letsencrypt/letsencrypt/issues/729 - probably needs a separate label of it’s own for HPKP for related issues ?

#28

Maybe I should ask about this in the forum thread about HPKP, where it’s much more on-topic!

1 Like
#29

yeah if you can move the posts :slight_smile:

#30

Another aspect of “how LE creates the keys”… This time it’s about different keys, but it’s still good to know:

1 Like