Acme.sh: CSR Issuing

[fpeterson194]

Hi All,

@Neilpang thanks very much for your work here. I used your agent and it works very good :)

I need to issue a certificate with an CSR with the following command:
acme.sh --signcsr --csr /path/to/mycsr.csr -w /path/to/webroot/ --issue --standalone --tls

I have a question here: Do I need to pass by parameter the Private Key or not? If I don´t pass it as parameter how does the CA validate that I own a domain? I´m using standalone function.

As far as I understand, the challenge/response between the CA and the applicant (me in this case) need to cipher with the public Key and the agent will need to de-cipher with the private one to validate the domain. Am I missing something?

Thanks in advance!

[Neilpang]

Do I need to pass by parameter the Private Key or not?

NO, you don't need to give the private key. That is why we have a --signcsr command here. It's designed to work without domain private key. Imaging you are a ssl provider, your customer only gives you his CSR, he would never give you his private key.

The letsencrypt CA only need your account key, not the domain key.

BTW, are you sure you know why to use -w, --standalone and --tls at the same time ?

See our wiki: https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert

And: https://github.com/Neilpang/acme.sh/wiki/Issue-a-cert-from-existing-CSR

[fpeterson194]

@Neilpang thanks very much for your response!
Ok, I see your point. If I signed the CSR with my privKey not to use it in the ACME protocol and given the fact that the PublicKey is inside the CSR, how does the CA decrypt the request? Does the agent send the signedCSR + the public key separately?

To add more, in the ACMESharp implementation (windows) https://github.com/ebekker/ACMESharp/issues/221 it requires the PrivKey, but I think it is only to store it in the vault the implementation provides, but not sure.

Af far as I understand:
--standalone: for request a certificate without web server. It uses netcat to handle the requests, correct?
--tls: To use the TLS ACME alternative to request a certificate.
-w: Is this the path to the web site itself? As I will import the certificate in other place, I don´t need this parameter, am I right?

[Neilpang]

@fpeterson194

The CA never needs your domain private key. It only needs to verify your ownership of the domain, it doesn't care what the domain key is at all.

Af far as I understand:
--standalone: for request a certificate without web server. It uses netcat to handle the requests, correct?
--tls: To use the TLS ACME alternative to request a certificate.
-w: Is this the path to the web site itself? As I will import the certificate in other place, I don´t need this parameter, am I right?

No. you are totally wrong. They are 3 different ways to verify your ownership of the domain. You don't need to use all 3 of them for the same domain.

read the wiki carefully: read the wiki carefully: read the wiki carefully:
https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert
And: https://github.com/Neilpang/acme.sh/wiki/Issue-a-cert-from-existing-CSR

[fpeterson194]

@Neilpang thanks for your prompt response!
Maybe I didn´t explain it with the proper words, but I know the CA does not need the priv Key and obviously the agent will not send it. PrivKey is secret and you need to keep it secure.
In a nutshell, my question is more protocol oriented, I was wondering if the CA encrypts the requests with your Public Key or not. If yes, the agent would need the privateKey to decrypt the challenge and the re-encrypt to respond to the CA the challenge, do you see my point? For what you already mentioned, this seems not to be correct. But I want to understand how it works. Make sense?

I read the links:
1) -w: Webroot mode.
2) ---standalone. To use without web server, that is why standalone, this uses the http validation, right?
3) --tls: If I want to request a certificate without webserver configured but with tls validation, I just put --tls (it is not necessary to put --standalone plus --tls). Am I right now?

Thanks!

[Neilpang]

I was wondering if the CA encrypts the requests with your Public Key or not

No, the CA never encrypts anything. The connection to the CA is over https, so it's already encrypted.
The acme client only signs the request with the account key, not the domain key. So, domain private key is not needed.

-w: if the domain is already bind to a website running, just specify the webroot folder to validate your ownership of the domain.

or

--standalone: if you don't have web server running, you can use standalone mode. we use nc to run a temp webserver on tcp 80 port to response to the CA.

or

--tls: it's similar to the --standalone mode, but running a https server on tcp 443 to verify your ownership.

[Neilpang]

So, you just need to use one of the 3 modes for one domain, you don't need to use all 3 of them, unless you have 3 domains in the same cert and you want to use hybrid mode.

[fpeterson194]

@Neilpang excellent explanation! Now makes sense for me, the acme client uses the account key to sign not the domain key, perfect, make sense now :)

About the -w. This is when you already have a web server running and the port already binded to it, so the client even though the port is binded it can use it to perform the challenge, am I right?

[Neilpang]

so the client even though the port is binded it can use it to perform the challenge, am I right?

If you use -w mode, that means you already have a webserver running on 80 port. the acme client won't try to bind to that 80 port again. It just write the validation file to the webroot folder. When the CA requests to the webroot, it will get the validation file and pass the validation.

[Neilpang]

@fpeterson194

[fpeterson194]

@Neilpang thanks very much for your clarifications!! Now, it is crystal clear for me :)