Certbot
証明書を管理する
Certbotが知っている証明書のリストを表示するには、certificatesサブコマンドを実行します。
certbot certificates
これにより、次の形式で情報が返されます。
Found the following certs:
Certificate Name: example.com
Domains: example.com, www.example.com
Expiry Date: 2017-02-19 19:53:00+00:00 (VALID: 30 days)
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem
Certificate Name証明書の名前を表示します。使用してこの名前を渡し--cert-nameための特定の証明書を指定するためのフラグをrun、certonly、certificates、renew、およびdeleteコマンドを。例：
certbot certonly --cert-name example.com
既存の証明書の再作成と更新
同じドメイン名を持つ既存の証明書がすでにある場合でも、certonlyor runサブコマンドを使用して単一の新しい証明書の作成を要求できます。
証明書がで要求された場合runやcertonly、すでに存在している証明書の名前を指定して、Certbotは、既存の証明書を更新します。それ以外の場合は、新しい証明書が作成され、指定された名前が割り当てられます。
--force-renewal、--duplicate、および--expand既存の証明書と同じ名前の証明書を再作成する際のオプションはCertbotの動作を制御します。要求された動作を指定しない場合、Certbotはあなたが何を意図しているのかを尋ねることがあります。
--force-renewal既存の証明書と同じドメインを持つ新しい証明書を要求するようにCertbotに指示します。各ドメインはを通して明示的に指定されなければなりません-d。成功すると、この証明書は以前の証明書と一緒に保存liveされ、新しい証明書を指すようにシンボリックリンク（「」参照）が更新されます。これは特定の個々の証明書を更新する有効な方法です。
--duplicate既存の証明書と同じドメインを使用して、関連性のない別の証明書を作成するようにCertbotに指示します。この証明書は以前のものとは完全に別々に保存されます。ほとんどのユーザーは、通常の状況ではこのコマンドを発行する必要はありません。
--expand既存の証明書をすべての古いドメインと1つ以上の追加の新しいドメインを含む新しい証明書で更新するようにCertbotに指示します。このオプションを指定--expandすると、この-dオプションを使用して、すべての既存ドメインと1つ以上の新しいドメインを指定できます。
例：
certbot --expand -d existing.com,example.com,newdomain.com
ご希望の場合は、次のようにドメインを個別に指定できます。
certbot --expand -d existing.com -d example.com -d newdomain.com
どの証明書が変更されるかをより詳細に制御でき、ドメインを追加するだけでなくドメインを削除できるため、--cert-name代わりにを使用することを検討し--expandてください。
--allow-subset-of-names指定されたドメイン承認の一部しか取得できない場合は、Certbotに証明書の生成を続行するように指示します。証明書に指定されているドメインがこのシステムを指していない場合は、これが便利です。
これらの方法のいずれかで新しい証明書を取得するたびに、以前の証明書の有効期限が切れているかどうかにかかわらず、新しい証明書は以前に取得した証明書と一緒に存在します。新しい証明書の生成は、ここで説明されているように、ACMEプロトコルの悪用を防ぐことを目的としたいくつかのレート制限に対してカウントされ ます。
証明書のドメインを変更する
この--cert-nameフラグは、-dor --domainsフラグを使用して新しいドメインを指定することによって、証明書に含まれるドメインを変更するためにも使用できます。証明書があればexample.com 、以前に含まれるexample.comとwww.example.com、それが含まれているだけに修飾することができるexample.comだけ指定することによってexample.comで-d又は--domainsフラグ。例：
certbot certonly --cert-name example.com -d example.com
証明書に含まれるドメインのセットを拡張したり、そのセットを完全に置き換えるために同じ形式を使用できます。
certbot certonly --cert-name example.com -d example.org,www.example.org
証明書を取り消す
アカウントキーが侵害された場合、または証明書を無効にする必要がある場合は、revokeコマンドを使用してそれを行います。このrevokeコマンドは、証明書名cert.pemまたはドメインではなく証明書パス（で終わる）を使用することに注意してください。例：
certbot revoke --cert-path /etc/letsencrypt/live/CERTNAME/cert.pem
reasonフラグを使用して証明書を失効させる理由を指定することもできます。理由は、unspecifiedデフォルトである、と同様にkeycompromise、affiliationchanged、superseded、とcessationofoperation：
certbot revoke --cert-path /etc/letsencrypt/live/CERTNAME/cert.pem --reason keycompromise
さらに、証明書が--stagingor --test-certフラグによって取得されたテスト証明書である場合は、そのフラグをrevokeサブコマンドに渡す必要があります 。証明書が取り消されると（または他の証明書管理タスクのために）、deleteサブコマンドを使用して証明書に関連するすべてのファイルをシステムから削除できます。
certbot delete --cert-name example.com
注意
delete証明書を完全に削除するために使用しない場合は、次回の更新イベントで自動的に更新されます。
注意
証明書を失効させても、Let's Encryptサーバーによる料金制限には影響しません。
証明書を更新する
注意
CAを暗号化しましょう短期間の証明書を発行します（90日）。少なくとも3か月に一度は証明書を更新するようにしてください。
また見なさい
このよう通じインストールDebianやUbuntuのバージョンなど、箱から出して自動更新が付属して配布して得られたcertbotクライアントの多くaptなど、EPELてCentOSの/ RHEL 7は、参照の自動更新による 詳細。
バージョン0.10.0以降、Certbotはrenewインストールされているすべての証明書の有効期限が切れることを確認し、それらの更新を試みるアクションをサポートしています。最も簡単な形式は
certbot renew
このコマンドは、30日以内に期限切れになる、以前に取得した証明書を更新しようとします。他のプラグインまたはオプションを指定しない限り、証明書が最初に発行されたときに使用されていたのと同じプラグインおよびオプションが更新の試行に使用されます。とは異なりcertonly、renew複数の証明書を処理し、それぞれが有効期限に近いかどうかを常に考慮します。このためrenew、システムが各証明書を適切なときに自動的に更新できるように、自動使用に適しています（そして設計されています）。renew期限切れに近い証明書を更新するだけなので、必要なだけ頻繁に実行できます - 通常は何もしないためです。
このrenewコマンドには、証明書の更新前または更新後にコマンドまたはスクリプトを実行するためのフックが含まれています。たとえば、スタンドアロンプラグインを使用して取得した単一の証明書がある場合は、更新する前にWebサーバーを停止してスタンドアロンが必要なポートにバインドできるようにし、プラグインの終了後に再起動する必要があります。例：
certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"
フックが0以外の終了コードで終了した場合、エラーは出力されますがstderr、更新は試行されます。フックが失敗してもCertbotはゼロ以外の終了コードで直接終了しませんが、更新が失敗するとCertbotはゼロ以外の終了コードで終了するため、更新が失敗したフックが失敗すると間接的にゼロ以外の終了コードになります。 。証明書の更新期限が切れた場合にのみフックが実行されるため、Webサーバーを不必要に停止することなく上記のコマンドを頻繁に実行できます。
Certbotは、証明書が更新の原因である、ことを検出した場合--pre-hookと--post-hookフックは前に実行し、各試行の後に、それを更新します。更新が成功した後にのみフックを実行したい場合--deploy-hookは、次のようなコマンドを使用してください。
certbot renew --deploy-hook /path/to/deploy-hook-script
たとえば、証明書をrootユーザーとして読み取らないデーモンがある場合、このようなdeployフックはそれらを正しい場所にコピーして適切なファイル許可を適用することができます。
/ path / to / deploy-hook-script
#!/bin/sh
set -e
for domain in $RENEWED_DOMAINS; do
case $domain in
example.com)
daemon_cert_root=/etc/some-daemon/certs
# Make sure the certificate and private key files are
# never world readable, even just for an instant while
# we're copying them into daemon_cert_root.
umask 077
cp "$RENEWED_LINEAGE/fullchain.pem" "$daemon_cert_root/$domain.cert"
cp "$RENEWED_LINEAGE/privkey.pem" "$daemon_cert_root/$domain.key"
# Apply the proper file ownership and permissions for
# the daemon to read its certificate and key.
chown some-daemon "$daemon_cert_root/$domain.cert" \
"$daemon_cert_root/$domain.key"
chmod 400 "$daemon_cert_root/$domain.cert" \
"$daemon_cert_root/$domain.key"
service some-daemon restart >/dev/null
;;
esac
done
Certbotの設定ディレクトリのサブディレクトリにファイルを配置してフックを指定することもできます。設定ディレクトリが/etc/letsencryptであると仮定する と、サブコマンドで証明書が更新されたとき/etc/letsencrypt/renewal-hooks/preに/etc/letsencrypt/renewal-hooks/deploy、およびで 見つけられる実行可能ファイルが/etc/letsencrypt/renewal-hooks/postそれぞれpre、deploy、およびpostフックとして実行されrenewます。これらのフックはアルファベット順に実行され、他のサブコマンドに対しては実行されません。（フックが実行される順序は、ファイル名に含まれる文字のバイト値によって決まり、ロケールには依存しません。）
コマンドライン、設定ファイル、または更新設定ファイルで指定されたフックは、これらのディレクトリですべてのフックを実行した後で通常どおりに実行されます。これに対する1つの小さな例外は、他の場所で指定されたフックが単に同じタイプのフックディレクトリ内の実行可能ファイルへのパスである場合（例えば、プリフックが実行可能ファイルへのパスである場合/etc/letsencrypt/renewal-hooks/pre）、ファイルは2度目には実行されません。 。--no-directory-hooksコマンドラインに含めることで、これらのディレクトリにある実行ファイルをCertbotが自動的に実行しないようにすることができます。
実行することでフックに関するより多くの情報を見つけることができます。certbot --help renew
このコマンドが人の介入なしで正常に実行されることが確実であれば、にコマンドを追加できますcrontab（証明書は期限切れに近いと判断された場合にのみ更新されるため、コマンドは毎週または毎週のように定期的に実行できます）日）。その場合は、エラー以外のすべての出力を黙らせるために-qor --quietquietフラグを使用したいと思うでしょう。
すべての証明書を手動で更新している場合は、この --force-renewalフラグが役に立ちます。更新を検討する際に証明書の有効期限が無視され、インストールされた各証明書の有効期限に関係なく更新が試行されます。（このフォームは毎日の実行には適していません。各証明書は毎日更新されるため、認証局のレート制限にすぐに達します。）
提供されるオプションは、更新が試みられるすべての証明書に適用さ れます。たとえば、 4096ビットのRSA公開鍵を使用して、期限切れに近い証明書をすべて同等の証明書に置き換えようとします。指定されたオプションを使用して証明書が正常に更新された場合、それらのオプションは保存され、その証明書の将来の更新に使用されます。certbot renewcertbot renew --rsa-key-size 4096
更新プロセスをよりきめ細かく制御するための代替フォーム（特定の証明書を一度に1つずつ更新しながら）は、フラグで指定された特定の証明書のサブジェクトドメインの完全なセットを使用する方法です。ユーザー入力をブロックしないようにするためにor フラグを含めることもできます（これはcronからコマンドを実行するときに便利です）。certbot certonly-d-n--noninteractive
certbot certonly -n -d example.com -d www.example.com
この場合、新しい証明書を取得するのではなく、古い証明書を更新して置き換えるために、証明書の対象となるすべてのドメインを指定する必要があります。www.ドメインを忘れないでください。ドメインのサブセットを指定すると、元の証明書を置き換えるのではなく、それらのドメインのみを含む新しい個別の証明書が作成されます。既存の証明書に対応する一連のドメインで実行すると、certonlyコマンドはその特定の証明書を更新しようとします。
有効期限が切れる証明書を更新しない場合、CAは提供されたアドレスに通知メールを送信します。
Certbotは更新プロセスを改善するために懸命に努力しています、そして、あなたの個々の環境にこれらのコマンドを統合することにおいてあなたが遭遇するどんな不都合でも申し訳ありません。
注意
certbot renew更新の試みが失敗した場合、終了ステータスは1になります。これは、証明書を更新する必要がない場合に終了ステータスが0になることを意味します。カスタムスクリプトを作成し、証明書が実際に更新された後にのみコマンドを実行する場合は、更新が成功したときと更新が不要なときの両方で終了ステータスが0になるため、を使用する必要があります。certbot renew--deploy-hook
更新設定ファイルの修正
証明書が発行されると、デフォルトでCertbotはCertbotの実行時に選択されたオプションを追跡する更新設定ファイルを作成します。これにより、更新の時期になるとCertbotは同じオプションを再度使用できるようになります。これらの更新設定ファイルはにあります/etc/letsencrypt/renewal/CERTNAME。
高度な証明書管理タスクでは、証明書の更新設定ファイルを手動で変更することは可能ですが、証明書を更新するCertbotの機能を簡単に破る可能性があるため、お勧めできません。更新設定ファイルを変更する場合は、その有効性をコマンドでテストすることをお勧めします。certbot renew --dry-run
警告
/etc/letsencryptCertbotが証明書を適切に管理できなくなるように、ファイルを変更するとファイルが損傷する可能性があります。そのようにしないことをお勧めします。
ほとんどのタスクでは--deploy-hook、自分の運用状況で必要とされる場合（たとえば、証明書とキーを異なる方法で組み合わせるなど）、そこにあるファイルにシンボリックリンクを指すこと、またはそれらのファイルに基づいて新しいファイルをコピー/作成することに自分自身を制限するのが最も安全 です。他のプログラムによって要求されている、異なる特定の許可を持つもののコピーを持つこと）。
のコンテンツを/etc/letsencrypt/archive/CERTNAME新しいフォルダに移動する場合は、まず更新設定ファイルで新しいフォルダの名前を指定してから、実行してシンボリックリンクが新しいフォルダを指すようにします。certbot update_symlinks/etc/letsencrypt/live/CERTNAME
実行ごとにシンボリックリンクの場所Certbotが更新するライブ証明書ファイルを別の場所に配置する場合は、まずそれらをその場所に移動してから、更新設定ファイルの4つのファイルそれぞれのフルパスを指定します。シンボリックリンクは相対リンクなので、これをフォローする必要があります。certbot update_symlinks
たとえば、証明書の更新設定ファイルに以前に次のディレクティブが含まれていたとします。
archive_dir = /etc/letsencrypt/archive/example.com
cert = /etc/letsencrypt/live/example.com/cert.pem
privkey = /etc/letsencrypt/live/example.com/privkey.pem
chain = /etc/letsencrypt/live/example.com/chain.pem
fullchain = /etc/letsencrypt/live/example.com/fullchain.pem
以下のコマンドを使用して、これらのファイルが配置されている場所を指定できます。
mv /etc/letsencrypt/archive/example.com /home/user/me/certbot/example_archive
sed -i 's,/etc/letsencrypt/archive/example.com,/home/user/me/certbot/example_archive,' /etc/letsencrypt/renewal/example.com.conf
mv /etc/letsencrypt/live/example.com/*.pem /home/user/me/certbot/
sed -i 's,/etc/letsencrypt/live/example.com,/home/user/me/certbot,g' /etc/letsencrypt/renewal/example.com.conf
certbot update_symlinks
自動更新
多くのLinuxディストリビューションでは、システムパッケージマネージャを通じてインストールされたパッケージを使用すると自動的に更新されます。次の表は、不完全そうディストリビューションのリストだけでなく、そうするためにそれらのメソッド。
お使いのシステムは、これはすでに自動化されたかどうかわからない場合は、お使いのディストリビューションのマニュアルを参照、または一般的に（システムのcrontabをチェック/etc/crontab/し、/etc/cron.*/*そしてsystemdにタイマー（）。systemctl list-timers
| 配布名 | 配布バージョン | 自動化メソッド |
|---|---|---|
| CentOS | EPEL 7 | systemd |
| Debian | ジェシー | cron、systemd |
| Debian | ストレッチ | cron、systemd |
| Debian | testing / sid | cron、systemd |
| Fedora | 26 | systemd |
| Fedora | 27年 | systemd |
| RHEL | EPEL 7 | systemd |
| ウブンツ | 17.10 | cron、systemd |
| ウブンツ | certbot PPA | cron、systemd |
私の証明書はどこにありますか？
すべての生成された鍵と発行された証明書はにあります/etc/letsencrypt/live/$domain。複数の代替名を使用してSAN証明書を作成する場合$domainは、-dパラメーターを介して渡される最初のドメインです。コピーするのではなく、あなたの（Web）サーバー設定をそれらのファイルに直接向けてください（またはシンボリックリンクを作成してください）。中に更新、/etc/letsencrypt/live最新の必要なファイルで更新されます。
注意
/etc/letsencrypt/archive最新のバージョンにシンボリックリンクし/etc/letsencrypt/keys ながら、以前のすべてのキーと証明書を含み/etc/letsencrypt/liveます。
以下のファイルが利用可能です。
privkey.pem-
証明書の秘密鍵
警告
これは常に秘密にしておく必要があります！Certbot開発者を含め、誰とも決してそれを共有しないでください。ただし、安全に保管することはできません。SSL/ TLSが機能するためには、サーバーがこのファイルにアクセスする必要があります。
注意
Certbotバージョン0.29.0以降、新しい証明書の秘密鍵はにデフォルトで設定され
0600ます。このファイルのグループモードまたはグループ所有者（gid）に対する変更は、更新時にも保持されます。これがApacheがSSLCertificateKeyFileに、そしてssl_certificate_keyにNginxに必要なものです。
fullchain.pem-
サーバー証明書（リーフ証明書またはエンドエンティティ証明書）を含むすべての証明書。サーバー証明書がこのファイルの最初の証明書で、その後に中間証明書が続きます。
これはApache> = 2.4.8がSSLCertificateFileに必要なもの、そしてNginxがssl_certificateに必要なものです。
cert.pemそしてchain.pem（あまり一般的ではない）-
cert.pemサーバー証明書自体を含み、サーバー証明書chain.pemを検証するためにWebブラウザが必要とする追加の中間証明書を 含みます。あなたのWebサーバにこれらのファイルのいずれかを提供する場合、あなたはしなければならないそれらの両方を提供する、または一部のブラウザでは、「この接続は信頼できないです」サイトのエラーが表示されます時間のいくつかを。Apache < 2.4.8ではSSLCertificateFileにこれらが必要です。そしてSSLCertificateChainFileそれぞれ。
Nginx> = 1.3.7でOCSPステープルを使用している場合は、 OCSP応答を検証する
chain.pemためにssl_trusted_certificateとして指定する必要があります。
注意
すべてのファイルはPEMエンコードされています。DERやPFXなど他の形式が必要な場合は、を使って変換できますopenssl。--deploy-hook自動更新を使用している場合は、これで自動化 できます。
事前および事後検証フック
手動モードで実行した場合、Certbotは事前検証フックと事後検証フックの指定を可能にします。これらのスクリプトを指定するためのフラグがある--manual-auth-hookと--manual-cleanup-hook、それぞれ、次のように使用することができます。
certbot certonly --manual --manual-auth-hook /path/to/http/authenticator.sh --manual-cleanup-hook /path/to/http/cleanup.sh -d secure.example.com
これによりauthenticator.shスクリプトが実行され、検証が試行されてからスクリプトが実行されcleanup.shます。さらに、certbotは関連する環境変数をこれらのスクリプトに渡します。
CERTBOT_DOMAIN：認証されているドメインCERTBOT_VALIDATION：検証文字列（HTTP-01およびDNS-01のみ）CERTBOT_TOKEN：HTTP-01チャレンジのリソース名部分（HTTP-01のみ）
さらにクリーンアップのために：
CERTBOT_AUTH_OUTPUT：authスクリプトが標準出力に書いたものは何でも
HTTP-01の使用例
certbot certonly --manual --preferred-challenges=http --manual-auth-hook /path/to/http/authenticator.sh --manual-cleanup-hook /path/to/http/cleanup.sh -d secure.example.com
/path/to/http/authenticator.sh
#!/bin/bash
echo $CERTBOT_VALIDATION > /var/www/htdocs/.well-known/acme-challenge/$CERTBOT_TOKEN
/path/to/http/cleanup.sh
#!/bin/bash
rm -f /var/www/htdocs/.well-known/acme-challenge/$CERTBOT_TOKEN
DNS-01（Cloudflare API v4）の使用例（あくまで例として、そのまま使用しないでください）
certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /path/to/dns/authenticator.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com
/path/to/dns/authenticator.sh
#!/bin/bash
# Get your API key from https://www.cloudflare.com/a/account/my-account
API_KEY="your-api-key"
EMAIL="your.email@example.com"
# Strip only the top domain to get the zone id
DOMAIN=$(expr match "$CERTBOT_DOMAIN" '.*\.\(.*\..*\)')
# Get the Cloudflare zone id
ZONE_EXTRA_PARAMS="status=active&page=1&per_page=20&order=status&direction=desc&match=all"
ZONE_ID=$(curl -s -X GET "https://api.cloudflare.com/client/v4/zones?name=$DOMAIN&$ZONE_EXTRA_PARAMS" \
-H "X-Auth-Email: $EMAIL" \
-H "X-Auth-Key: $API_KEY" \
-H "Content-Type: application/json" | python -c "import sys,json;print(json.load(sys.stdin)['result'][0]['id'])")
# Create TXT record
CREATE_DOMAIN="_acme-challenge.$CERTBOT_DOMAIN"
RECORD_ID=$(curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
-H "X-Auth-Email: $EMAIL" \
-H "X-Auth-Key: $API_KEY" \
-H "Content-Type: application/json" \
--data '{"type":"TXT","name":"'"$CREATE_DOMAIN"'","content":"'"$CERTBOT_VALIDATION"'","ttl":120}' \
| python -c "import sys,json;print(json.load(sys.stdin)['result']['id'])")
# Save info for cleanup
if [ ! -d /tmp/CERTBOT_$CERTBOT_DOMAIN ];then
mkdir -m 0700 /tmp/CERTBOT_$CERTBOT_DOMAIN
fi
echo $ZONE_ID > /tmp/CERTBOT_$CERTBOT_DOMAIN/ZONE_ID
echo $RECORD_ID > /tmp/CERTBOT_$CERTBOT_DOMAIN/RECORD_ID
# Sleep to make sure the change has time to propagate over to DNS
sleep 25
/path/to/dns/cleanup.sh
#!/bin/bash
# Get your API key from https://www.cloudflare.com/a/account/my-account
API_KEY="your-api-key"
EMAIL="your.email@example.com"
if [ -f /tmp/CERTBOT_$CERTBOT_DOMAIN/ZONE_ID ]; then
ZONE_ID=$(cat /tmp/CERTBOT_$CERTBOT_DOMAIN/ZONE_ID)
rm -f /tmp/CERTBOT_$CERTBOT_DOMAIN/ZONE_ID
fi
if [ -f /tmp/CERTBOT_$CERTBOT_DOMAIN/RECORD_ID ]; then
RECORD_ID=$(cat /tmp/CERTBOT_$CERTBOT_DOMAIN/RECORD_ID)
rm -f /tmp/CERTBOT_$CERTBOT_DOMAIN/RECORD_ID
fi
# Remove the challenge TXT record from the zone
if [ -n "${ZONE_ID}" ]; then
if [ -n "${RECORD_ID}" ]; then
curl -s -X DELETE "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
-H "X-Auth-Email: $EMAIL" \
-H "X-Auth-Key: $API_KEY" \
-H "Content-Type: application/json"
fi
fi
ACMEサーバーの変更
デフォルトでは、Certbotはhttps://acme-v01.api.letsencrypt.org/にある Let's Encryptの初期運用サーバーを使用し ます。サーバーのACMEディレクトリのURL を使用--serverしてコマンドラインまたは構成ファイルで提供することで、 Certbotに別のCAを使用するように指示できます。たとえば、Let's Encryptの新しいACMEv2サーバーを使用したい場合は、コマンドラインに追加します。Certbotは、提供されたURLで提供されたコンテンツに基づいて、使用するACMEプロトコルのバージョンを自動的に選択します。--server https://acme-v02.api.letsencrypt.org/directory
--server新しいバージョンの仕様を実装するACME CAを指定するために使用する場合は、ワイルドカードドメインの証明書を入手できる可能性があります。一部のCA（Let's Encryptなど）では、DNSレコードを変更してワイルドカードドメインのドメイン検証を行う必要があるため、dns-01チャレンジタイプを使用する必要があります。このチャレンジタイプをサポートするCertbotプラグインのリストとその使用方法については、プラグインを参照してください。
ファイルをロックする
検証を処理するとき、Certbotはシステム上に多数のロックファイルを書き込み、複数のインスタンスが互いの変更を上書きしないようにします。つまり、デフォルトではCertbotの2つのインスタンスは並行して実行できません。
Certbotが使用するディレクトリは設定可能なので、Certbotは使用するすべてのディレクトリに対してロックファイルを作成します。これはCertbotのを含め--work-dir、--logs-dirと--config-dir。デフォルトでは、これらは/var/lib/letsencrypt、/var/log/letsencrypt、および/etc/letsencrypt それぞれ。さらに、Apacheまたはnginxと一緒にCertbotを使用している場合は、そのプログラムの設定フォルダがロックされます/etc。通常、このフォルダはディレクトリにもあります。
これらのロックファイルは他のプロセスではなく、Certbotの他のインスタンスがそれらのディレクトリを使用することを防ぐだけであることに注意してください。Certbotの複数のインスタンスを同時に実行したい場合は--work-dir、として--logs-dir、および--config-dir実行したいCertbotのインスタンスごとに異なるディレクトリを指定する必要があります。
設定ファイル
Certbotは、そのオプションをCertbotのすべての呼び出しに適用するグローバル構成ファイルを受け入れます。証明書固有の設定の選択肢は、にある.conf ファイルに設定する必要があります/etc/letsencrypt/renewal。
デフォルトではcli.iniファイルは作成されません。作成後、この設定ファイルの場所を（またはそれ以下）で指定することが可能 です。設定ファイルの例を以下に示します。certbot --config cli.ini-c cli.ini
# This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Certbot with
# "--help" to learn more about the available options.
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.
# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
# Uncomment and update to register with the specified e-mail address
# email = foo@example.com
# Uncomment to use the standalone authenticator on port 443
# authenticator = standalone
# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
# authenticator = webroot
# webroot-path = /usr/share/nginx/html
デフォルトでは、次の場所が検索されます。
/etc/letsencrypt/cli.ini$XDG_CONFIG_HOME/letsencrypt/cli.ini（または 設定されていない~/.config/letsencrypt/cli.ini場合$XDG_CONFIG_HOME）。
この設定ファイルはcertbotのすべての呼び出しに適用されるので、その中にドメインをリストするのは正しくありません。cli.iniにドメインをリストすると、更新が機能しなくなる可能性があります。さらにcli.iniの引数がどのように解析されるかのために、設定したくないオプションはリストされるべきではありません。falseに設定されたオプションは、代わりに設定ファイルにリストされているので、Certbotの古いバージョンではtrueに設定されていると解釈されます。
ログローテーション
デフォルトでは、certbotはステータスログを保存します/var/log/letsencrypt。ログディレクトリに1000個のログがあると、デフォルトでcertbotはログのローテーションを開始します。つまり、1000個のファイルが/var/log/letsencryptCertbotに入ると、新しいログ用のスペースを空けるために最も古いファイルが削除されます。後続のログの数は、必要な数をコマンドラインフラグに渡すことによって変更できます --max-log-backups。
注意
DebianやUbuntuを含むいくつかのディストリビューションは、より伝統的なlogrotateスクリプトを支持してcertbotの内部ログローテーションを無効にしています。ディストリビューションのパッケージを使用していて、ログローテーションを変更したい場合/etc/logrotate.d/は、certbotローテーションスクリプトを確認してください。
Certbotのコマンドラインオプション
Certbotは多くのコマンドラインオプションをサポートしています。こちらからの完全なリスト です：certbot --help all
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
enhance Add security enhancements to your existing configuration
-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 or --cert-name)
delete Delete a certificate
manage your account with Let's Encrypt:
register Create a Let's Encrypt ACME account
unregister Deactivate a Let's Encrypt ACME account
update_account Update 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)
--eab-kid EAB_KID Key Identifier for External Account Binding (default:
None)
--eab-hmac-key EAB_HMAC_KEY
HMAC key for External Account Binding (default: None)
--cert-name CERTNAME Certificate name to apply. This name is used by
Certbot for housekeeping and in file paths; it doesn't
affect the content of the certificate itself. To see
certificate names, run 'certbot certificates'. When
creating a new certificate, specifies the new
certificate's name. (default: the first provided
domain or the name of an existing certificate on your
system for the same domains)
--dry-run Perform a test run of the client, obtaining test
(invalid) certificates but not saving them to disk.
This can currently only be used with the 'certonly'
and 'renew' subcommands. Note: Although --dry-run
tries to avoid making any persistent changes on a
system, it is not completely side-effect free: if used
with webserver authenticator plugins like apache and
nginx, it makes and then reverts temporary config
changes in order to obtain test certificates, and
reloads webservers to deploy and then roll back those
changes. It also calls --pre-hook and --post-hook
commands if they are defined because they may be
necessary to accurately simulate renewal. --deploy-
hook commands are not called. (default: False)
--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
"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.35.1
(certbot(-auto); OS_NAME OS_VERSION) Authenticator/XXX
Installer/YYY (SUBCOMMAND; flags: FLAGS)
Py/major.minor.patchlevel). 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)
--reuse-key When renewing, use the same private key as the
existing certificate. (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')
--no-permissions-check
(certbot-auto only) skip the check on the file system
permissions of the certbot-auto script (default:
False)
-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)
--auto-hsts Gradually increasing max-age value for HTTP Strict
Transport Security security header (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)
--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: )
--https-port HTTPS_PORT
Port used to serve HTTPS. This affects which port
Nginx will listen on after a LE certificate is
installed. (default: 443)
--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-v02.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 or
--cert-name
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)
--disable-renew-updates
Disable automatic updates to your server configuration
that would otherwise be done by the selected installer
plugin, and triggered when the user executes "certbot
renew", regardless of if the certificate is renewed.
This setting does not apply to important TLS
configuration updates. (default: False)
--no-autorenew Disable auto renewal of certificates. (default: True)
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, along with
all previous and later versions of those certificates.
(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
--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)
-m EMAIL, --email EMAIL
Email used for registration and recovery contact. Use
comma to register multiple emails, ex:
u1@example.com,u2@example.com. (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)
update_account:
Options for account modification
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
enhance:
Helps to harden the TLS configuration by adding security enhancements to
already existing configuration.
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 are
using DNS Made Easy for DNS). (default: False)
--dns-gehirn Obtain certificates using a DNS TXT record (if you are
using Gehirn Infrastracture Service for DNS).
(default: False)
--dns-google Obtain certificates using a DNS TXT record (if you are
using Google Cloud DNS). (default: False)
--dns-linode Obtain certificates using a DNS TXT record (if you are
using Linode for DNS). (default: False)
--dns-luadns Obtain certificates using a DNS TXT record (if you are
using LuaDNS for DNS). (default: False)
--dns-nsone Obtain certificates using a DNS TXT record (if you are
using NS1 for DNS). (default: False)
--dns-ovh Obtain certificates using a DNS TXT record (if you are
using OVH for DNS). (default: False)
--dns-rfc2136 Obtain certificates using a DNS TXT record (if you are
using BIND for DNS). (default: False)
--dns-route53 Obtain certificates using a DNS TXT record (if you are
using Route53 for DNS). (default: False)
--dns-sakuracloud Obtain certificates using a DNS TXT record (if you are
using Sakura Cloud for DNS). (default: False)
apache:
Apache Web Server plugin (Please note that the default values of the
Apache plugin options change depending on the operating system Certbot is
run on.)
--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)
--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)
--apache-ctl APACHE_CTL
Full path to Apache control script (default:
apache2ctl)
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-gehirn:
Obtain certificates using a DNS TXT record (if you are using Gehirn
Infrastracture Service for DNS).
--dns-gehirn-propagation-seconds DNS_GEHIRN_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-gehirn-credentials DNS_GEHIRN_CREDENTIALS
Gehirn Infrastracture Service credentials 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-linode:
Obtain certs using a DNS TXT record (if you are using Linode for DNS).
--dns-linode-propagation-seconds DNS_LINODE_PROPAGATION_SECONDS
The number of seconds to wait for DNS to propagate
before asking the ACME server to verify the DNS
record. (default: 1200)
--dns-linode-credentials DNS_LINODE_CREDENTIALS
Linode credentials INI file. (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-ovh:
Obtain certificates using a DNS TXT record (if you are using OVH for DNS).
--dns-ovh-propagation-seconds DNS_OVH_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-ovh-credentials DNS_OVH_CREDENTIALS
OVH credentials INI 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)
dns-sakuracloud:
Obtain certificates using a DNS TXT record (if you are using Sakura Cloud
for DNS).
--dns-sakuracloud-propagation-seconds DNS_SAKURACLOUD_PROPAGATION_SECONDS
The number of seconds to wait for DNS to propagate
before asking the ACME server to verify the DNS
record. (default: 90)
--dns-sakuracloud-credentials DNS_SAKURACLOUD_CREDENTIALS
Sakura Cloud credentials file. (default: None)
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. 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
--nginx-server-root NGINX_SERVER_ROOT
Nginx server root directory. (default: /etc/nginx or
/usr/local/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:
{})