Let's Encrypt

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

Let's Encrypt (LE) is een initiatief van de Electronic Freedom Foundation om iedereen de beschikking te geven over SSL-certificaten. Met LE kun je met een beetje mazzel binnen 15 minuten gratis een certificaat voor een site regelen. Maar niet altijd: Er zitten hier en daar wat technische haken en ogen aan.

What I'm usually looking for

sudo certbot

sudo certbot renew

sudo certbot delete

Installatie certbot

2018

Certbot is de applicatie die voor het certificaat zorgt. Deze procedure voor Ubuntu 17.04, werkte prima op Ubuntu 18.04 (lente 2018):

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt update
sudo apt install python-certbot-apache 

Gewoon sudo apt install certbot lijkt aanvankelijk goed te werken, maar vervolgens blijken er onderdelen te ontbreken.

2021

sudo add-apt-repository ppa:certbot/certbot
sudo apt install python3-certbot-apache

Installatie SSL-certificaat

In den begin

sudo certbot --apache

Er worden een paar vragen gesteld. Die worden hieronder behandeld. De rest spreekt voor zich - Er wordt oa. automatisch een nieuw Apache Virtual Host-bestand aangemaakt!

Wat mij vaak beter bevalt:

sudo certbot --apache --redirect --reinstall

Automatisch vernieuwen?

Uiteraard.

Met en zonder 'www'?

Zo zorg je ervoor dat de domeinnaam met en zonder www van een certificaat worden voorzien: Eén certificaat voor beide namen!
  • Meestal defineer ik een host zoals example.com met www.example.com als alias
  • Op het moment dat je naar bv. www.example.com gaat, wordt je direct omgeleid naar example.com. Het adres in de browser verandert dus naar example.com
  • De crux is, om een bepaald certificaat voor beide domeinnamen toe te passen - En dat wordt niet expliciet aangegeven

Mixed content

Nee: Alleen https - Moet nog worden uitgewerkt

Redirect

Je kunt kiezen om de oude en nieuwe site naast elkaar te laten bestaan, of dat http-verkeer wordt omgeleid naar https-verkeer. Ik kies steeds dat laatste, maar ik heb de indruk dat het niet echt werkt → Zie aparte hoofdstuk in dit artikel.

Aanpassingen websites?

  • Voor Drupal-sites hoef je niets aan te passen
  • Voor WordPress-sites moet je een paar dingen aanpassen: SSL & WordPress.

Aanpassingen firewall?

https gaat over poort 443. Deze moet dus geopend zijn in de firewall → UFW (firewall).

Alle domeinen tegelijkertijd bijwerken?

Now you're playing with power:

sudo certbot run --apache --redirect

Je krijgt de mogelijkheid om in één keer alle domeinen op een webserver van certificaat te voorzien. Daar heb ik slechte ervaringen mee.

Verificatie

Gewoon: De betreffende site oproepen in een browser met voorvoegsel https// - Werkt direct. Blijkbaar zijn er geen DNS-wijzigingen voor nodig.

Additionele sites op dezelfde server

Gewoon opnieuw sudo certbot --apache

DNS moet accuraat zijn

  • De betreffende site moet uiteraard wel gewoon bereikbaar zijn via DNS. Anders lukt zo'n response niet
  • Ik heb regelmatig de situatie dat ik een certificaat wil aanvragen voor een domein waarvan de DNS-entries nog zijn aangepast. Ongetwijfeld ben ik niet de enige in die situatie. Het lijkt er echter op, dat hier geen oplossing voor is [1]: Het A-record moet accuraat zijn.

Test

https://www.ssllabs.com/ssltest/analyze.html?d=example.com

Hmm, dit werkt dan weer niet, voor het eerste domein waarvoor ik zojuist een certificaat heb aangevraagd. Maar veel belangrijker: De site zelf is nu wel bereikbaar via https!

SSL-certificaat ongedaan maken

Gewoon opnieuw sudo certbot --apache.

Hoe het werkt

  • Voor een site met of zonder SSL, heb je geen aparte DNS-wijzigingen nodig. Blijkbaar is het protocol nog steeds http
  • Wat wel verschilt: http-verkeer gaat doorgaans over poort 80, terwijl https-verkeer over poort 443 gaat
  • Let's Encrypt plaatst een testfile ergens in het virtuele domein, en met een challenge-en-response wordt op die manier het domein geverifiëerd. Zie verderop voor details
  • Let's Encrypt maakt een aparte entry aan voor het domein-met-ssl in sites-enabled
  • ⇒ Gebruik voor hoofd- & subdomeinen op een gegeven server, één SSL-certificaat (dus voor bv. example.com & media.example.com) - Om het simpel te houden.

De domeinnamen waar LE certificaten voor heeft verzorgd, kun je (ook zonder sudo) inzien via

ls /etc/letsencrypt/live

In elke map vind je een aantal bestanden. Naar sommige van die bestanden wordt verwezen vanuit het bijbehorende vHost-bestand:

  Bestandsnaam    Omschrijving      Verwijzing vHost-bestand
  ------------    ---------------   -------------------------------------------------------------------
* cert.pem        SSLCertificateFile        /etc/letsencrypt/live/example.com/cert.pem
* chain.pem       SSLCertificateChainFile   /etc/letsencrypt/live/example.com/chain.pem
* fullchain.pem   
* privkey.pem     SSLCertificateKeyFile     /etc/letsencrypt/live/example.com/privkey.pem
* README

Apache virtuele host-configuraties

  • Bij gebruik van Let's Encrypt, krijg je twee vHost-definities: Eén met SSL, en een redirect zonder. Vermoedelijk kun je deze twee samenvoegen tot één vHost-bestand, maar dat heb ik nog niet geprobeerd.
  • Het is cruciaal dat je bij de aanvraag van het certificaat, dit certificaat voor zowel het eigenlijke domein als voor de alias laat gelden

Voorbeeld vHost-definities example.com:

example.com-le-ssl.conf

LE kan desgewenst zelf een configuratie-bestand maken. Daar maak ik geen gebruik van. Wat ik zelf hanteer:

<VirtualHost *:443>

        ServerName example.com
        ServerAlias www.example.com
        DirectoryIndex index.php index.html index.htm
        DocumentRoot /var/www/example.com

        <Directory /var/www/example.com>

                AllowOverride All
                Require all granted
                RewriteEngine on
                RewriteBase /
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

        </Directory>

        LogLevel warn
        ErrorLog /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log vhost_combined

        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

</VirtualHost>

example.com.conf

LE past desgewenst het oude .conf-bestand aan, maar dat werkt voor mij niet. Wat voor mij wel werkt:

<VirtualHost *:80>

        ServerName example.com
        ServerAlias www.example.com

        Redirect / https://example.com

</VirtualHost>

Merk op dat hier geen log-statements in zit. Bij een redirect komt het log er namelijk niet echt aan te pas, ofzo.

Certificaten bekijken

Wat het dichtst in de buurt komt van een statusoverzicht:

sudo certbot certificates

of

sudo certbot certificates example.com

Certificaten vernieuwen

Als je vergeet een certificaat te vernieuwen. Ik had al wel andere domeinen toegevoegd aan dit certificaat (bv. test.devliegendebrigade.nl), maar niet het bestaande certificaat vernieuws. Dan krijg je dit
Na sudo certbot renew was het probleem gelijk verdwenen

Certificaten zijn drie maanden geldig. Als de vervaldatum in de buurt komt, krijg je een herinneringsemail. Vernieuwen gaat verbluffend eenvoudig. Met

sudo certbot renew

worden alle certificaten vernieuwd, die binnenkort aflopen op de betreffende server. Alleen de mededelingen leken niet te kloppen (aug. 2018): Hij zij dat er niets te vernieuwen was, terwijl-ie twee certificaten vernieuwd had.

Bijbehorende logbestanden staan in map

/var/log/letsencrypt/

Het actuele logbestand kun je oa. lezen met

sudo tail /var/log/letsencrypt/letsencrypt.log

Onhandig dat 't niet leesbaar is voor gewone accounts. Sois.

Foutmeldingen

Foutmeldingen omtrent domeinnamen die niet gehost worden op de betreffende server? sudo certbot delete (zie verderop).

Certificaten verwijderen

Certificaten verwijderen, bv. van domeinen die je niet meer host op de betreffende server? Simpel:

sudo certbot delete

Net als bij het installeren van certificaten, kun je opnieuw meerdere URL's selecteren, gescheiden door spaties of komma's.

En als je het zeker wilt weten:

ls /etc/letsencrypt/live

Aliases

  • Je kunt geen certificaat aanvragen voor aliases. Alleen voor echte domeinnamen [2]
  • Je kunt per certificaat tot 100 aliases hebben [3]. Voorbeeld: sudo certbot certonly --apache -d domain.com,www.domain.com,sub1.domain.com,sub2.domain.com,domain2.com,www.domain2.com,[...]
  • Per vHost kun je maximall één certificaat hebben. Je kunt er dus voor kiezen om voor bv. example.com en www.example.com, twee vHosts te hebben, met twee certificaten. In de zomer van 2018 heb ik die aanpak met succes toegepast op een site voor kindercoaching. De twee vHosts verwezen overigens naar dezelfde map binnan /var/www. Met een andere site op het gebied van trauma-therapie, krijg ik dit truukje maar niet aan de praat → Waarschijnlijk overzichtelijker om met aliases te werken

Dit is de oplossing: Als je Certbort start met alleen sudo certbot en hij vraagt om welke domeinen het gaat, dan kun je meerdere domeinen kiezen. Die krijgen allemaal hetzelfde certficaat. Dat is de manier om een alias te incorporeren in het hoofddomein!

Redirect domein A → domein B

Bij een redirect van domein A naar domein B, gaat de redirect voor http prima, maar die voor https geeft een foutmelding dat het certificaat niet klopt. Waarschijnlijk omdat je een certificaat krijgt voor het ene domein, terwijl je naar een ander domein ging.

De vermoedelijke oplossing: Zorg dat beide domeinen bij hetzelfde certificaat horen. Ik heb dat nog niet uitvoerig getest, maar het lijkt te werken (zomer 2020). Ik hoefde verder niets aan te passen in vHost-bestanden.

Zoiets dus: Dit is een domein met aliassen (andere domeinnamen) en subdomeinen. Die krijgen allemaal hetzelfde certificaat

Troubleshooting

  • Is Apache-module mod_ssl geactiveerd?
  • Firewall poort 443?
  • Zijn de betreffende vHosts wel geactiveerd??? In de herfst van 2018 vermoedelijk dit over het hoofd gezien bij een domein
  • Certificaten gedefineerd voor zowel hoofddomein als alias?
  • Server herstart?

Utattended execution

Waarschijnlijk kun je het proces van het aanvragen van een certificaat, automatiseren [4].

Dit geeft voor mij hetzelfde resultaat als hoe ik het doorgaans handmatig doe:

sudo certbot --apache --non-interactive --agree-tos --no-redirect --domains $domain_name

Casus: devliegendebrigade.nl (herfst 2018)

Oude situatie

  • Er is een A- en een AAA-DNS-record voor dit domein gedefineerd. Dat AAAA-record vertrouw ik overigens niet zo
  • Er is een vHost voor devliegendebrigade.nl, waarvan www.devliegendebrigade.nl een alias is. Dit is de bijbehorende vHost-definitie:
<VirtualHost *:80> 
 
   ServerName devliegendebrigade.nl 
   ServerAlias www.devliegendebrigade.nl 
   DirectoryIndex index.php index.html index.htm 
   DocumentRoot /home/strompf/public/devliegendebrigade.nl/public 
 
   <Directory /home/strompf/public/devliegendebrigade.nl/public> 
 
      AllowOverride All 
      Require all granted 
      RewriteEngine on 
      RewriteBase / 
      RewriteCond %{REQUEST_FILENAME} !-f 
      RewriteCond %{REQUEST_FILENAME} !-d 
      RewriteRule ^(.*)$ index.php?q=$1 [L,QSA] 
 
   </Directory> 
 
   LogLevel warn 
   ErrorLog /home/strompf/public/devliegendebrigade.nl/log/error.log 
   CustomLog /home/strompf/public/devliegendebrigade.nl/log/access.log combines 
 
</VirtualHost>

Certificaat aanvragen

  • sudo certbot
  • Which name would you like to activate HTTPS for?devliegendebrigade.nl
  • Er wordt automatisch een nieuwe vHost-definitie geplaatst - Daar heb je dus geen controle over
  • Geen redirect laten aanmaken - Dat doe ik zelf.

Dit is het nieuwe vHost-bestand devliegendebrigade.nl-le-ssl.conf:

<IfModule mod_ssl.c>
<VirtualHost *:443>

   ServerName devliegendebrigade.nl
   ServerAlias www.devliegendebrigade.nl
   DirectoryIndex index.php index.html index.htm
   DocumentRoot /home/strompf/public/devliegendebrigade.nl/public

   <Directory /home/strompf/public/devliegendebrigade.nl/public>

      AllowOverride All 
      Require all granted
      RewriteEngine on
      RewriteBase /
      RewriteCond %{REQUEST_FILENAME} !-f 
      RewriteCond %{REQUEST_FILENAME} !-d 
      RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

   </Directory>

   LogLevel warn
   ErrorLog /home/strompf/public/devliegendebrigade.nl/log/error.log
   CustomLog /home/strompf/public/devliegendebrigade.nl/log/access.log combines

SSLCertificateFile /etc/letsencrypt/live/devliegendebrigade.nl/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/devliegendebrigade.nl/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/devliegendebrigade.nl/chain.pem
</VirtualHost>
</IfModule>

Troubleshooting

https://devliegendebrigade.nl geeft time-out-problemen. Troubleshooting:

Casus: Foutmelding fullchain.pem (herfst 2018)

Probleem

Dit probleem krijg ik op alle servers bij commando apachectl -S:

AH00526: Syntax error on line 24 of /etc/apache2/sites-enabled/example.com-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/example.com/fullchain.pem' does not 
exist or is empty

Action '-S' failed.

The Apache error log may have more information.

Aanvullende gegevens

  • Dit bestand is gewoon aanwezig
  • Dit bestand is niet bereikbaar als je geen root bent: sudo less /etc/letsencrypt/live/example.com/fullchain.pem werkt, maar less /etc/letsencrypt/live/example.com/fullchain.pem geeft een foutmelding.
  • Dit bestand is een link naar bestand /etc/letsencrypt/archive/example.com

Vermoedelijke oorzaak: Bestandspermissies

  • Apache kan het pad /etc/letsencrypt/live/example.com/fullchain.pem niet volgen, maar het uiteindelijke bestand fullchain.pem is wél world-readable
  • fullchain.pem is een link naar /etc/letsencrypt/archive/example.com/fullchain1.pem, en dat bestand is niet world-readable: -rw-r--r-- 1 root root 3818 mei 25 13:16 fullchain1.pem

Oplossing: Bestandspermissies aanpassen?

Misschien bestaat er een beter oplossing, maar aanpassen van bestandspermissies, werkt: Alle tussenliggende mappen moeten leesbaar zijn voor Apache (sudo chmod o+rx). Dat vereist precies twee commando's (heb ik uitvoerig getest):

sudo chmod o+rx /etc/letsencrypt/live
sudo chmod o+rx /etc/letsencrypt/archive

Verder...

  • Als je na aanpassen van de bestandsrechten, opnieuw sudo certbot --apache --redirect --reinstall geeft, veranderen de bestandsrechten niet
  • Ik hoef dit gelukkig maar één keer per server te verbeteren.

Casus: Foutmelding fullchain.pem (jan. 2019)

Probleem

Zelfde storing als hierboven: Alle domeinen op de betreffende server zijn offline, en apachectl -S geeft dezelfde foutmelding als hiervoor. Echter, de oplossing die daar genoemd werd, lijkt niet te werken.

Melding Apachectl:

AH00526: Syntax error on line 23 of /etc/apache2/sites-enabled/example.com-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/example.com/fullchain.pem' does not exist or is empty
Action '-S' failed.

Oorzaken

  1. De betreffende domeinnaam-map onder /etc/letsencrypt/live bestaat niet - Dat is anders dan in de situatie hierboven
  2. Vermoedelijk was het certificaat van één van de domeinnamen verlopen en daardoor verwijderd van de server. Dat veroorzaakte de Apache-foutmelding.

Oplossing

Accuut

  1. Verwijzing naar SSL-certificaat uit-commentariseren uit Apache virtuele hostbestand: Zolang dit bestand niet ok is, functioneert Apache niet, en is certbot niet mogelijk
  2. Apache herstarten (sudo service apache2 restart)
  3. sudo certbot voor het betreffende domein
  4. Verifiëren dat het Apache virtuele hostbestand ok is; evt. aanpassen + Apache herstarten
  5. Verifiëren dat de sites weer online zijn.

Structureel

Update-scripts op alle servers uitgebreid met regel sudo certbot renew.

Foutmelding redirect http » https

Probleem

Ik heb de indruk dat de redirect van http naar https niet werkt: Nadat het SSL-certificaat werkt, is de site nog steeds gewoon bereikbaar via http. Ik heb liever dat sites altijd automatisch redirecten naar https.

Aanvullende gegevens

Terugkoppeling tijdens installatieprocedure:

Added an HTTP->HTTPS rewrite in addition to other RewriteRules; you may wish to check for overall consistency.
Redirecting vhost in /etc/apache2/sites-enabled/example.com.conf to ssl vhost in 
/etc/apache2/sites-available/example.com-le-ssl.conf

Er zijn nu twee virtual host-bestanden: example.com.conf en example.com-le-ssl.conf. In dat eerste bestand is een RewriteRule opgenomen:

RewriteCond %{SERVER_NAME} =www.example.com [OR]
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

maar dit lijkt niet te werken.

Mogelijke oorzaken

  • Is Apache-module rewrite wel actief? → sudo a2enmod rewrite → Yep: Module rewrite already enabled
  • Is de originele host-file wel actief? → apachectl -S → Ja: Ze worden beide vermeld
  • Redirect is beter dan rewrite [5]

Oplossing

Zoals [6] uitlegt: De virtual host-definitie voor een site die 100% ge-redirect wordt, kan veel simpeler. Bv.:

<VirtualHost *:80>

        ServerName example.com
        ServerAlias www.example.com

        Redirect / https://example.com

        LogLevel warn
        ErrorLog /var/log/apache2/error.log
        CustomLog /var/log/apache2/access.log vhost_combined

</VirtualHost>

Goede kans dat dit zelfs beter is:

<VirtualHost *:80>

        ServerName example.com
        ServerAlias www.example.com

        Redirect / https://example.com

</VirtualHost>

Tijdens tests in juni 2018, had ik voor een bepaald domein een redirect naar zichzelf gemaakt. Dat gaf binnen de browser een foutmelding, maar ik kon het niet terugvinden in het logboek.

Te algemene redirect?

Bovenstaande redirect lijkt te algemeen te zijn: Als ik een ander domein oproep dat op een of andere manier naar deze server verwijst, wordt-ie ook afgevangen door deze redirect. Sois: Als een domein niet aanwezig is, pakt Apache altijd een ander domein.

Foutmelding: Site can't provide secure connection (Sep. 2018)

Het probleem

Dit dus - Chrome
En in Firefox

Aanvullende gegevens

Als ik in Firefox info opvraag tav. de connetie, krijg ik dit: Alsof er geen certificaat is
sudo certbot certificates - Ziet er goed uit (het is vandaag 28 sep. 2018)

Mogelijke oorzaken

  • "This error is caused by speaking HTTP on port 443 instead of HTTPS" [7]

Foutmelding: Invalid response (okt. 2018)

Zoiets als

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.example.com
   Type:   unauthorized
   Detail: Invalid response from
   http://www.example.com/.well-known/acme-challenge/hnSnXUAVLYHcFtt2EjmyF2fYZ12379w5zl-Ep4VL8-k:
   "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"\n
   \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n<html
   xmlns=\"htt"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

Oorzaak: Het domein was zonet verhuisd, en de DNS-entries wezen nog naar de oude locatie. Oplossing: Dagje wachten.

Casus: Foutmelding NXDOMAIN (jan. 2019)

Foutmelding

 The following errors were reported by the server:

   Domain: www.example.com
   Type:   None
   Detail: DNS problem: NXDOMAIN looking up A for example.com

Oorzaak

Er was wel een DNS-entry aangemaakt voor example.com, maar niet voor www.example.com.

Casus: Fullchain-foutmelding (sep. 2021)

Probleem

Hmm, sommige dingen lijken nooit te veranderen:

$ apachectl -M

AH00526: Syntax error on line 27 of /etc/apache2/sites-enabled/example.com-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/example.com/fullchain.pem' does not exist or is empty
Action '-M' failed.
The Apache error log may have more information.

Diagnose

Het bestand bestaat. Zoals in het verleden ook al bleek: Het is een rare zoektocht om er te komen:

sudo ls -alF /etc/letsencrypt/live/example.com/../../archive/example.com
sudo less /etc/letsencrypt/live/example.com/../../archive/example.com/fullchain1.pem

en ik kan ook weinig met de inhoud (net als een public key).

Oplossing

Dezelfde oplossing als in 2018:

sudo chmod o+rx /etc/letsencrypt/live
sudo chmod o+rx /etc/letsencrypt/archive

Case: How to renew an outdated certificate? (2023.06)

The problem

  • A certificate is outdated for domain voorbeeld.nl, meaning that a file is gone. Therefore, Apache doesn't work anymore
  • I can't renew the certificate without a functioning Apache.

Possible solutions

  • Pause the problematic virtual host → Run Certbot → Fix virtual host file ⇒ Doesn't work: The problematic domain is the same as for which the certificate is needed
  • Disable the problematic virtual host file → Run Certbot → Etc.

Actions & info

  • The exact error: AH00526: Syntax error on line 25 of /etc/apache2/sites-enabled/example.nl-le-ssl.conf: SSLCertificateFile: file '/etc/letsencrypt/live/example.nl-0001/fullchain.pem' does not exist or is empty. Action '-S' failed. - Appearantly, an outdated certificate implies that a file is gone
  • a2dis example.nl-le-ssl.conf - Appearantly, you can still stop a domain, despite errors
  • Start Apache (restart doesn't work as Apache wasn't running): sudo systemctl load apache2

Zie ook

Bronnen

Aliases

Foutmelding fullchain.pem

Redirect-storing

No secure connection-storing

Appendix: man certbot

certbot - certbot script documentation

usage:
  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
   -d DOMAINS       Comma-separated list of domains to obtain a certificate for

  --apache          Use the Apache plugin for authentication & installation
  --standalone      Run a standalone webserver for authentication
  --nginx           Use the Nginx plugin for authentication & installation
  --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-path)
    delete          Delete a certificate

manage your account with Let's Encrypt:
    register        Create a Let's Encrypt ACME account
  --agree-tos       Agree to the ACME server's Subscriber Agreement
   -m EMAIL         Email address for important account notifications

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)
  -v, --verbose         This flag can be used multiple times to incrementally
                        increase the verbosity of output, e.g. -vvv. (default:
                        -2)
  --max-log-backups MAX_LOG_BACKUPS
                        Specifies the maximum number of backup logs that
                        should be kept by Certbot's built in log rotation.
                        Setting this flag to 0 disables log rotation entirely,
                        causing Certbot to always append to the same log file.
                        (default: 1000)
  -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)
  --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)
  --debug-challenges    After setting up challenges, wait for user input
                        before submitting to CA (default: False)
  --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 "tls-
                        sni-01,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: [])
  --user-agent USER_AGENT
                        Set a custom user agent string for the client. User
                        agent strings allow the CA to collect high level
                        statistics about success rates by OS, plugin and use
                        case, and to know when to deprecate support for past
                        Python versions and flags. If you wish to hide this
                        information from the Let's Encrypt server, set this to
                        "". (default: CertbotACMEClient/0.22.2 (certbot;
                        darwin 10.13.3) Authenticator/XXX Installer/YYY
                        (SUBCOMMAND; flags: FLAGS) Py/2.7.14). The flags
                        encoded in the user agent are: --duplicate, --force-
                        renew, --allow-subset-of-names, -n, and whether any
                        hooks are set.
  --user-agent-comment USER_AGENT_COMMENT
                        Add a comment to the default user agent string. May be
                        used when repackaging Certbot or calling it from
                        another tool to allow additional statistical data to
                        be collected. Ignored if --user-agent is set.
                        (Example: Foo-Wrapper/1.0) (default: None)

automation:
  Flags for automating execution & other tweaks

  --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)
  --expand              If an existing certificate is a strict subset of the
                        requested names, always expand and replace it with the
                        additional names. (default: Ask)
  --version             show program's version number and exit
  --force-renewal, --renew-by-default
                        If a certificate already exists for the requested
                        domains, renew it now, regardless of whether it is
                        near expiry. (Often --keep-until-expiring is more
                        appropriate). Also implies --expand. (default: False)
  --renew-with-new-domains
                        If a certificate already exists for the requested
                        certificate name but does not match the requested
                        domains, renew it now, regardless of whether it is
                        near expiry. (default: False)
  --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)
  --agree-tos           Agree to the ACME Subscriber Agreement (default: Ask)
  --duplicate           Allow making a certificate lineage that duplicates an
                        existing one (both can be renewed in parallel)
                        (default: False)
  --os-packages-only    (certbot-auto only) install OS package dependencies
                        and then stop (default: False)
  --no-self-upgrade     (certbot-auto only) prevent the certbot-auto script
                        from upgrading itself to newer released versions
                        (default: Upgrade automatically)
  --no-bootstrap        (certbot-auto only) prevent the certbot-auto script
                        from installing OS-level dependencies (default: Prompt
                        to install OS-wide dependencies, but exit if the user
                        says 'No')
  -q, --quiet           Silence all output except errors. Useful for
                        automation via cron. Implies --non-interactive.
                        (default: False)

security:
  Security parameters & server settings

  --rsa-key-size N      Size of the RSA key. (default: 2048)
  --must-staple         Adds the OCSP Must Staple extension to the
                        certificate. Autoconfigures OCSP Stapling for
                        supported setups (Apache version >= 2.3.3 ). (default:
                        False)
  --redirect            Automatically redirect all HTTP traffic to HTTPS for
                        the newly authenticated vhost. (default: Ask)
  --no-redirect         Do not automatically redirect all HTTP traffic to
                        HTTPS for the newly authenticated vhost. (default:
                        Ask)
  --hsts                Add the Strict-Transport-Security header to every HTTP
                        response. Forcing browser to always use SSL for the
                        domain. Defends against SSL Stripping. (default: None)
  --uir                 Add the "Content-Security-Policy: upgrade-insecure-
                        requests" header to every HTTP response. Forcing the
                        browser to use https:// for every http:// resource.
                        (default: None)
  --staple-ocsp         Enables OCSP Stapling. A valid OCSP response is
                        stapled to the certificate that the server offers
                        during TLS. (default: None)
  --strict-permissions  Require that all configuration files are owned by the
                        current user; only needed if your config is somewhere
                        unsafe like /tmp/ (default: False)

testing:
  The following flags are meant for testing and integration purposes only.

  --test-cert, --staging
                        Use the staging server to obtain or revoke test
                        (invalid) certificates; equivalent to --server https
                        ://acme-staging-v02.api.letsencrypt.org/directory
                        (default: False)
  --debug               Show tracebacks in case of errors, and allow certbot-
                        auto execution on experimental platforms (default:
                        False)
  --no-verify-ssl       Disable verification of the ACME server's certificate.
                        (default: False)
  --tls-sni-01-port TLS_SNI_01_PORT
                        Port used during tls-sni-01 challenge. This only
                        affects the port Certbot listens on. A conforming ACME
                        server will still attempt to connect on port 443.
                        (default: 443)
  --tls-sni-01-address TLS_SNI_01_ADDRESS
                        The address the server listens to during tls-sni-01
                        challenge. (default: )
  --http-01-port HTTP01_PORT
                        Port used in the http-01 challenge. This only affects
                        the port Certbot listens on. A conforming ACME server
                        will still attempt to connect on port 80. (default:
                        80)
  --http-01-address HTTP01_ADDRESS
                        The address the server listens to during http-01
                        challenge. (default: )
  --break-my-certs      Be willing to replace or renew valid certificates with
                        invalid (testing/staging) certificates (default:
                        False)

paths:
  Flags for changing execution paths & servers

  --cert-path CERT_PATH
                        Path to where certificate is saved (with auth --csr),
                        installed from, or revoked. (default: None)
  --key-path KEY_PATH   Path to private key for certificate installation or
                        revocation (if account key is missing) (default: None)
  --fullchain-path FULLCHAIN_PATH
                        Accompanying path to a full certificate chain
                        (certificate plus chain). (default: None)
  --chain-path CHAIN_PATH
                        Accompanying path to a certificate chain. (default:
                        None)
  --config-dir CONFIG_DIR
                        Configuration directory. (default: /etc/letsencrypt)
  --work-dir WORK_DIR   Working directory. (default: /var/lib/letsencrypt)
  --logs-dir LOGS_DIR   Logs directory. (default: /var/log/letsencrypt)
  --server SERVER       ACME Directory Resource URI. (default:
                        https://acme-v01.api.letsencrypt.org/directory)

manage:
  Various subcommands and flags are available for managing your
  certificates:

  certificates          List certificates managed by Certbot
  delete                Clean up all files related to a certificate
  renew                 Renew all certificates (or one specified with --cert-
                        name)
  revoke                Revoke a certificate specified with --cert-path
  update_symlinks       Recreate symlinks in your /etc/letsencrypt/live/
                        directory

run:
  Options for obtaining & installing certificates

certonly:
  Options for modifying how a certificate is obtained

  --csr CSR             Path to a Certificate Signing Request (CSR) in DER or
                        PEM format. Currently --csr only works with the
                        'certonly' subcommand. (default: None)

renew:
  The 'renew' subcommand will attempt to renew all certificates (or more
  precisely, certificate lineages) you have previously obtained if they are
  close to expiry, and print a summary of the results. By default, 'renew'
  will reuse the options used to create obtain or most recently successfully
  renew each certificate lineage. You can try it with `--dry-run` first. For
  more fine-grained control, you can renew individual lineages with the
  `certonly` subcommand. Hooks are available to run commands before and
  after renewal; see https://certbot.eff.org/docs/using.html#renewal for
  more information on these.

  --pre-hook PRE_HOOK   Command to be run in a shell before obtaining any
                        certificates. Intended primarily for renewal, where it
                        can be used to temporarily shut down a webserver that
                        might conflict with the standalone plugin. This will
                        only be called if a certificate is actually to be
                        obtained/renewed. When renewing several certificates
                        that have identical pre-hooks, only the first will be
                        executed. (default: None)
  --post-hook POST_HOOK
                        Command to be run in a shell after attempting to
                        obtain/renew certificates. Can be used to deploy
                        renewed certificates, or to restart any servers that
                        were stopped by --pre-hook. This is only run if an
                        attempt was made to obtain/renew a certificate. If
                        multiple renewed certificates have identical post-
                        hooks, only one will be run. (default: None)
  --deploy-hook DEPLOY_HOOK
                        Command to be run in a shell once for each
                        successfully issued certificate. For this command, the
                        shell variable $RENEWED_LINEAGE will point to the
                        config live subdirectory (for example,
                        "/etc/letsencrypt/live/example.com") containing the
                        new certificates and keys; the shell variable
                        $RENEWED_DOMAINS will contain a space-delimited list
                        of renewed certificate domains (for example,
                        "example.com www.example.com" (default: None)
  --disable-hook-validation
                        Ordinarily the commands specified for --pre-hook
                        /--post-hook/--deploy-hook will be checked for
                        validity, to see if the programs being run are in the
                        $PATH, so that mistakes can be caught early, even when
                        the hooks aren't being run just yet. The validation is
                        rather simplistic and fails if you use more advanced
                        shell constructs, so you can use this switch to
                        disable it. (default: False)
  --no-directory-hooks  Disable running executables found in Certbot's hook
                        directories during renewal. (default: False)

certificates:
  List certificates managed by Certbot

delete:
  Options for deleting a certificate

revoke:
  Options for revocation of certificates

  --reason {unspecified,keycompromise,affiliationchanged,superseded,cessationofoperation}
                        Specify reason for revoking certificate. (default:
                        unspecified)
  --delete-after-revoke
                        Delete certificates after revoking them. (default:
                        None)
  --no-delete-after-revoke
                        Do not delete certificates after revoking them. This
                        option should be used with caution because the 'renew'
                        subcommand will attempt to renew undeleted revoked
                        certificates. (default: None)

register:
  Options for account registration & modification

  --register-unsafely-without-email
                        Specifying this flag enables registering an account
                        with no email address. This is strongly discouraged,
                        because in the event of key loss or account compromise
                        you will irrevocably lose access to your account. You
                        will also be unable to receive notice about impending
                        expiration or revocation of your certificates. Updates
                        to the Subscriber Agreement will still affect you, and
                        will be effective 14 days after posting an update to
                        the web site. (default: False)
  --update-registration
                        With the register verb, indicates that details
                        associated with an existing registration, such as the
                        e-mail address, should be updated, rather than
                        registering a new account. (default: False)
  -m EMAIL, --email EMAIL
                        Email used for registration and recovery contact.
                        (default: Ask)
  --eff-email           Share your e-mail address with EFF (default: None)
  --no-eff-email        Don't share your e-mail address with EFF (default:
                        None)

unregister:
  Options for account deactivation.

  --account ACCOUNT_ID  Account ID to use (default: None)

install:
  Options for modifying how a certificate is deployed

config_changes:
  Options for controlling which changes are displayed

  --num NUM             How many past revisions you want to be displayed
                        (default: None)

rollback:
  Options for rolling back server configuration changes

  --checkpoints N       Revert configuration N number of checkpoints.
                        (default: 1)

plugins:
  Options for for the "plugins" subcommand

  --init                Initialize plugins. (default: False)
  --prepare             Initialize and prepare plugins. (default: False)
  --authenticators      Limit to authenticator plugins only. (default: None)
  --installers          Limit to installer plugins only. (default: None)

update_symlinks:
  Recreates certificate and key symlinks in /etc/letsencrypt/live, if you
  changed them by hand or edited a renewal configuration file

plugins:
  Plugin Selection: Certbot client supports an extensible plugins
  architecture. See 'certbot plugins' for a list of all installed plugins
  and their names. You can force a particular plugin by setting options
  provided below. Running --help <plugin_name> will list flags specific to
  that plugin.

  --configurator CONFIGURATOR
                        Name of the plugin that is both an authenticator and
                        an installer. Should not be used together with
                        --authenticator or --installer. (default: Ask)
  -a AUTHENTICATOR, --authenticator AUTHENTICATOR
                        Authenticator plugin name. (default: None)
  -i INSTALLER, --installer INSTALLER
                        Installer plugin name (also used to find domains).
                        (default: None)
  --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
                        areusing DNS Made Easy for DNS). (default: False)
  --dns-google          Obtain certificates using a DNS TXT record (if you are
                        using Google Cloud 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-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)

apache:
  Apache Web Server plugin - Beta

  --apache-enmod APACHE_ENMOD
                        Path to the Apache 'a2enmod' binary. (default: None)
  --apache-dismod APACHE_DISMOD
                        Path to the Apache 'a2dismod' binary. (default: None)
  --apache-le-vhost-ext APACHE_LE_VHOST_EXT
                        SSL vhost configuration extension. (default: -le-
                        ssl.conf)
  --apache-server-root APACHE_SERVER_ROOT
                        Apache server root directory. (default: /etc/apache2)
  --apache-vhost-root APACHE_VHOST_ROOT
                        Apache server VirtualHost configuration root (default:
                        None)
  --apache-logs-root APACHE_LOGS_ROOT
                        Apache server logs directory (default:
                        /var/log/apache2)
  --apache-challenge-location APACHE_CHALLENGE_LOCATION
                        Directory path for challenge configuration. (default:
                        /etc/apache2/other)
  --apache-handle-modules APACHE_HANDLE_MODULES
                        Let installer handle enabling required modules for
                        you.(Only Ubuntu/Debian currently) (default: False)
  --apache-handle-sites APACHE_HANDLE_SITES
                        Let installer handle enabling sites for you.(Only
                        Ubuntu/Debian currently) (default: False)

certbot-route53:auth:
  Obtain certificates using a DNS TXT record (if you are using AWS Route53
  for DNS).

  --certbot-route53:auth-propagation-seconds CERTBOT_ROUTE53:AUTH_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 10)

dns-cloudflare:
  Obtain certificates using a DNS TXT record (if you are using Cloudflare
  for DNS).

  --dns-cloudflare-propagation-seconds DNS_CLOUDFLARE_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 10)
  --dns-cloudflare-credentials DNS_CLOUDFLARE_CREDENTIALS
                        Cloudflare credentials INI file. (default: None)

dns-cloudxns:
  Obtain certificates using a DNS TXT record (if you are using CloudXNS for
  DNS).

  --dns-cloudxns-propagation-seconds DNS_CLOUDXNS_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 30)
  --dns-cloudxns-credentials DNS_CLOUDXNS_CREDENTIALS
                        CloudXNS credentials INI file. (default: None)

dns-digitalocean:
  Obtain certs using a DNS TXT record (if you are using DigitalOcean for
  DNS).

  --dns-digitalocean-propagation-seconds DNS_DIGITALOCEAN_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 10)
  --dns-digitalocean-credentials DNS_DIGITALOCEAN_CREDENTIALS
                        DigitalOcean credentials INI file. (default: None)

dns-dnsimple:
  Obtain certificates using a DNS TXT record (if you are using DNSimple for
  DNS).

  --dns-dnsimple-propagation-seconds DNS_DNSIMPLE_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 30)
  --dns-dnsimple-credentials DNS_DNSIMPLE_CREDENTIALS
                        DNSimple credentials INI file. (default: None)

dns-dnsmadeeasy:
  Obtain certificates using a DNS TXT record (if you are using DNS Made Easy
  for DNS).

  --dns-dnsmadeeasy-propagation-seconds DNS_DNSMADEEASY_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 60)
  --dns-dnsmadeeasy-credentials DNS_DNSMADEEASY_CREDENTIALS
                        DNS Made Easy credentials INI file. (default: None)

dns-google:
  Obtain certificates using a DNS TXT record (if you are using Google Cloud
  DNS for DNS).

  --dns-google-propagation-seconds DNS_GOOGLE_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 60)
  --dns-google-credentials DNS_GOOGLE_CREDENTIALS
                        Path to Google Cloud DNS service account JSON file.
                        (See https://developers.google.com/identity/protocols/
                        OAuth2ServiceAccount#creatinganaccount forinformation
                        about creating a service account and
                        https://cloud.google.com/dns/access-
                        control#permissions_and_roles for information about
                        therequired permissions.) (default: None)

dns-luadns:
  Obtain certificates using a DNS TXT record (if you are using LuaDNS for
  DNS).

  --dns-luadns-propagation-seconds DNS_LUADNS_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 30)
  --dns-luadns-credentials DNS_LUADNS_CREDENTIALS
                        LuaDNS credentials INI file. (default: None)

dns-nsone:
  Obtain certificates using a DNS TXT record (if you are using NS1 for DNS).

  --dns-nsone-propagation-seconds DNS_NSONE_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 30)
  --dns-nsone-credentials DNS_NSONE_CREDENTIALS
                        NS1 credentials file. (default: None)

dns-rfc2136:
  Obtain certificates using a DNS TXT record (if you are using BIND for
  DNS).

  --dns-rfc2136-propagation-seconds DNS_RFC2136_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 60)
  --dns-rfc2136-credentials DNS_RFC2136_CREDENTIALS
                        RFC 2136 credentials INI file. (default: None)

dns-route53:
  Obtain certificates using a DNS TXT record (if you are using AWS Route53
  for DNS).

  --dns-route53-propagation-seconds DNS_ROUTE53_PROPAGATION_SECONDS
                        The number of seconds to wait for DNS to propagate
                        before asking the ACME server to verify the DNS
                        record. (default: 10)

manual:
  Authenticate through manual configuration or custom shell scripts. When
  using shell scripts, an authenticator script must be provided. The
  environment variables available to this script depend on the type of
  challenge. $CERTBOT_DOMAIN will always contain the domain being
  authenticated. For HTTP-01 and DNS-01, $CERTBOT_VALIDATION is the
  validation string, and $CERTBOT_TOKEN is the filename of the resource
  requested when performing an HTTP-01 challenge. When performing a TLS-
  SNI-01 challenge, $CERTBOT_SNI_DOMAIN will contain the SNI name for which
  the ACME server expects to be presented with the self-signed certificate
  located at $CERTBOT_CERT_PATH. The secret key needed to complete the TLS
  handshake is located at $CERTBOT_KEY_PATH. An additional cleanup script
  can also be provided and can use the additional variable
  $CERTBOT_AUTH_OUTPUT which contains the stdout output from the auth
  script.

  --manual-auth-hook MANUAL_AUTH_HOOK
                        Path or command to execute for the authentication
                        script (default: None)
  --manual-cleanup-hook MANUAL_CLEANUP_HOOK
                        Path or command to execute for the cleanup script
                        (default: None)
  --manual-public-ip-logging-ok
                        Automatically allows public IP logging (default: Ask)

nginx:
  Nginx Web Server plugin - Alpha

  --nginx-server-root NGINX_SERVER_ROOT
                        Nginx server root directory. (default: /etc/nginx)
  --nginx-ctl NGINX_CTL
                        Path to the 'nginx' binary, used for 'configtest' and
                        retrieving nginx version number. (default: nginx)

null:
  Null Installer

standalone:
  Spin up a temporary webserver

webroot:
  Place files in webroot directory

  --webroot-path WEBROOT_PATH, -w WEBROOT_PATH
                        public_html / webroot path. This can be specified
                        multiple times to handle different domains; each
                        domain will have the webroot path that preceded it.
                        For instance: `-w /var/www/example -d example.com -d
                        www.example.com -w /var/www/thing -d thing.net -d
                        m.thing.net` (default: Ask)
  --webroot-map WEBROOT_MAP
                        JSON dictionary mapping domains to webroot paths; this
                        implies -d for each entry. You may need to escape this
                        from your shell. E.g.: --webroot-map
                        '{"eg1.is,m.eg1.is":"/www/eg1/", "eg2.is":"/www/eg2"}'
                        This option is merged with, but takes precedence over,
                        -w / -d entries. At present, if you put webroot-map in
                        a config file, it needs to be on a single line, like:
                        webroot-map = {"example.com":"/var/www"}. (default:
                        {})