著者アーカイブ takahashi

takahashi 著者:takahashi

ついにメールサーバーがハード製品として販売される時代に!? メールサーバー専用ガジェット「Helm」

なんとメールサーバーそのものを個人宅向けの専用デバイスにして販売を開始した企業が現れました。

Helmという製品です。

Helm

誰でも簡単に自分のメールを自分で管理しセキュアに運営できるメールサーバーが作れる「Helm」- Gigazine

ドメインの取得とインターネット回線は必要ですが、その他機器は一切不要で、Helm側のクラウドゲートウェイを利用するので固定IPの割り当ても不要となっています。

Helmのコンセプトは”データのユーザー完全所有化”で、この辺りの思想はownCloudNextCloudに近いものを感じます。

一般的によく使われるフリーのメールサービスは、各サービスの管理をする企業が管理するサーバーにデータが保存されるため、企業によっては自分のメールデータを勝手に閲覧されてしまう可能性もありますし、たとえプライバシーに慎重な企業が管理していてのぞき見の心配はなかったとしても、クラッキングによるデータ流出のリスクから逃れることはできません。

一方Helmは、メールデータはすべてエンドツーエンドで暗号化され、Helm側が一切データの中身を見ることができない仕様になっているとのこと。


※写真は公式サイトをGoogle翻訳で日本語にしたものです。

さらに、端末内の暗号化を解除する唯一の秘密鍵も専用の物理ストレージになっていたり、Helm自体の起動にもセキュアブートが採用されていたりと、データ流出対策にとても気を配った設計になっていることがうかがえます。

ネット上のサービスを利用する場合と違い、いままで自宅サーバー、いわゆるオンプレミスのサーバーを手に入れるためには自力で環境を構築する必要がありました。
もっともそれが醍醐味だったりしたわけですが、最近は同じようなことがハードをそろえなくてもネット上でできるようになったため、こういったサービスを利用する人が増えていきました。

一方でオンプレミスの方は今回のHelmのような、”知識や高価な機器がなくても構築できる”系の機器が増えているような印象がありますし、今後は一般ユーザー向け製品としての路線へ進んでいくのかもしれませんね。

takahashi 著者:takahashi

[nginx小ネタ]failed (24: Too many open files)が出た時にまず確認したいこと

今回は、先日のちょっとしたやらかし談をご紹介します。

先日新しくサーバーを構築していて、nginxでバックエンドのApacheへのリバースプロキシを構築していたのですが、途中でこんなエラーに遭遇し、サイトが表示されなくなってしまいました。
logを確認するとこんなメッセージが。

accept4() failed (24: Too many open files)

いろいろ調べたところ、OSファイルディスクリプタ数上限の設定やnginxの制限の設定などを変えると解決するという情報を発見て、sysctl.confやらnginxのコンフィグやらを色々変えたのですが、何度試しても同じエラーが出続けて動作せず。

おかしいなーと思いながらもう一度設定ファイルを見返したところ、あることに気づきました。

バックエンドのApacheでは3003番ポートでListenしていて、nginxの3001番ポート経由でバックエンドのサーバーにつなげさせたかったのですが、設定ファイルには

server {
    listen       3001;
    server_name  node.example.com;

   client_max_body_size 1g;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header  X-Forwarded-Proto \$scheme;


    location / {
        proxy_pass http://localhost:3001; #←!?
    }

}

となっていました。
そう、つまりlocalhostの3003番ポートで動作しているApacheへリバースプロキシさせるはずが、あろうことかnginxが待ち受ける3001番ポート自身をまたリバースプロキシするような設定になってしまっていました。
当然、nginxの待ち受けポートをnginx自身がリバースプロキシしてしまっているので接続が無限にループしてしまい、それが原因でOSの上限を超えてしまっていたというのが今回の原因でした。

すぐに

proxy_pass http://localhost:3003;

に修正したところ、正常にページが表示されるようになりました。

見慣れないエラーが出ると慌ててついいろいろ試してしまいますが、まずは自分の凡ミスを疑ってみることも大事なんだなと思いました(;´∀`)

takahashi 著者:takahashi

普通のメールサーバーでもキャリアメールのようなプッシュ通知を可能にするIMAP IDLEとは

携帯電話やスマートフォンでキャリアメールを使用していると、何もしなくてもリアルタイムでメールを受信することができます。
一方、通常のメールサーバーからメールを受信する際、元々リアルタイム受信は一般的ではなく、ユーザーがメールサーバーに定期的に確認しに行くしかありませんでした。
ところがIMAPというメール受信のプロトコルができてから、こういった従来のメールシステムでも定期的にサーバーに確認することなくメールをリアルタイムで受信することが可能になりました。

具体的には、メールソフトがIMAPサーバーへ接続した際、特定のコマンドをクライアントが発行することで受信操作完了後もIMAPサーバーとの接続を維持し続け、新着メールがあるたびにメールサーバーからクライアントにリアルタイムで通知する仕組みになっています。

この仕組み、およびコマンドををIMAP IDLEといいます。
IMAP IDLEコマンドを使用するには、使用しているメールサーバーがIMAPに対応しており、かつIMAP IDLEコマンドにも対応している必要があります。

自分でフルコントロールできるメールサーバーがあれば、受信サーバーにdovecotなどのIMAP IDLE対応IMAPサーバーを使用することで、自分のメールサーバーに到着したメールをリアルタイムにプッシュ通知させることができます。

DovecotでIMAP IDLE を使った Pushメールを体験してみる – レンタルサーバー・自宅サーバー設定・構築のヒント

しかし、使用しているメールサーバーの管理権限を持っていない場合(通常はこの場合が多いと思います。)、IMAP IDLEに対応していないとこのプッシュ通知を利用することができません。

有名どころでは、現時点で下記のメールサービスはIMAP IDLEに対応しているようです。

・Gmail
・Yahoo!メール

そのほかのメールサービスでもIMAP IDLEが利用できるものがあるようです。各メールサービスのFAQやドキュメントを確認したり、サポートに問い合わせたり等して確認してみてください。

また、IMAP IDLEが利用できないサーバーを利用されていて、それでもIMAP IDLEをつかってプッシュ受信を実現したいということであれば、一旦他のメールサービスを受信させて、そこからIMAP IDLEを使ってプッシュさせる方法があります。

例えば、自分の場合は会社のメールサーバーはPOP3にしか対応していないため、直接IMAP接続することができません。
そこで、フリーのメールサービスであるGmailを使い、一度会社のメールサーバーのメールをPOPでGmailへ受信させ、GmailがPOPで受信した時点でIMAP IDLE経由で各端末へ通知させるような使い方をしています。

Gmailサーバーと会社のメールサーバーはPOPでやり取りしているため、実際には完全なリアルタイムではありませんが、Gmailは比較的リアルタイムに近い時間間隔でPOP受信をかけてくれるため、ほぼ数分程度の誤差でメールを受信することができます。

GmailでPOP受信設定する方法 – heteml BLOG

ただし、Gmailの場合は受信容量に上限(Google Dirveなどのサービスと共用で、1無料アカウントにつき15GB)があるので、無限にメールをため続けることができない点には注意してください。

takahashi 著者:takahashi

ついにPixel 3/Pixel 3 XL の日本発売が正式に発表!

ついに…

ついに!!!

Pixel 3/3 XL 正式発表キタ――――――――――――――――――――――(゚∀゚)――――――――――――――――――――――!!

Google Pixel 3 公式ティザーサイト

いやぁ来ましたね。

Pixel 3はAndroid開発元のGoogle自身が開発したAndroid端末の最新機種です。
見た目はGoogleのロゴが入っていること以外普通のスマートフォンなのですが、実は他のAndroidスマートフォンにはない特徴があります。

1.”Android OS開発元”のGoogleが直接ビルドした”純正のAndroid”が使える。

以前販売されていた”Nexus”シリーズ同様に開発元のGoogleが混ざりけなしのAndroidをインストールしているため、メーカーやキャリア製端末によくある”消せないアプリ”が最小限になっています。
また、メーカーによるAndroidの改造プロセスがない分Android最新版が出た時点でGoogleから直接アップデートを受け取れるため、ほかのAndroidスマホよりも早く新しいOSのバージョンが試せるのも魅力です。

2.Googleの最新機能がいち早く使える

Googleが作ったソフトウェアがそのまま入っているので、Googleが提供する新機能もいち早く試せます。
過去に、先代のPixel2に優先的に搭載された機能として、Googleアシスタント、GoogleLensなどがあります。
また、今回のPixel 3発売とともに、Googleアシスタントがユーザーの代わりに電話に応答し、迷惑電話を撃退してくれる機能も発表されました。

今後新たな機能の発表があった際も、(HWが対応していれば)Pixel 3にも優先的に提供されるとみられます。

3.カメラ性能
背面カメラは12.2 メガピクセルとSonyのXPeriaシリーズよりは劣りますが、光学ズームを搭載しており、Googleの得意分野であるAIを使用した強力な画像補正技術により、非常に綺麗な写真を撮ることができるとのこと。

また、暗いところでも綺麗に撮れるNight Sight機能、
シャッターチャンスを逃してしまっても、シャッターの前後の写真から一番良いものを後から選べる機能など、アマ以上のカメラマンも垂涎の機能がたくさん盛り込まれています。

今回の発表が特に盛り上がった理由として、こういった機能面だけではなく、日本発売が絶望視されてきたPixelシリーズの端末の日本国内発売がされた点があります。
以前の記事でも説明しましたが、日本ではNexusシリーズを最後に、Google純正の端末がしばらく発売されてきませんでした。

その分、久々の純正端末の発売決定は反響が特に大きかったようです。

最近発売されたiPhone XS/XR と単純に比較すると微妙なところではありますが、Google・Androidファンにとってはかなり魅力的な一台なのではないかなと思います。

takahashi 著者:takahashi

nginxやAmazon ALBなどのロードバランサー経由でLaravelにアクセスさせたときにHTTP/HTTPSを振り分ける方法

nginxやロードバランサーなどを使ってWebサーバーにアクセスさせた際に困るのが、一部の情報が本体のWebサーバーまで到達しない点。
特に、クライアントがHTTPでアクセスしているのか、HTTPSでアクセスしているのか、などの情報はそのままの状態で取得するのは困難です。

こういった環境と、HTTPかHTTPSどちらで接続されているのかを判定したうえでDOMのURLを書き換えるタイプの機能を持つフレームワークやプログラムとの相性は特に最悪で、Webサーバーに対してHTTPでアクセスされた時点で”クライアントからHTTPでアクセスされている”と判定して、すべてのアセットのアドレスをhttp://から始まるURLに置き換えて返してしまい、結果jsやcssが読み込めずに表示崩れや不具合になってしまうことがあります。

最近人気のLaravelもこの機構を持っており、そのままの状態でnginxやLBを間に置いてしまうと、httpsでアクセスしたときにページが正常に表示されない問題が発生してしまいます。

幸いにも、HTTPSかどうかの部分についてnginxやロードバランサーが代わりに取得し、その情報をヘッダーに含めて投げてくれる場合が多いので、今回はLaravel上でこのヘッダ情報を使って簡単にHTTP/HTTPSを判定できるようにしてみました。

Laravelプロジェクトフォルダ内の
routes/web.php
の最初あたりに、次のコードを追加します。

<?php

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

//ここから
//リバースプロキシ経由のHTTP/HTTPS判定
if(!empty($_SERVER["HTTP_X_FOWARDED_PROTO"])){ //"HTTP_X_FOWARDED_PROTO"ヘッダーが存在していたら
    if(strtoupper($_SERVER["HTTP_X_FOWARDED_PROTO"]) == "HTTP"){ //strtoupper("HTTP_X_FOWARDED_PROTO")の中身が"HTTP"だったら
        URL::forceScheme('http'); //すべてのURLをhttpに書き換える
    } else {
        URL::forceScheme('https'); //すべてのURLをhttpsに書き換える
    }
}
//ここまで

$_SERVERはPHPにおいて、サーバー情報および実行時の環境情報がすべて格納されるスーパーグローバル変数です。

$_SERVER – php.net

この中に、リクエストヘッダの中身もすべて格納されるので、その中からnginxやAmazon ALBやClassic Load BalancerがHTTP/HTTPSの情報を格納する”X_FOWARDED_PROTO”ヘッダーを参照して、どちらでアクセスされたかを判定しています。

ifを敢えてHTTPかどうかで判定している理由は万が一、”$_SERVER[“HTTP_X_FOWARDED_PROTO”]”にhttpでもhttpsでもない不正な値が入っていた場合も、とりあえずhttps://で吐き出すようにするためです。

こんな形で処理を加えてやれば、Laravelでもnginxやロードバランサーを使用していても正常にHTTPとHTTPSの切り替えが行えるようになると思います。

少しでも参考になりましたらしたら幸いです。

takahashi 著者:takahashi

VSCodeで簡単にMySQLと連携できるプラグイン”MySQL”

普段からVSCodeを使ってプログラムしているのですが、最近、DBの操作もプログラミングと同時にVSCodeから操作できないかなーと探していたところ、よさそうなものを発見しました。

MySQL – Visual Studio Marketplace

そのまんまの名前ではありますが、とても分かりやすく、使いやすいプラグインです。

インストールすると、VSCodeの左側カラムにMySQLのエリアが表示されます。

+ボタンがあるのでまずはクリックします。

上の画像のように専用のパレットが開くので、指示通りにDBへの接続情報を入力していきます。

設定が完了するとDBリストに追加されるので、目的のDBを右クリック。

New Queryをクリックします。
すると新しいタブが開くのでSQL文を入力し、
”Run MySQL Query”
をクリックします。

すると右側に実行結果が表示されます。

使い勝手もよく、とても見やすいのがいいですね。
おススメです。

takahashi 著者:takahashi

Windowsの”付箋”機能が進化! ついにWindows端末間での同期が可能に

最近PCを使っていてふと気づいたのですが、

いつの間にかWindowsの付箋機能がパワーアップしていました。

起動直後は特に今までと変わりはないのですが、
タスクバーの付箋を右クリックして出てくるメニューの”すべてのメモ”をクリックすると…

付箋を一覧にして表示、さらには検索もできます。
使い勝手がGoogle Keepに似た形になりました。

さらに、

自動同期機能も搭載されました!
これは便利ですね。

アップデートしてもデータは引き継がれるようですので、普段から付箋機能を愛用している方は是非アップデートして使ってみてはいかがでしょうか。

takahashi 著者:takahashi

ownCloud デスクトップクライアント 2.5.0 がリリース。 サーバーVer.9以下はサポート対象外に。

日本時間2018/9/18に最新版のownCloudデスクトップクライアントVer.2.5.0がリリースされました。
このアップデートを自分の環境で適用したところ、ファイル同期が一時停止され、次のような警告が表示されました。

The ServerVersion 8.1.0.8- is unsupported! Proceed at your own risk.

詳しく調べたところ、どうやらownCloudクライアント2.5.0から、リリース時点でサポート終了となっていたownCloudサーバーバージョン9以下について、接続やファイルの送受信の正常性を一切保証しない”サポート対象外”となったようです。

Desktop Client reports “Server Version 9.1.4.2 is unsupported!” – ownCloud

なお、各サーバーバージョンのサポート期限についてはこちらから確認できます。
Maintenance and Release Schedule

一番いい解決方法は、ownCloudサーバーを Ver.10以上(可能であれば最新版)へアップグレードすることですが、すぐには難しい、ということであれば
https://github.com/owncloud/client/releases
から旧バージョンのデスクトップクライアントが入手できるので、Ver.2.4.1以下のクライアントを入手し、再インストールすることで暫定的に解決することはできます。

なお、一度アップグレードした後でダウングレードすると、設定情報がすべて初期化されてしまうことがあるようですので注意が必要です。

ownCloudは新しいバージョンになればなるほど改良されているので、ownCloudサーバーを触れる権限をお持ちの方はこの機会にアップグレードしてしまうのも手かもしれません。

なお、ownCloudからフォークしたプロジェクトに
NextCloud
というものもあります。
こちらもownCloudと同様の機能を供えつつもNextcloudにしか実装されていない新機能が入っていたりもするので、こちらに移行するのもありかもしれませんね。

takahashi 著者:takahashi

Certbotでnginxプラグインを使用した際に”UnicodeDecodeError”が出てしまった場合の対処法

CentOS 6.10でCertbotのインストールとSSL証明書の取得をnginxプラグインで行った際に、下記のようなエラーが発生。

2018-10-08 15:34:01,329:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module>
    load_entry_point('letsencrypt==0.7.0', 'console_scripts', 'letsencrypt')()
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1364, in main
    return config.func(config, plugins)
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1233, in certonly
    installer, auth = plug_sel.choose_configurator_plugins(config, plugins, "certonly")
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 228, in choose_configurator_plugins
    installer = pick_installer(config, req_inst, plugins, installer_question)
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 32, in pick_installer
    config, default, plugins, question, (interfaces.IInstaller,))
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 106, in pick_plugin
    verified.prepare()
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in prepare
    return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in <listcomp>
    return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 132, in prepare
    self._initialized.prepare()
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/configurator.py", line 145, in prepare
    self.parser = parser.NginxParser(self.conf('server-root'))
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 38, in __init__
    self.load()
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 45, in load
    self._parse_recursively(self.config_root)
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 66, in _parse_recursively
    self._parse_recursively(subentry[1])
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 56, in _parse_recursively
    trees = self._parse_files(filepath)
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 207, in _parse_files
    parsed = nginxparser.load(_file)
  File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/nginxparser.py", line 123, in load
    return loads(_file.read())
  File "/usr/lib64/python3.4/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)
2018-10-08 15:34:01,331:ERROR:certbot.log:An unexpected error occurred:

どうやら、Certbot内のpythonスクリプトで何かエラーが発生しており、そのせいでSSL証明書の取得ができなくなってしまっているようです。
エラー内容をよく見ていくと

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)

とあり、どうやら文字コードの問題が発生していることは分かりました。
とりあえず調べていくと、こちらの記事を発見。

cert-bot/letsencrypt nginx `UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe3 in position 12: ordinal not in range(128)` – Qiita

どうやら、nginxの設定ファイルにコメントなどで日本語が入っていると、Let’sEncryptのnginxプラグインがその日本語部分を解釈できない(asciiコードとして解釈しようとしてしまう)のが原因のようです。

とりあえずの対策として、nginxの全設定ファイルから日本語やその他のマルチバイト文字をすべて取り除けば解決するようです。

自分の環境でもnginxからすべての日本語を取り除いたところ、正常に動作し、SSL証明書取得まで行うことができました。

ただ、Let’sEncryptを使用するから、という理由だけでnginx内のコンフィグで日本語が一切使用できないのはちょっと辛いものがあるので、改良されてほしいですね。

takahashi 著者:takahashi

Let’s Encrypt + MyDNS でワイルドカードSSL証明書を自動更新する方法

昨日の記事で、無料DDNSサービスであるMyDNSで、手動でDNSの編集をしなくてもワイルドカード証明書を取得・更新できるようになったことをお伝えしました。

今回は実際に自動的にワイルドカード証明書を取得・更新為の設定方法をご紹介したいと思います。

まず前提として、まだMyDNSに登録をしていない方は、先に登録しておく必要があります。

また、MyDNSはDDNSサービスであり、IPアドレスを定期的に書き換えることが前提の仕組みになっています。
そのため、たとえ固定のIPアドレスを取得していたとしても、定期的に向き先のIPアドレスをMyDNSに通知する必要があります。

1週間通知しないと、ドメインIPの正引きが停止し、1か月間通知しないと、アカウントが削除されてしまいますが、IPアドレスの通知はプログラムを使って通知することができるようになっていますので、通知スクリプトをcronなどで定期的に実行することで、手動のメンテナンスなしで利用の継続が可能です。

https://www.mydns.jp/?MENU=030のSTEP4にある要件さえ満たしていればどんな言語やプログラムを使ってもOKなのですが、一から作るのはちょっと面倒なので、インターネット上で有志の方が作成したサンプルコードを利用した方が確実かつ手軽なので、活用することをお勧めします。

アカウントの作成方法とIPの自動更新設定についてはネット上に参考資料が沢山出ているため今回は割愛します。

上記の手順まで完了したら、自動更新スクリプトをサーバーに入れ込んでいきます。

ターミナルを開き、次のコマンドをroot権限で実行します

cd ~ #ホームフォルダなどの作業スペースへ移動
wget 'https://github.com/disco-v8/DirectEdit/archive/master.zip' -O DirectEdit-master.zip #MyDNSの自動更新スクリプトをダウンロード
unzip DirectEdit-master.zip #ダウンロードしたZipを解凍
mv DirectEdit-master /opt/ #解凍したフォルダを/opt/に移動

次に、自動DNS書き換えの設定をしていきます。

vi /opt/DirectEdit-master/txtedit.conf

内容を下記のように書き換えます。

    $MYDNSJP_URL       = 'https://www.mydns.jp/directedit.html'; //そのまま
    $MYDNSJP_MASTERID  = 'mydnsXXXXXX'; //MyDNSユーザーID
    $MYDNSJP_MASTERPWD = 'yourmydnspasswd'; //MyDNSパスワード
    $MYDNSJP_DOMAIN = 'example.com'; //MyDNSに登録したドメイン名

権限を変更します。

cd /opt/DirectEdit-master
chown root:root ./
chmod 700 ./*.php //DNS自動更新プログラム
chmod 600 ./*.conf //設定ファイル

これで下準備はOKです。
それではMyDNS自動更新スクリプトを使ってdns-01認証でワイルドカード証明書を取得してみます。

certbot-auto certonly --manual \ #certbot-autoコマンドは環境によって名前が異なる場合があります。
--preferred-challenges=dns \
--manual-auth-hook /opt/DirectEdit-master/txtregist.php \
--manual-cleanup-hook /opt/DirectEdit-master/txtdelete.php \
-d example.com -d *.example.com \ #※左記以外のサブドメイン(たとえばa.example.com)はMyDNSのスクリプトではエラーになるため指定できません。サブドメインのSSLを取得する場合は別途従来のhttp-01認証で取得してください。
--server https://acme-v02.api.letsencrypt.org/directory \
--agree-tos -m hoge@example.com \ #Let'sEncryptからの通知を受け取るアドレスを指定します。
--manual-public-ip-logging-ok

これでおそらくワイルドカード証明書を取得できたかと思います。
一度上記のコマンドを実行してしまえば、次回以降の更新では

certbot-auto renew #環境によってコマンドが異なります。

コマンドのみを実行すれば更新することができますのでcronなどで定期実行させればサーバーが自動でSSL証明書を更新するようになります。

ワイルドカード証明書を手軽に使ってみたい、という方は是非試してみてください。