certbot / certbot

Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.
Other
31.17k stars 3.38k forks source link

v1.18.0: `--server` flag missing in pip installation #8976

Closed zyrolasting closed 2 years ago

zyrolasting commented 2 years ago

My operating system is (include version):

Ubuntu 20.04, running on an LXC

uname -a shows

Linux code 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08:47 +0100) x86_64 x86_64 x86_64 GNU/Linux

I installed Certbot with (snap, OS package manager, pip, certbot-auto, etc):

https://certbot.eff.org/lets-encrypt/pip-other

I ran this command and it produced this output:

Well, I ran three commands. Here's the session, with a couple of redactions.

$ REQUESTS_CA_BUNDLE="$(step path)/certs/root_ca.crt" certbot certonly -n --standalone -d <REDACTED> --server <REDACTED> 
Saving debug log to /var/log/letsencrypt/letsencrypt.log
You should register before running non-interactively, or provide --agree-tos and --email <email_address> flags.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

$ certbot --help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,
it will attempt to use a webserver both for obtaining and installing the
certificate. The most common SUBCOMMANDS and flags are:

obtain, install, and renew certificates:
    (default) run   Obtain & install a certificate in your current webserver
    certonly        Obtain or renew a certificate, but do not install it
    renew           Renew all previously obtained certificates that are near
expiry
    enhance         Add security enhancements to your existing configuration
   -d DOMAINS       Comma-separated list of domains to obtain a certificate for

  (the certbot apache plugin is not installed)
  --standalone      Run a standalone webserver for authentication
  (the certbot nginx plugin is not installed)
  --webroot         Place files in a server's webroot folder for authentication
  --manual          Obtain certificates interactively, or using shell script
hooks

   -n               Run non-interactively
  --test-cert       Obtain a test certificate from a staging server
  --dry-run         Test "renew" or "certonly" without saving any certificates
to disk

manage certificates:
    certificates    Display information about certificates you have from Certbot
    revoke          Revoke a certificate (supply --cert-name or --cert-path)
    delete          Delete a certificate (supply --cert-name)

manage your account:
    register        Create an ACME account
    unregister      Deactivate an ACME account
    update_account  Update an ACME account
  --agree-tos       Agree to the ACME server's Subscriber Agreement
   -m EMAIL         Email address for important account notifications

More detailed help:

  -h, --help [TOPIC]    print this message, or detailed help on a topic;
                        the available TOPICS are:

   all, automation, commands, paths, security, testing, or any of the
   subcommands or plugins (certonly, renew, install, register, nginx,
   apache, standalone, webroot, etc.)
  -h all                print a detailed help page including all topics
  --version             print the version number
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ certbot --help certonly
usage: 

  certbot certonly [options] [-d DOMAIN] [-d DOMAIN] ...

This command obtains a TLS/SSL certificate without installing it anywhere.

optional arguments:
  -h, --help            show this help message and exit
  -c CONFIG_FILE, --config CONFIG_FILE
                        path to config file (default: /etc/letsencrypt/cli.ini and
                        ~/.config/letsencrypt/cli.ini)

certonly:
  Options for modifying how a certificate is obtained

  -n, --non-interactive, --noninteractive
                        Run without ever asking for user input. This may require additional
                        command line flags; the client will try to explain which ones are
                        required if it finds one missing (default: False)
  --force-interactive   Force Certbot to be interactive even if it detects it's not being
                        run in a terminal. This flag cannot be used with the renew
                        subcommand. (default: False)
  -d DOMAIN, --domains DOMAIN, --domain DOMAIN
                        Domain names to apply. For multiple domains you can use multiple -d
                        flags or enter a comma separated list of domains as a parameter. The
                        first domain provided will be the subject CN of the certificate, and
                        all domains will be Subject Alternative Names on the certificate.
                        The first domain will also be used in some software user interfaces
                        and as the file paths for the certificate and related material
                        unless otherwise specified or you already have a certificate with
                        the same name. In the case of a name collision it will append a
                        number like 0001 to the file path name. (default: Ask)
  --eab-kid EAB_KID     Key Identifier for External Account Binding (default: None)
  --eab-hmac-key EAB_HMAC_KEY
                        HMAC key for External Account Binding (default: None)
  --cert-name CERTNAME  Certificate name to apply. This name is used by Certbot for
                        housekeeping and in file paths; it doesn't affect the content of the
                        certificate itself. To see certificate names, run 'certbot
                        certificates'. When creating a new certificate, specifies the new
                        certificate's name. (default: the first provided domain or the name
                        of an existing certificate on your system for the same domains)
  --dry-run             Perform a test run of the client, obtaining test (invalid)
                        certificates but not saving them to disk. This can currently only be
                        used with the 'certonly' and 'renew' subcommands. Note: Although
                        --dry-run tries to avoid making any persistent changes on a system,
                        it is not completely side-effect free: if used with webserver
                        authenticator plugins like apache and nginx, it makes and then
                        reverts temporary config changes in order to obtain test
                        certificates, and reloads webservers to deploy and then roll back
                        those changes. It also calls --pre-hook and --post-hook commands if
                        they are defined because they may be necessary to accurately
                        simulate renewal. --deploy-hook commands are not called. (default:
                        False)
  --keep-until-expiring, --keep, --reinstall
                        If the requested certificate matches an existing certificate, always
                        keep the existing one until it is due for renewal (for the 'run'
                        subcommand this means reinstall the existing certificate). (default:
                        Ask)
  --allow-subset-of-names
                        When performing domain validation, do not consider it a failure if
                        authorizations can not be obtained for a strict subset of the
                        requested domains. This may be useful for allowing renewals for
                        multiple domains to succeed even if some domains no longer point at
                        this system. This option cannot be used with --csr. (default: False)
  -q, --quiet           Silence all output except errors. Useful for automation via cron.
                        Implies --non-interactive. (default: False)
  --debug-challenges    After setting up challenges, wait for user input before submitting
                        to CA (default: False)
  --preferred-chain PREFERRED_CHAIN
                        Set the preferred certificate chain. If the CA offers multiple
                        certificate chains, prefer the chain whose topmost certificate was
                        issued from this Subject Common Name. If no match, the default
                        offered chain will be used. (default: None)
  --preferred-challenges PREF_CHALLS
                        A sorted, comma delimited list of the preferred challenge to use
                        during authorization with the most preferred challenge listed first
                        (Eg, "dns" or "http,dns"). Not all plugins support all challenges.
                        See https://certbot.eff.org/docs/using.html#plugins for details.
                        ACME Challenges are versioned, but if you pick "http" rather than
                        "http-01", Certbot will select the latest version automatically.
                        (default: [])
  --csr CSR             Path to a Certificate Signing Request (CSR) in DER or PEM format.
                        Currently --csr only works with the 'certonly' subcommand. (default:
                        None)
  --cert-path CERT_PATH
                        Path to where certificate is saved (with certonly --csr), installed
                        from, or revoked (default: ./cert.pem)
  --apache              Obtain and install certificates using Apache (default: False)
  --nginx               Obtain and install certificates using Nginx (default: False)
  --standalone          Obtain certificates using a "standalone" webserver. (default: False)
  --manual              Provide laborious manual instructions for obtaining a certificate
                        (default: False)
  --webroot             Obtain certificates by placing files in a webroot directory.
                        (default: False)
  --dns-cloudflare      Obtain certificates using a DNS TXT record (if you are using
                        Cloudflare for DNS). (default: False)
  --dns-cloudxns        Obtain certificates using a DNS TXT record (if you are using
                        CloudXNS for DNS). (default: False)
  --dns-digitalocean    Obtain certificates using a DNS TXT record (if you are using
                        DigitalOcean for DNS). (default: False)
  --dns-dnsimple        Obtain certificates using a DNS TXT record (if you are using
                        DNSimple for DNS). (default: False)
  --dns-dnsmadeeasy     Obtain certificates using a DNS TXT record (if you are using DNS
                        Made Easy for DNS). (default: False)
  --dns-gehirn          Obtain certificates using a DNS TXT record (if you are using Gehirn
                        Infrastructure Service for DNS). (default: False)
  --dns-google          Obtain certificates using a DNS TXT record (if you are using Google
                        Cloud DNS). (default: False)
  --dns-linode          Obtain certificates using a DNS TXT record (if you are using Linode
                        for DNS). (default: False)
  --dns-luadns          Obtain certificates using a DNS TXT record (if you are using LuaDNS
                        for DNS). (default: False)
  --dns-nsone           Obtain certificates using a DNS TXT record (if you are using NS1 for
                        DNS). (default: False)
  --dns-ovh             Obtain certificates using a DNS TXT record (if you are using OVH for
                        DNS). (default: False)
  --dns-rfc2136         Obtain certificates using a DNS TXT record (if you are using BIND
                        for DNS). (default: False)
  --dns-route53         Obtain certificates using a DNS TXT record (if you are using Route53
                        for DNS). (default: False)
  --dns-sakuracloud     Obtain certificates using a DNS TXT record (if you are using Sakura
                        Cloud for DNS). (default: False)

Certbot's behavior differed from what I expected because:

As the above text shows, the --server flag is not present in help, and appears to be ignored when used. If I ask for a different ACME server, the command demanding ToS acceptance and my email for use with LetsEncrypt.

Since I did not find any indication that --server comes from a plugin (if it does, apologies), I expected the first command to work as it reads, on account of it being present in a reasonably recent guide.

alexzorin commented 2 years ago

Hi @zyrolasting,

You are right that --server does not show up in certbot --help. It does show up in certbot --help all. I'm guessing that was just a historical decision about what to show/hide on the basic help screen.

If I ask for a different ACME server, the command demanding ToS acceptance and my email for use with LetsEncrypt.

I don't see this happening in your CLI output.

The tasks of agreeing to a Terms of Service, and providing a contact email address for your registration, are not specific to Let's Encrypt. Both tasks are built-in parts of the ACME protocol, which both Let's Encrypt and Step CA implement.

You are acknowledging the terms of service of Step CA (--agree-tos) and providing a contact email address to Step CA. The email address you can skip with --register-unsafely-without-email, if the ACME server allows it, which Step CA does.

There is however, a bug in Certbot here, which I have filed separately at https://github.com/certbot/certbot/issues/8977. Since Step CA does not include a terms of service in its ACME server, Certbot shouldn't be asking you to agree with it. It's a UI bug more than anything.