is the private key of the cert needed if I want to create a cert with an existing key?
I dont realyy want LE to generate one nor I want to access it.
at least at startssl you just give it the CSR in the browser and finish.
technically the CA just signs the pubkey of a CSR (pubkey plus extra info) that is signed using its own priv key.
meaning the privkey does not need to go anywhere except to the HTTPS server.
it’s not as I dont trust the LE client, but I wanna go a bit more safely on that stuff.
well when it comes to server certs and stuff keys ashouldnt leave the server or being transported at all so I generate the key o the server (that doesnt support LE) make a CSR and give the to whatever CA (including LE) that I wanna use. I am a bit paranoid about that, bit well my main key is 16384 bit soI really dont want to take any risk and even if it’s open source it’s probably not quite small and I dont have the understanding yet to check the code as a whole.
I never let anyone Generarte my keys I rather do that myself. as I said, "never transport your keys anywhere as long as it absolutely cannot be avoided.
Is there any real reason to generate a key with bit length longer than the parent certificate key? I mean, LE cert is 2048 bits, and given you have the whole chain as trusted, it makes it way simpler to go for it.
Unless you pin a specific certificate, but then why care about LE at all?
simple when an attacker attacks the chain he can impersonate me, but when he attacks the leaf then he can decrypt the actual communication between server and client (including previous ones).
also my paranoid key is just an example sincce that one is self-signed, I am just saying that I want to make the key myself, make a CSR and push that to LE without being asked for the private key.
also if the LE generates the keys then it has (theoretical) access to the keys which I REALLY dont want.
well yeah as long as you use forward secrecy true, but does everyone use that? I dont think so.
also even if the LE client makes the keys it has them and can THEORETICALLY transfer it somewhere (for example if the client is modified in whatever way, as there’s not much you can do to verify the integrity of the client, that’s why I am doing thos on a more paranoid side. most CA use the browser and a text window to get the CSR (or let you generate it, which I obviously never do) and a browser hardly can transmit your keys, espeically if those arent even on the computer used to get the cert, which is the webserver to minimize key transit.
if the client is modified in whatever way, as there's not much you can do to verify the integrity of the client
To be honest, if someone has enough access to your system to modify the client, they have access to do far more destructive things completely separate from Let's Encrypt, and there's nothing the LE client can do for you at this point. This kind of security is well outside of the scope of Let's Encrypt and it's up to you as the administrator to properly secure your systems.
I think your concerns here are a complete non-issue based on something that will literally never happen in the real world. If you're that concerned, the ACME protocol is completely open and you can authorize a Let's Encrypt signature with curl calls to the ACME server manually.
All current downloads of the client (to my knowledge) are served over TLS. If someone has managed to MITM your TLS connections without causing any errors in your clients, you have far bigger problems than a malicious LE client.
well I dunno where you get the software yet so far I only saw the source on guthub and I think we remember diginotar, or heartblled and so on, dont we? I rather go a bit paranoid rather thenexposing the key to THEOREITICAL danger.
also as I also said I key usually should be and stay on the server that’s why we even have CSRs, so nobody needs ANY kind of access to the key.
To be honest, you’re taking security to the point of ridiculousness. If you’re genuinely this concerned about security, assuming you’re not trolling, you shouldn’t even be using the internet.
Consider this: Unless you host your own server in your own premises, your host can do anything to your server and there’s nothing you can do about it. There comes a point in all security models where you have to compromise, because unless you’re fabricating your own hardware, you have to trust somebody.
As I said, the client is open-source, it doesn’t put your key anywhere but your server. If that isn’t enough, there is nothing Let’s Encrypt can do for you, write your own client.
but we cant deny the fact that heartbleed and similar stuff happened.
and as I said a key should usually never be in transit (as I said my “server” doesnt support the LE client) but be on the server and having rights set to a minimum so only the stuff needed can use it.
and I just wanted a verification whether using the “I already have a key dont make me one” method works without the private key, because it was said that it’s possible to use exisiting keys.
also about hosting the server on my own premises, well actually it isnt really a “server” as most people would call it but it certainly runs at home, so.
also I did say that even if the client is open source you have to understand it and actually I am not really fluent in most programming languages, so…
again I just wanted to know whether running LE woth a pre-generated key needs the private key or not, this is not about justification or anything
Now, what’s your concern? Just your personal setup or the generic LE setup for everybody?
You, as the server administrator, can choose the ciphers you’re offering to the clients, and if you just offer PFS-able ciphers, i.e. Diffie-Hellman key exchange with a reasonable setup (unique dhparams for DHE, or ECDHE), your setup is protected for any connected client.
Don’t be unfair. The whole certificate signing process, using CSR, was planned such that the key never ever has to leave the site’s server at all or being exposed to any 3rd party software except the initial "openssl genrsa" and subsequent "openssl req". Someone asking for this very mechanism to be applied is not asking for ridiculous security.
Consider this: someone hacks the passphrase of one of LE’s integration developers’ github account. It’s then easy for the hacker to push changes to the LE client unnoticed, voiding everyone’s security badly. I think that this scenario cannot be ruled out at all. We’re all relying on github’s security here.
I would go so far to question the generic approach, presented in the User Guide telling every user to directly fetch master from a live github repository instead of providing a closely audited clone of it from some letsencrypt.org download link.
also talking about forward secrecy I dont know whether or not all the non-http server (plus webdav, where the Win8.1 implementation doesnt even support SNI) even support that stuff, I mean forward secrecy is great but still the key should only be generated then CSR'ed and then only be used by the server.
I was wondering myself if the private key can be generated with more bits. I was using self-signed with 4096 without problem and with Lets Encrypt I have to user 2048. I will look to the csr part only.
well I am running a win7 PC with XAMPP (apache) so we have 2 things: LE doesnt support windows. there is a 3rd party LE client, which DOES support windows but well only with IIS.
yesterday I tried to start with LE (got into the beta that day) on my raspi with manual mode (nothing with CSR yet since I figure that out today, or at least I try.
even though my PC and my raspi share the same IP they are on different machines (obvious enough) and well it told me to make text123 available at example.com/.well-known/acme-challenge/url123 which I did (after figuring out how to create a dot folder in windows) and it worked splendidly I got a cert with pregenerated key for now and today I give it another shot with a CSR I make today.