TLS 証明書と HTTPS

HTTPS は、Passkey、OIDC コールバック、インターネットで公開する多くのサービスの基盤です。証明書は、訪問者が実際に使用する認証 Host とサービス用 Host をカバーする必要があります。内部アドレスや古いドメイン名だけを対象に証明書を発行しても、ゲートウェイではブラウザーの警告やログイン失敗が発生します。

ページ構成と証明書の取得元

SSL / HTTPS は 3 つのタブに分かれています。

タブ	管理する内容
証明書設定	現在の HTTPS 状態、ゲートウェイへの展開モード、手動アップロード、証明書ストア
自己署名証明書	ローカルルート CA と、その CA が発行するドメイン / IP 用サーバー証明書
ACME 証明書 / DNS-01 証明書	複数の申請設定、発行、更新、ログ、証明書ストアとの関連付け

取得元	適した用途	注意事項
既存の証明書をアップロード	CDN、管理パネル、その他のツールですでに証明書を発行済み	証明書チェーンと秘密鍵を一緒に保存し、更新責任の所在を記録する
自己署名証明書	LAN 内のテストや一時的な検証	クライアント側で手動の信頼設定が必要で、一般的なインターネット公開には不向き
ACME	検証可能なドメインがあり、自動更新を使用したい	現在の申請フローは DNS-01 を使用するため、DNS API 認証情報を保護する

証明書ストアと手動アップロード

アップロード欄には PEM 証明書と秘密鍵を直接貼り付けられます。共有ディレクトリを利用できるプラットフォームでは、共有ファイルから読み込むこともできます。証明書と秘密鍵は一致する必要があり、証明書チェーンにはサーバー証明書と必要な中間証明書を含めてください。

保存時には 2 つの操作があります。

操作	結果
証明書ストアのみに保存	検証してストアへ追加するだけで、現在公開中の証明書は変更しない
保存して有効にする	ストアへ追加し、現在有効な証明書またはデフォルトのフォールバック証明書に設定して、直ちにゲートウェイへ同期する

証明書ストアには、取得元、対象ドメイン、有効期間、更新日時、Host のカバレッジが表示されます。使用中の証明書を削除すると、HTTPS も同時に無効になります。証明書ストアをクリア を実行すると、すべての証明書とゲートウェイが受信済みの証明書セットが削除され、HTTPS も無効になります。一時的に HTTPS だけを停止する場合は、状態カードの HTTPS を無効化 を使用してください。証明書はストアに残ります。

単一の有効な証明書と複数の証明書 SNI

証明書ストアには複数の証明書を保持できますが、ゲートウェイへ実際に送信される枚数は 展開モードとゲートウェイ同期 で決まります。

展開モード	ゲートウェイの動作	適した用途
単一の有効な証明書	現在有効な証明書だけを送信し、すべてのドメインで同じ証明書を返す	1 枚のワイルドカード証明書または SAN 証明書ですべての Host をカバーする
複数の証明書 SNI	証明書セット全体を送信し、TLS SNI に基づいてドメインに合う証明書を選択する	異なる親ドメインや異なる取得元の証明書で 1 つのゲートウェイを共有する

複数の証明書 SNI でも、デフォルトのフォールバック証明書が 1 枚必要です。クライアントが SNI を送信しない場合、不明な Host にアクセスした場合、または一致する証明書がない場合、ゲートウェイはデフォルトの証明書を返します。展開モードを切り替えた後は、ページの ゲートウェイが現在受信している証明書のセット を確認してください。保存済みモードと実行中のモードが一致しない場合や同期エラーがある場合は、証明書ストアの内容だけで適用済みと判断しないでください。

サブドメイン構成では、認証 Host とインターネットへ公開するすべてのサービス用 Host をカバーする必要があります。ワイルドカード *.example.com がカバーするのは 1 階層のサブドメインだけで、ルートドメイン example.com や a.b.example.com は対象外です。ページの Host カバレッジ分析では、現在のマッピングをもとに不足している項目が表示されます。

外部ツールから証明書を受信する

証明書設定 → 外部証明書を受信 では、証明書の発行と更新を Certd、acme.sh、lego、または Certbot に任せ、完全な証明書チェーンと秘密鍵を fn-knock へプッシュできます。この受信先から CA へ証明書を申請することはありません。fn-knock は認証、証明書の検証、証明書ストアへの保存、および必要に応じたゲートウェイ更新を担当します。

次のような環境に適しています。

• Certd ですでに複数のドメイン、VPS、NAS、CDN の証明書を一元管理している
• 既存の acme.sh、lego、Certbot 更新ジョブを維持し、DNS API 認証情報を fn-knock に重複保存したくない
• 1 枚の発行済み証明書を複数の fn-knock インスタンスへ配布する必要がある
• fn-knock ホスト自身は DNS-01 を実行できないが、内部ネットワークから証明書を受信できる

動作モデル

1 回の完全な展開は次の順序で実行されます。

1. 外部ツールが CA から証明書を発行または更新します。
2. 発行成功後、Webhook または deploy hook が fullchain と秘密鍵をバインド専用の URL へ送信します。
3. fn-knock はバインドの Bearer Token で認証し、リクエストサイズ、PEM、完全な証明書チェーン、有効期間、証明書と秘密鍵の一致を検証します。
4. 証明書は固定スロット external_<binding_id> に保存されます。以後の更新は常に同じストア記録を置き換え、更新のたびに証明書が増えることはありません。
5. その証明書が使用中なら、有効／デフォルトの役割を維持して直ちにゲートウェイを更新します。使用中でなければ、既存のデフォルト証明書を奪いません。複数の証明書 SNI モードでは証明書セット全体を再同期します。
6. ゲートウェイ同期が成功すると、受信先に最終受信時刻、ドメイン、有効期限が表示されます。同期に失敗した場合は非 2xx を返し、fn-knock は以前の設定の復元を試みます。外部ツールはその展開を失敗として記録し、設定したポリシーで再試行してください。

fn-knock に現在の証明書が 1 枚もない場合、外部受信先から最初に正常受信した証明書が自動的に有効化され、ゲートウェイへ送信されます。すでに別の現在の証明書がある場合、新しい受信先への初回プッシュは証明書ストアへの追加だけを行います。公開デフォルトを置き換えるときは、証明書ストアから手動で有効化してください。

ツール	fn-knock が生成する設定	実行タイミング
Certd	PUT Webhook URL、Header、JSON テンプレート、成功判定文字列	Certd の証明書パイプラインに「Webhook 方式で証明書をデプロイ」ステップを追加
acme.sh	URL と Token を含む deploy hook スクリプト	発行後に --deploy-hook fnknock を実行
lego	lego v5 deploy hook と v4 renew hook に対応するスクリプト	更新コマンドまたは .lego.yaml から実行
Certbot	RENEWED_LINEAGE を読む deploy hook スクリプト	renewal hook ディレクトリへ配置するか、certbot renew --deploy-hook から実行

証明書の受信先を作成する

1. SSL 証明書 → 証明書設定 を開き、外部証明書を受信 を展開します。
2. 証明書ツール で Certd、acme.sh、lego、または Certbot を選択します。
3. Certd example.com や Certbot gateway-01 のように、証明書または対象ノードを識別できる名前を入力します。
4. 受信先を作成 をクリックします。
5. 生成された設定をすぐにすべてコピーします。Token は作成時または Token 再生成時に 1 回だけ表示され、設定欄を閉じた後に再表示することはできません。

1 つの受信先には 1 つの固定証明書スロットと独立した Token があります。無関係な複数の証明書を同じ受信先へ送ると、後のプッシュが前の証明書を置き換えます。複数の fn-knock インスタンス間でも Token を共有せず、各インスタンスで受信先を作成してください。

公開、LAN、ループバック入口を選ぶ

プッシュ入口には、HTTPS 認証 Host 経由の公開 URL、明示的に許可した RFC1918 アドレスとゲートウェイポートを使う LAN HTTPS、同一ホスト用のループバック互換 URL があります。別端末やクラウドでは、管理ポートを公開せずに使える /__certificates__/<BINDING_ID> を推奨します。LAN は非ループバック監視と既定証明書が必要で、最大 16 IPv4 を許可できます。IP と証明書名が一致しない場合の -k は選択した LAN だけで使い、公開入口では使用しません。

すべての入口は同じ Token と検証を共有します。Token は任意 SAN を展開し、同じ SAN の既存証明書を引き継げるため、証明書管理者資格情報として扱い、漏えい時は直ちにローテーションしてください。

ループバック互換入口と BACKEND_PORT

生成される URL は次の形式です。

http://127.0.0.1:7998/api/integrations/certificates/<BINDING_ID>

ポートは fn-knock の実行時 BACKEND_PORT から取得され、7998 はデフォルト値にすぎません。管理バックエンドはデフォルトで 127.0.0.1 と ::1 だけをリッスンします。この URL を直接使用できるのは、証明書ツールと fn-knock が同じホストまたは同じネットワーク名前空間にある場合だけです。

この互換 URL は同一ホストまたはネットワーク名前空間だけで使用します。ホストのループバックは隔離コンテナ内を指しません。別端末では公開認証 Host 入口か明示的に有効化した LAN 入口を使い、BACKEND_PORT を公開しないでください。Token を URL、Query String、Access Log、デバッグ出力に記録しないでください。

Certd Webhook を設定する

Certd 用の受信先を作成した後、fn-knock に表示された値を対応する Certd 証明書パイプラインへコピーします。

1. パイプラインに、ドメイン証明書を正常に出力する申請タスクがあることを確認します。
2. 申請タスクの後に Webhook 方式で証明書をデプロイ ステップを追加します。
3. ドメイン証明書 には、直前の申請タスクの出力を選択します。無関係な証明書を選ばないでください。
4. 次の表の値を入力してパイプラインを保存します。

Certd の項目	値	説明
タスク名	fn-knock へ証明書をプッシュ	対象ノード名を含めても構いません
Webhook URL	fn-knock に表示されたプッシュ URL	ツールの位置に応じて公開 HTTPS、LAN HTTPS、ループバックを選択
リクエスト方式	PUT	POST に変更しない
ContentType	application/json	Certd が JSON として送信するために必要
Headers	Authorization=Bearer fnk_cert_<YOUR_TOKEN>	この Certd 欄は key=value 形式。完全な Token を fn-knock からコピーする
メッセージ Body テンプレート	{"cert":"${crt}","key":"${key}"}	${crt} は完全な証明書内容、${key} は秘密鍵
証明書検証を無視	通常はオフ	HTTP には検証対象の TLS 証明書がない。HTTPS リバースプロキシでは可能な限り信頼チェーンを修正する
成功判定	"success":true	Response も 2xx である必要があり、非 2xx は失敗として扱う

画像の <BINDING_ID> と fnk_cert_<YOUR_TOKEN> はドキュメント用のプレースホルダーであり、そのまま使用できません。作成またはローテーション直後の受信先から実際の値をコピーしてください。Header は Authorization=Bearer ... です。一般的な HTTP 記法の Authorization: Bearer ... ではありません。この Certd 入力欄が 1 行ごとの key=value を要求するためです。

保存後、Certd パイプラインを 1 回手動実行します。Webhook ステップだけを実行する場合は、前段タスクの証明書出力を読み取れることを先に確認してください。成功すると Certd のステップが成功になり、fn-knock は "success":true を含む JSON を返し、受信先の最新状態を更新します。

acme.sh、lego、Certbot を使用する

これら 3 つでは JSON を手動作成する必要はありません。ツールを選択して受信先を作成すると、fn-knock が URL と Token を埋め込んだスクリプトを生成します。スクリプトは jq で PEM の改行を安全に JSON 化し、curl で送信します。ファイルの権限を制限し、CI ログへスクリプト内容を出力しないでください。

acme.sh

1. 生成スクリプトを ~/.acme.sh/deploy/fnknock.sh として保存します。
2. chmod 700 ~/.acme.sh/deploy/fnknock.sh を実行します。
3. 発行成功後、次を実行します。

~/.acme.sh/acme.sh --deploy -d example.com --deploy-hook fnknock

スクリプトは acme.sh deploy hook が渡す秘密鍵と fullchain を使用します。ワイルドカード証明書では、その証明書の acme.sh 上のメインドメインを指定してください。--deploy は既存の発行結果を展開する操作であり、再発行コマンドではありません。

lego

1. 生成スクリプトを固定パスへ保存し、chmod 700 /path/to/fn-knock-lego-hook.sh を実行します。
2. lego v5 では次を実行します。

lego --deploy-hook=/path/to/fn-knock-lego-hook.sh renew

.lego.yaml の hooks.deploy.command に設定することもできます。lego v4 では --renew-hook=/path/to/fn-knock-lego-hook.sh を使用します。生成スクリプトは v5 の LEGO_HOOK_* と v4 互換環境変数の両方を認識します。

Certbot

1. 生成スクリプトを /etc/letsencrypt/renewal-hooks/deploy/fn-knock として保存します。
2. chmod 700 /etc/letsencrypt/renewal-hooks/deploy/fn-knock を実行します。
3. テストするか、Hook を明示して実行します。

certbot renew --deploy-hook /etc/letsencrypt/renewal-hooks/deploy/fn-knock

スクリプトは Certbot の RENEWED_LINEAGE から fullchain.pem と privkey.pem を読みます。deploy hook は更新成功時だけ実行されます。テスト時は Certbot が提供する手順を使用し、Staging 証明書を本番証明書としてプッシュしないことを確認してください。

初回プッシュ、更新、展開ロール

プッシュ前の状態	fn-knock の動作
現在の証明書がない	固定外部証明書記録を作成し、自動的に現在の証明書に設定してゲートウェイへ同期
単一の有効な証明書モードで別の現在の証明書がある	新しい証明書をストアへ追加するが、公開証明書は変更しない
この受信先の証明書がすでに現在の証明書	同じ記録を置き換え、現在のロールを維持してゲートウェイを更新
複数の証明書 SNI モード	受信先の証明書を置き換えてセット全体を再同期し、既存のデフォルトは維持
完全に同一の証明書と秘密鍵を再送	冪等に成功し、ストアへの再書き込みや不要なゲートウェイ再読み込みを行わない
既存スロットの証明書より早く期限切れになる証明書を送信	古い証明書への誤ったロールバックを防ぐため 409 Conflict を返す

fn-knock はチェーンの順序と署名、中間証明書の CA／Key Usage、チェーン内すべての証明書の有効開始・終了時刻、およびリーフ証明書と秘密鍵の一致を検証します。必要な中間証明書の欠落、順序違い、未発効または期限切れの証明書、鍵の不一致は拒否されます。Request Body の上限は 1 MiB です。

証明書の取得元は「外部プッシュ」として記録され、source_provider で Certd、acme.sh、lego、Certbot を区別します。状態とログにはバインド、結果、Fingerprint、ドメイン、有効期間だけを記録し、PEM 秘密鍵や平文 Token は記録しません。

成功を確認する

プッシュ後は次の順序で確認します。

1. 外部ツールで証明書申請だけでなく展開タスクも成功している。
2. fn-knock の受信先が 受信中 と 前回の受信は成功 を表示し、ドメイン、最終受信時刻、有効期限が正しい。
3. 証明書ストアに受信先用の外部証明書が 1 件だけあり、再更新しても件数が増えない。
4. 公開する証明書なら、現在／デフォルトの証明書であるか、複数の証明書 SNI のゲートウェイセットに含まれている。
5. 実際のアクセス経路で返る証明書を確認する。

openssl s_client \
  -connect auth.example.com:443 \
  -servername auth.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

前回の受信は成功 は fn-knock が今回の内容を受け付けたことを示します。公開証明書になっているかは、有効ロール、展開モード、公開トラフィックが実際にこのゲートウェイへ到達するかにも依存します。

受信先と Token を管理する

• 受信を一時停止：受信先と既存証明書を保持したまま、新しいプッシュを利用不可にします。
• 新しい Token を生成：古い Token は直ちに無効になり、新しい Token は 1 回だけ表示されます。Certd または deploy hook スクリプトを更新しないと 401 になります。
• 名前を保存：表示名だけを変更し、証明書スロット、URL、Token、保存済み証明書は変わりません。
• 受信先を削除：URL と Token を無効にしますが、取り込み済みの証明書はデフォルトで残します。使用中 HTTPS の停止を避けるためです。不要な証明書は証明書ストアから別途削除します。

Token が許可するのは 1 つのバインド専用証明書スロットへの展開だけです。/api/admin/ssl/* の呼び出しや他のバインドの操作はできません。自動化に管理セッション Cookie を使用しないでください。

複数の fn-knock インスタンス

Certd から複数の VPS／NAS へ配布するときは、各 fn-knock で受信先を作成し、インスタンスごとに独立した展開ステップを追加します。

証明書を発行／更新
├── fn-knock gateway-01 へプッシュ（独立 URL + Token）
├── fn-knock gateway-02 へプッシュ（独立 URL + Token）
└── CDN または別サービスへプッシュ

これにより、1 つの Token 漏えい、到達不能なノード、ゲートウェイ同期失敗が全ノード共通の認証情報問題に拡大しません。Certd では各展開ステップの結果を個別に保持し、ラッパースクリプトで一部ノードの失敗を隠さないでください。

外部プッシュのトラブルシューティング

HTTP ステータス	主な原因	対処
400 Bad Request	JSON／PEM が不正、チェーンが不完全または順序違い、鍵不一致、未発効、期限切れ	fullchain と対応する秘密鍵を送る。Certd の ${crt}／${key} JSON テンプレートを維持する
401 Unauthorized	Token の欠落、コピー誤り、ローテーション済み、Certd Header の形式誤り	fn-knock で Token を再生成し、Authorization=Bearer ... を完全に更新する
404 Not Found	バインドが削除／一時停止済み、または URL のバインド ID が不明	受信先状態と完全なパスを確認し、別インスタンスの URL を流用しない
409 Conflict	受信証明書の期限が既存証明書より早い、または並行変更を安全に保存できない	古い成果物を送っていないか確認し、同じ受信先への同時書き込みを避けて再試行する
413 Payload Too Large	JSON Body が 1 MiB を超えた	ログ、PKCS#12、重複証明書、無関係な内容が PEM に追加されていないか確認する
500 Internal Server Error	設定または展開状態の保存に失敗	fn-knock ログとディスク／設定ストレージを確認し、外部ジョブは失敗のまま再試行する
502 Bad Gateway	検証後のゲートウェイ同期に失敗。以前の設定を復元できたか Response に表示される	現在公開中の証明書を確認し、ゲートウェイ状態と fn-knock ログを調べて再試行する

Certd で発行成功でも fn-knock が 最初の送信を待機中 のままなら、展開ステップが実行されていない、Webhook に到達できない、または前段の証明書出力選択が誤っています。Certd タスクログでリクエスト送信を確認し、同一ホストの 127.0.0.1:${BACKEND_PORT} またはホスト間のリバースプロキシ経路を確認してください。

自己署名ルート CA

自己署名証明書 は次の順序で使用します。

1. ルート証明書を初期化し、ルート CA をダウンロードします。
2. アクセスに使用するすべてのクライアントまたは管理対象デバイスへ、ルート CA を信頼済みルート証明書としてインストールします。
3. ドメインと IP の一覧に、実際にアクセスする名前を追加します。
4. 適用 をクリックしてサーバー証明書を発行・インストールするか、サーバー証明書をダウンロードして別途使用します。

サーバー証明書の有効期間は 20 年です。有効期間が長くても、秘密鍵の保護や失効時の計画を省略してよいわけではありません。ルート CA を再生成またはクリアすると、元のルート CA が発行したサーバー証明書は信頼されなくなるため、画面では 2 回の確認が必要です。実行前に、新しいルート証明書を配布する方法とロールバック手順を用意してください。

自己署名証明書は、管理された LAN、テスト用デバイス、ルート証明書を一括配布できる環境に適しています。インターネット上の訪問者、外部 OIDC、不特定のクライアントには、通常は公的に信頼される CA を使用してください。

ACME 申請設定

Windows 以外のプラットフォームで初めて使用する場合は、先に システム設定 → ACME で acme.sh を初期化し、必要に応じてデフォルトの認証局を選択します。認証局の切り替えが影響するのは、以後の申請と自動更新だけです。発行済みまたは展開済みの証明書が直ちに置き換わることはありません。

ACME の各申請設定には、次の内容が個別に保存されます。

• 名前と 1 つ以上のドメイン
• DNS プロバイダーと、その申請設定で使用する API 認証情報
• 自動更新の有効・無効
• 現在の証明書、証明書ストアとの関連付け、直近のタスク状態

保存 は申請設定だけを変更し、保存して適用 は直ちに発行タスクを送信します。発行に成功した証明書は証明書ストアへ自動同期されますが、必ずしも現在の証明書にはなりません。単一の有効な証明書モードでは、必要に応じて 現在の証明書として設定 を実行します。複数の証明書 SNI モードでは、その証明書がゲートウェイの証明書セットに含まれたことを確認してください。

同じ申請設定を更新または再申請した場合、関連付け済みの証明書ストア記録がその場で置き換えられ、元のラベルと現在有効またはデフォルトの展開ロールが維持されるため、証明書が重複して増えることはありません。ドメイン変更後の発行タスクが失敗または停止しても、以前の使用可能な発行結果は維持されます。新しい証明書をゲートウェイへ送信できなかった場合は、以前の SSL 設定を復元して再送信します。その間により新しい設定が保存されていた場合は、その新しい設定を維持して送信します。タスク自体は失敗として終了するため、ログで以前の設定を復元したのか、新しい設定を維持したのか、または安全な設定も復元できなかったのかを確認してください。

申請設定のメニューからは、タスクログの表示、証明書のダウンロード、証明書ストアの手動更新、展開、証明書の削除、申請設定の削除も行えます。2 つの削除操作では対象範囲が異なります。

操作	保持される内容
証明書を削除	申請設定は保持し、現在保存されている発行結果と証明書ストアとの関連付けを削除
申請設定を削除	申請設定を削除し、その申請設定に属する既存の証明書と関連付けも削除

タスクまたは自動更新の実行中でも、申請設定の DNS 設定は編集して保存できます。別の発行、展開、削除など、現在のタスクと競合する操作はロックされたままです。タスクログには、DNS 認証情報、DNS API のレート制限、ACME の申請回数制限など、確認すべき方向が表示されます。タスク停止は最初にキャンセルを要求し、そのタスクが所有するプロセスグループを終了します。エグゼキューターと Runtime Lock の両方が終了した後にだけ成功と表示されます。PID または停止エラーが残る場合は 2 つ目のタスクをすぐに開始せず、古いプロセスの終了を確認してください。

自動更新のスケジュールと復旧

自動更新を有効にした申請設定は、サービス起動直後に確認され、その後はデフォルトで 6 時間ごとにスキャンされます。残り有効期間が 30 日以内になると更新キューへ入り、複数の申請設定は期限が近い順に直列処理されるため、DNS API と ACME クライアントが並行実行されません。

• 自動スキャンと申請設定ごとの発行タスクは、所有者とハートビートを持つ個別の Runtime Lock を使用し、同じサービス内で重複更新を防ぎます。手動タスクが実行中なら、そのスキャンは安全にスキップされます。
• サービス再起動後、新しいプロセス内にエグゼキューターがない queued／running タスクは停止済みに復旧し、残存 Runtime Lock を削除してから再スキャンします。プロセス内でキャンセル処理中のタスクは、元のエグゼキューターの終了まで Lock を維持し、新旧タスクの重複を防ぎます。
• RFC 3339 と、既存証明書で使われる一般的な OpenSSL UTC 有効期限の両方を認識します。解析できない期限は警告を記録してスキップし、「更新不要」と誤判定しません。
• 各スキャン後に証明書ストアとゲートウェイへの配備を再同期します。1 件の更新失敗で次回以降のスキャンが止まることはなく、以前の利用可能な証明書と SSL 設定は前節の復旧規則に従って保持されます。
• 自動更新が失敗または停止した後は、デフォルトで 6 時間の再試行バックオフが適用され、各スキャンが DNS API と CA をすぐに再呼び出すことを防ぎます。その申請設定を編集すると、次回スキャンで再試行できます。

画面には独立した「次回スキャン時刻」スイッチはありません。手動申請を繰り返すのではなく、申請設定の最新タスク状態、証明書の有効期限、ログから成否を確認してください。

Windows ネイティブ版：DNS-01 証明書

Windows x86_64 版では、SSL / HTTPS → DNS-01 証明書 から証明書を申請します。証明書クライアントはインストールパッケージに組み込まれているため、ACME.sh の初期化やダウンロードは不要です。この経路では Let's Encrypt と DNS-01 検証だけを使用し、HTTP-01 や他の認証局への切り替えは利用できません。

ページでサポート対象の DNS プロバイダーを選択し、必要最小限の権限を持つ API 認証情報を保存してください。現在は Aliyun DNS、Baidu Cloud DNS、Cloudflare、DNSPod、Tencent Cloud DNSPod、DuckDNS、Dynu、dynv6、GoDaddy、Huawei Cloud DNS、Porkbun をサポートしています。Cloudflare では API Token と Global API Key の 2 種類の認証情報を利用できますが、Zone を限定した Token を優先してください。

新しい申請設定では自動更新がデフォルトで有効になり、発行に成功した証明書は証明書ストアへ追加されます。単一の有効な証明書モードでは、初回発行後に手動で現在の証明書として設定する必要があります。Windows のページでは acme.sh の初期化は不要で、認証局の切り替えもありません。

FNOS SSL 証明書同期（ネイティブ FPK のみ）

FNOS ネイティブ FPK では、システム設定 → FNOS → FNOS SSL 証明書同期 から、fn-knock の証明書ストアの内容を FNOS システムにある既存の証明書記録へ同期できます。

同期によって更新されるのは、ドメインと SAN の組み合わせが完全に一致する既存の FNOS 証明書だけです。FNOS システム内に証明書記録を新規作成したり、削除したりすることはありません。そのため、先に両方のストアで対象ドメインの組み合わせが一致していることを確認し、個別または一括で同期してください。一致する記録がない場合は、同期機能による自動作成を期待せず、先に証明書記録を調整します。

必要に応じて手動同期を実行できるほか、自動同期も有効にできます。自動モードでは、ローカルの証明書ストアが変更された後に短時間待って複数の変更をまとめ、一致する項目を同期して FNOS サービスを 1 回更新します。同期先の証明書で FNOS 側の自動更新も有効な場合は、後の更新によって同期結果が上書きされる可能性があります。どちらの側が更新を担当するか明確にしてください。

推奨設定手順

1. インターネットへ公開する最終的なドメインとポートを確定し、内部アドレスで証明書を申請しないようにします。
2. DNS で認証 Host とサービス用 Host の名前解決が反映済みであることを確認します。
3. SSL / HTTPS で証明書をアップロード、申請、または選択します。
4. 証明書の枚数に応じて単一の有効な証明書または複数の証明書 SNI を選択し、ゲートウェイが想定した証明書セットを受信したことを確認します。
5. 証明書のカバレッジ表示を確認し、対象外の Host を修正します。
6. モバイルネットワークから認証 Host とサービス用 Host の 1 つへアクセスし、ブラウザーで証明書チェーン、ドメイン、有効期間、ログインフローを確認します。

自動 HTTPS の境界

システムの自動 HTTPS が行うのは、ゲートウェイ側の HTTP から HTTPS へのリダイレクトと、設定済み証明書の有効化だけです。ドメインの申請、ルーターのポート開放、CDN のオリジン設定を代行するものではありません。Docker と OpenWrt 環境には、このホスト関連のスイッチがありません。外側のリバースプロキシで TLS を終端する場合は、外側で HTTPS を強制してください。Windows でスイッチが表示されても、実際の受信経路と利用可能なポート 80 が先に必要です。7999 がデフォルトですべてのインターフェースをリッスンすることは、Windows ファイアウォール、ルーター / NAT、通信事業者がインターネットからのアクセスを許可していることを意味しません。

トラブルシューティング

• ブラウザーにドメイン不一致と表示される：証明書の DNS 名が現在の Host をカバーしていないか、上流の CDN が誤ったサイトをオリジンとして参照しています。

• 証明書ストアに存在するのにインターネット側では古い証明書が返る：その証明書が現在有効またはデフォルトに設定されているか、展開モードが正しいか、ゲートウェイが受信済みの証明書セットが更新されたかを確認します。

• 複数のドメインで同じ誤った証明書が返る：現在も単一の有効な証明書モードになっていないか、複数の証明書 SNI に一致する証明書がなくデフォルトへフォールバックしていないかを確認します。

• アップロードに失敗する：PEM の内容、秘密鍵との一致、証明書チェーンの順序を確認し、PKCS#12 ファイルの内容を PEM テキスト欄へ貼り付けないでください。

• ACME に失敗する：DNS プロバイダーの認証情報、DNS API のレート制限、TXT レコードの伝播を確認します。現在の申請フローは DNS-01 だけを使用するため、HTTP-01 の方向で調査しないでください。

• ACME の発行に成功したが反映されない：証明書ストアとの関連付けと、単一の有効な証明書モードで 現在の証明書として設定 を実行したかを確認します。

• Cloudflared で https://localhost:7999 を使用すると失敗する：アップストリームの TLS 名と証明書が一致する必要があります。一致させられない場合は、先に検証済みの HTTP オリジン方式を使用するか、Tunnel の TLS 設定を調整してください。

• サービスページは正常だが Passkey を使用できない：認証 Host が有効な HTTPS と正しい RP ドメイン名でアクセスされているか確認します。

• DDNS 管理

• サブドメインマッピング

• Cloudflared トンネル

• システム設定とメンテナンス