ownCloudサーバーでLet's Encryptを使用してSSL/HTTPSを設定する方法

Apache VirtualHost の背後で直接ホストされている ownCloud Server インスタンスの場合、通常はパブリック ドメインをサーバーに割り当て、HTTP サイトにアクセスできるようにし、そのホスト名に対して Certbot の Apache インストーラーを実行します。たとえば、ownCloud アドレスが の場合cloud.example.com、Certbot は Let's Encrypt 証明書を要求し、 で HTTPS を提供するように Apache を設定できますsudo certbot --apache -d cloud.example.com。これに依存する前に、サイトと自動更新をテストしてください。

この手順は、ownCloudのApacheガイドで想定されているように、Ubuntu上のApacheで提供されるownCloud Classic 10.16スタイルのインストールを対象としています。ownCloud Classic 11をDockerで実行する場合、ownCloudによると、コンテナの前面にあるWebプロキシでHTTPSを設定する必要があります。ホスティングプロバイダまたはリバースプロキシが既にTLSを終端している場合は、ownCloudコンテナに証明書をインストールしようとするのではなく、そちらで証明書を設定してください。

この設定がサーバーに適合するか確認してください。

Let's Encryptは、証明書を発行する前に、要求されたドメイン名をあなたが管理していることを証明します。一般的なHTTP-01チャレンジでは、Let's Encryptは、公開HTTPポート80経由でサーバーから一時ファイルを取得できる必要があります。同じホスト名が、ownCloudサイトを提供する公開エンドポイントに解決される必要があります。その後、HTTPSトラフィックがポート443のApacheエンドポイントに到達します。

• には、などの公開ホスト名があり、cloud.example.comそのDNSレコードを制御できます。
• ホスト名は、ApacheサーバーまたはパブリックリバースプロキシのパブリックIPアドレスに解決されます。
• 受信ポート80番と443番は、関連するファイアウォール、ルーター、およびクラウドセキュリティグループを通過することが許可されています。
• Apacheは既に、そのホスト名に対応するVirtualHostを通じてownCloudサイトを提供しています。
• あなたは、パブリックなHTTPおよびHTTPSトラフィックを処理するマシンへの管理者権限を持っています。

サイトがプロキシ、ロードバランサー、コンテナホスト、またはコントロールパネルの背後にある場合は、Certbotを実行する前にパブリックTLSがどこで終了するかを確認してください。間違ったマシンに証明書をインストールしても、ブラウザとサーバー間の接続は保護されません。ownCloud Classic 11では、サポートされているDocker設計により、コンテナ内でApacheが管理され、WebプロキシにHTTPSが配置されます。

ownCloudホスト名とApacheサイトを準備する

可能な限り、専用のownCloudホスト名を使用してください。ownCloudでは、ログインに使用する各ブラウザURLが、trusted_domains設定config/config.phpファイル内の`hostname`にリストされている必要があります。IPアドレスまたは別のホスト名から`hostname`に変更する場合はcloud.example.com、新しいアドレスをテストする前に、`trusted-domains`配列の未使用のエントリに新しいホストを追加してください。誤って他のエントリを上書きしないでください。

証明書を要求する前に、プレーンな HTTP で目的の ownCloud サイトに到達できることを確認してください。Apache では、VirtualHost でServerNameディレクティブを使用して正確なホスト名を指定する必要があります。ownCloud の Apache に関する手順は、VirtualHost の設定を前提としており、Ubuntu ではサイト定義を の下に配置します/etc/apache2/sites-available/。パスとサービス名は、他のディストリビューションでは異なる場合があります。

変更する前に、アクティブなApache VirtualHostの設定をバックアップしてください。これにより、自動インストーラーが誤ったサイトを選択したり、競合するHTTPSホストを作成したりした場合に、復旧ポイントを確保できます。同じサーバー上に複数のサイトがある場合は、既存のVirtualHostを確認し、証明書がデフォルトサイトではなくownCloudホスト名に紐付けられていることを確認してください。

Apache 用の Certbot をインストールして実行します。

ご使用のオペレーティングシステムとApacheの設定に合わせて、Certbotをインストールしてください。Certbotの公式手順では、多くのLinuxディストリビューションでSnapパッケージの使用を推奨していますが、パッケージの入手可能性とサポートされているインストール方法はディストリビューションによって異なります。OSパッケージマネージャーとSnapから複数のCertbotをインストールしないでください。certbot使用するApacheプラグインが含まれているCertbotのコマンドを実行してください。

SnapがインストールされサポートされているUbuntuホストでは、Certbotの手順書には次のインストールパスが示されています。

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Certbotが既にインストールされている場合は、別のコピーを追加する前に、シェルで実行されているバージョンとインストール方法を確認してください。その他のサポートされているインストールオプションについては、最新のCertbot Apacheインストールガイドを参照してください。

ownCloudホスト名の証明書をリクエストしてインストールしてください。

sudo certbot --apache -d cloud.example.com

実際のホスト名に置き換えてくださいcloud.example.com。Certbot はドメイン検証を実行し、Apache インストーラーを使用して Apache を更新し、発行された証明書を使用するようにします。1 つの証明書で複数の名前をカバーする場合は、各名前を明示的に指定します (例: ) -d cloud.example.com -d files.example.com。リストされているすべての名前は、到達可能なエンドポイントを指し、検証に合格する必要があります。

Certbotは、HTTPリクエストをHTTPSにリダイレクトするかどうかを尋ねる場合があります。HTTPS VirtualHostが正常に動作している場合は、リダイレクトを有効にするのが適切です。ownCloudは、本番環境ではHTTPSを使用し、暗号化されていないトラフィックには恒久的なリダイレクトを設定することを推奨しています。Apacheの設定を自分で管理したい場合は、Certbotは証明書のみのモードも提供しています。ownCloudのApacheガイドを使用して証明書ファイルとVirtualHostを正しく接続し、Apacheを再起動する前に設定をテストしてください。

HTTP検証がサーバーに到達できない場合

HTTP-01 メソッドは、ポート 80 のパスを使用します。/.well-known/acme-challenge/ルーターがポート 80 を別のマシンに転送したり、ファイアウォールがそれをブロックしたり、別のプロキシがそのパスを別の場所にルーティングしたりすると、ownCloud ページが HTTPS で読み込まれていても検証が失敗する可能性があります。パブリック DNS とポート転送を確認し、ACME チャレンジが Certbot が実行されているエンドポイントと同じエンドポイントに到達することを確認してください。

ISPまたはネットワークポリシーによってポート80がブロックされている場合は、代わりにDNS-01検証を検討してください。DNS-01はDNS TXTレコードを介してドメイン制御を証明し、ワイルドカード証明書を発行できますが、更新の自動化はDNSプロバイダが適切なAPIプラグインを提供しているかどうかに依存します。範囲の狭い認証情報または別の検証ホストが利用可能な場合は、Webサーバーに広範囲のDNS認証情報を配置することは避けてください。ワイルドカード証明書にはHTTP-01のみの手順を使用しないでください。

インストール後にApacheとownCloudを検証する

メンテナンスウィンドウを閉じる前に、Apacheの設定が有効であること、およびCertbotに新しい証明書がリストされていることを確認してください。

sudo apache2ctl configtest
sudo certbot certificates

Ubuntuでは、Apacheの構文チェックが成功すれば、設定が有効であると報告されます。https://cloud.example.comブラウザで開き、ログインしてください。ブラウザにホスト名の有効な証明書が表示されていることを確認し、代表的なファイルアップロード、ダウンロード、同期クライアントをテストしてください。リダイレクトを有効にしている場合は、HTTPアドレスにアクセスし、リダイレクトループなしで同じHTTPSホスト名に遷移することを確認してください。

ownCloudのログインページで信頼できないドメインが報告された場合は、trusted_domainsサーバーの設定を確認してください。ブラウザが誤ったホスト名にリダイレクトされる場合、またはownCloudがリバースプロキシの背後でHTTPリンクを生成する場合は、プロキシの転送ホストとHTTPSヘッダー、およびownCloudのプロキシ設定を確認してください。これらの設定はプロキシのトポロジーに依存するため、理由がない限り、リバースプロキシのオーバーライド設定を直接Apacheのインストール環境にコピーしないでください。

作業完了とみなす前に、更新状況を確認してください。

Let's Encryptの標準証明書は有効期限が短いため、更新を自動化する必要があります。Certbotのインストールでは、通常systemdタイマーまたはcronジョブが提供されます。更新を事前にテストするには、以下を実行してください。

sudo certbot renew --dry-run

ドライランでは、有効な証明書を置き換えることなく更新パスを確認します。ドライランが失敗した場合は、Certbot の出力を読み、記載されている DNS、ファイアウォール、チャレンジルーティング、または Apache の問題を修正してください。オペレーティングシステムのサービスツールを使用して、タイマーまたはスケジュールされたタスクが存在することを確認してください。最初の証明書が発行されたからといって、更新が有効になっていると想定しないでください。更新に HTTP-01 を使用する場合は、ポート 80 を空けておくか、DNS-01 の自動化で必要な TXT レコードを更新できることを確認してください。

よくある選択肢と落とし穴

関連するすべてのサブドメインがHTTPS経由で正しく配信されるまでは、 HSTSを有効にしないでくださいincludeSubDomains。ホスト名のヘッダーが、ブラウザによるサブドメインの処理方法に影響を与えるためです。まず、証明書、リダイレクト、および更新を確実に設定してください。その後、ドメイン全体の構成に適したHSTSおよびその他のTLS設定に関するownCloudのセキュリティ強化ガイドラインを確認してください。

ドキュメントは2026年10月6日に確認済みです。以下の正確なファイルパスとコマンドは、Ubuntu、Apache、ownCloud Classic 10.16を前提としています。Docker、リバースプロキシ、ホスティングパネル、Nginx、およびUbuntu以外のデプロイメントでは、実際のTLSエンドポイントに関する手順が必要です。

参考資料: ownCloud 10.16: Let's Encrypt を使用した Apache の設定; ownCloud 11: HTTPS とリバースプロキシのガイダンス; ownCloud 10.16: 信頼済みドメイン; Certbot: Apache のインストールと更新; Let's Encrypt: チャレンジの種類; Let's Encrypt: ポート 80 を開いたままにする。