Let's Encrypt
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.
Dit is wat ik meestal zoek:
sudo certbot
of
sudo certbot renew
Installatie certbot
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.
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'?
- 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.
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 biedt de mogelijkheid om een aparte entry aan te maken in sites-enabled. Nu ik het kunstje iets beter snap, doe ik het voortaan liever zelf
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
sudo certbot certificates
Certificaten vernieuwen
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
Het lijkt erop, dat Certbot met één account werkt, ook al staan domeinen mogelijk op verschillende servers. Dan krijg je foutmeldingen omtrent domeinen die niet gevonden kunnen worden, omdat die immers op andere servers staan.
Certificaten verwijderen
Soms lijkt Certbot certifcaten te willen verlengen van domeinnamen die niet meer op de betreffende server wordt gehost. Hoe fix ik dat? Handmatig configuratiebestanden verwijderen, lijkt me niet de beste oplossing. Welnu:
sudo certbot delete
- Net als bij het installeren van certificaten, kun je opnieuw meerdere URL's selecteren, gescheiden door spaties of komma's
- Vervolgens zijn de map met de betreffende domeinnamen verdwenen:
ls /etc/letsencrypt/live
.
Aliases
- Je kunt geen certificaat aanvragen voor aliases. Alleen voor echte domeinnamen [1]
- Je kunt per certificaat tot 100 aliases hebben [2]. 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 domein. Dat is de manier om een alias te incorporeren in het hoofddomein!
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?
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:
- http://devliegendebrigade.nl doet 't prima - logisch, want geen redirect
- https://www.ssllabs.com/ssltest/analyze.html?d=devliegendebrigade.nl - Rapporteert time-out-problemen
sudo service apache2 restart
- Geen verschil- Opnieuw
sudo certbot
- Certificaat lijkt er echt gewoon te zijn - Apache-module mod_ssl leek niet geïnstalleerd te zijn. Nu wel (Apache mod ssl-module activeren)
- Let's debug gebruikt: https://letsdebug.net/devliegendebrigade.nl/6153 → Hij zegt dat het AAAA-DNS-record niet klopt. Dat kan.
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, maarless /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 bestandfullchain.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.
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
- De betreffende domeinnaam-map onder /etc/letsencrypt/live bestaat niet - Dat is anders dan in de situatie hierboven
- Vermoedelijk was het certificaat van één van de domeinnamen verlopen en daardoor verwijderd van de server. Dat veroorzaakte de Apache-foutmelding.
Oplossing
Accuut
- Verwijzing naar SSL-certificaat uit-commentariseren uit Apache virtuele hostbestand: Zolang dit bestand niet ok is, functioneert Apache niet, en is
certbot
niet mogelijk - Apache herstarten (
sudo service apache2 restart
) sudo certbot
voor het betreffende domein- Verifiëren dat het Apache virtuele hostbestand ok is; evt. aanpassen + Apache herstarten
- 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 [3]
Oplossing
Zoals [4] 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
Aanvullende gegevens
Mogelijke oorzaken
- "This error is caused by speaking HTTP on port 443 instead of HTTPS" [5]
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.
Zie ook
Bronnen
- https://medium.com/@kevinsimper/review-of-getting-free-https-with-let-s-encrypt-5515f74be5f6
- https://certbot.eff.org/lets-encrypt/ubuntutzesty-apache
- https://www.transip.nl/knowledgebase/artikel/528-lets-encrypt-voor-webhosting/
- https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04
- https://community.letsencrypt.org/t/correct-way-to-completely-remove-issued-certificate-s-for-a-domain/7409/11
Aliases
Foutmelding fullchain.pem
- https://community.letsencrypt.org/t/apache-sslcertificatefile-error-does-not-exist-or-is-empty/14995
- https://community.letsencrypt.org/t/sslcertificatefile-file-etc-letsencrypt-live-example-com-cert-pem-does-not-exist-or-is-empty/23665/7
Redirect-storing
- https://www.digitalocean.com/community/questions/let-s-encrypt-standard-force-http-to-https-isn-t-working
- https://wiki.apache.org/httpd/RedirectSSL
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: {})