running the script should not require root. about certbot HOT 6 CLOSED

incentive # 2: it's also very inconvenient for testing the script.

from certbot.

@dnozay ptal #63 (comment) and #63 (comment)

@jdkasten, this probably needs a FAQ entry :)

from certbot.

Thanks @kuba! I will figure out a good place to put this information.

from certbot.

You wouldn't need root if you have sudo access, or if the server is already configured to pickup keys from a specified location you have access to.

@kuba, @schoen,

1. is there anything similar to wildcard certs supported?
2. why is port 443 necessary? arguably, if i'm using puppet, i know what the host key is going to be, then maybe a challenge can be arranged based on that fact.
3. can we isolate the parts that require root and use sudo instead, or use something like fabric and have a target host / target host(s).

from certbot.

Hi Damien!

Thanks for your interest in the project! I will do my best to answer your questions.

Yes, you just need superuser access to perform the domain validation challenges. The goal of the protocol is to prove complete authority over the webserver, port 443, the standard port for HTTPS.

The current challenges are defined at the end of this document. The client must be able to satisfy them in order to receive a DV certificate.

1. We will be supporting domain validation (DV) certificates with subject alternative names. In reference to wildcard certificates see #66.
2. We need to verify authoritative control over the port used for standard HTTPS communication. This is a protected port, and represents the service we are currently trying to validate. These challenges prove the exact level of control as the authorization issued by the certificate. The "client" has complete and arbitrary control over the port.
   I saw you posted a question on the acme-spec document about having knowledge of the ssh host key (which is the correct place for such a question). I would be hesitant to implement such a challenge. The only benefits I see is if you allowed the challenge to be off-path via a remote proof-of-possession challenge (which would not be sufficient for issuance and would allow attackers who compromised the key to remotely obtain certificates). However, discussion should be on the protocol spec. In general, ACME challenges are designed to be strictly stronger than the status quo. I believe a host key challenge would involve additional and unnecessary attack vectors. See #47 for more info.
3. Running the script is the same level of privilege required to make configuration changes to existing webservers and restart the servers (to implement the changes). If you would like to extend the client to support mass system administration, that would be excellent! Currently, we are still locking down the functionality of the core components and abstracting out the API.

Hopefully, I answered your questions. If you have any other client questions, feel free to ask.

from certbot.

This conversation has transitioned to other forums.

from certbot.