can it be made possible to just give LE a pre-used pubkey rather than a full CSR because most things you are asked for are ignored anyway and it’s easier to just enter the domains in the psudo-gui or with the command line params, especially when automizing the stuff, because that is easier to change.
the only thing LE uses are most probably the CN and the SAN…
Remember that a CSR not just carries the public key and some fields which are usually ignored for DV certificates, but also a signature. This signature proves that this request and all accompanied information was actually entered by the entity who owns the key and was not changed on the way to the signing CA.
And, using CSRs is the standard. I wouldn’t go away from that just to save you one line of “openssl req”. Remember that you can create a configuration file which is then used by “openssl req” instead of an interactive fetching.
but anyone can take a csr already used and creating a cert without having the accompanying privkey is kinda useless, coz what do you wanna do with that? depending on how the CA handles it, startssl for example literally ignroes everything and just takes the pubkey and then it’s completely useless…
but that thing with the config sounds intresting, but it would be rather epic if we could use an “empty” CSR and get asked for the domains in the pseudo-gui because that makes it easier to use since I actually never saw the req asking for any SAN stuff, but I usually manage my keys and certs using xca (nice key/cert management client for windows using an encrypted db and stuff and even there adding the sans is a slightly annoying process), while the LE pseudo-gui with the “give me all domains with comma”-approach is a lot better
It’s about the full chain between the one who wants a certificate to the CA signing and filling the CRT with proper data, back to himself. The idea is/was, that the fields in the CSR are honored in a WYRIWYG fashion (what you request is what you get) which is obviously not honored for DV certs, for a reason. Without the signature on the CSR, a MITM could alter your request on the way to the CA, and when you get back the CRT and find out it’s broken, it will be quite some effort (and money) to revoke that certificate and get a new one. Remember that the CSR/CRT PKCS flow was meant to be exchanged over fully untrusted communication channels.
but I think it’s weird that some CAs espeically startssl literally ignore everything and let you enter a domain name later, because you can use a CSR you already grabbed and use it for ANYTHING which makes the stuff rather funny
I wonder why CAs are sometimes so different even for just DV.
but can you explain me the stuff about the config (so I dont always have to enter something for all the fields which is plain annyoing if they are ignored anyway) and especially how to make a SAN CSR in openSSL? as I said I am not sure whether I saw san when using openssl req
or does it ASK for san interactively? I dont need a oneliner with all SAN targets I rather have it asking me for each domain, which is easier to manage since I dont automate anyway.
[quote=“ecdsa-chacha20, post:8, topic:3061”]
and then just refer to it via -config my-SAN.cnf.
[/quote]Isn’t it easier to get SAN via env vars?
It might be empty for a “regular” (non UC) cert.
@My1, you don’t have to change them permanently; you can just change them, perhaps, for a single interactive session or script. That might be simpler than creating a config file.
well is there a way to let it just ask me (similar to all the other stuff that is usually asked), and how does the value has to look, just comma seperated domains names? I dont think it’s that easy.
and how do I tell it what env to use?
I think this is a good idea. It is rather complicated to generate a CSR with SANs, and the letsencrypt client already knows how to do so. It would be nice to have a mode where the client could generate a proper CSR given a public and private keypair, plus a set of names.
I’d say rather a mode that outputs the correct openSSL command for that because then we get the problem that the clien has access to the private key (no matter what it does with it) rendering the benefits of a CSR essentially useless.