今回は証明書の話。証明書といえば、森村誠一の証明シリーズという小説がある。有名どころでいくと
- 野生の証明:映画は高倉健と薬師丸ひろ子が出演。噂によると怪談「杉沢村」の話のベースになったとか
- 人間の証明:映画は松田優作とジョー山中が出演。Mama Do you remember?が有名。
大抵、この手の話は、小説を読むより、映画を見ればいいのだが、この証明シリーズに限っては誰が出演していようと、絶対小説で読むべき。
野生の証明は、最後のシーンで皆殺しになるのだが、そのシーンが壮絶。最後、警官が殺人鬼になって、誰かが斧を渡す。
人間の証明は、かなりの人が出てくるのに脇役レベルですら時代を超えた、全員が相互関係をもつ。どんな脇役がいても、人間が螺旋階段のようにつながっている。映画ではとてもそこまで含められていない。読んでいてちょっと驚いた。
例えば、主人公の刑事と、ニューヨークに行った時に同行する現地刑事と犯人は元々関係がある。ただしその関係を最初はだれも気が付いていない。
閑話休題
QNAPやSynologyには、便利な証明書システムが付いている。というか、このためにだけでも買ってもいいくらい便利。証明書の取得から設置、さらに利用までできてしまう。証明書は、外部で出すときにだけで使うものと考えている人がいるかもしれないが、今のソフトウェア全部証明書ありきで動いている。なのでちゃんとした証明書がないと、回避するための設定が必要だったりする。それにLAN側をゼロトラストで組むならやはり社内でもきっちり証明書を使うべきだと思う。最近思うのがデモ画面でブラウザの表示で自己証明書だったりすると、そのデモは怪しいなぁと思うようにになってきた。特に自己証明書の状態のデモでセキュリティを語っているシーンとか。中間者攻撃とかは考えていないのかな?と思ってしまう。
まずは、QNAP編
QNAPの証明書を調べても、ちゃんとまとまっているページが無かったので、まとめてみた。
まとめるとQNAPで証明書を使う場合
-
myqnapcloud.comのFQDNで使う。(3種類のドメイン名から選択可能)
-
自分のドメインのFQDNで使う
の2通りのうちどれか1つを選ぶ必要がある。
QNAP における証明書取得・運用方式の比較表
|
項目
|
myQNAPcloud.com + Let’s Encrypt
|
自ドメイン + Let’s Encrypt
|
自ドメイン + 持ち込み証明書
|
|---|---|---|---|
|
利用ドメイン
|
xxxx.myqnapcloud.com
|
自身のドメイン
|
自身のドメイン
|
|
設定場所
|
myQNAPcloud Link
|
Control Panel
|
Control Panel
|
|
操作の簡単さ
|
非常に簡単
|
簡単
|
簡単
|
|
名前解決(DNS)
|
myQNAPcloud が自動管理
|
自身で管理
|
自身で管理
|
|
IPアドレスと80/443 の外部露出
|
不要(DDNS + QNAP連携)
|
必要(HTTP-01)
|
不要(証明書取得済み)
|
|
外部公開リスク
|
低
|
中
|
低
|
|
証明書費用
|
無料(※myQNAPcloud 有償版あり)
|
無料
|
基本有償
|
|
Let’s Encrypt 利用
|
○
|
○
|
×
|
|
証明書更新
|
自動
|
自動
|
手動
|
|
更新失敗リスク
|
非常に低
|
環境依存
|
人為ミス依存
|
|
柔軟性(SAN / Wildcard)
|
低
|
中〜高
|
高
|
|
法人・商用向き
|
△
|
○
|
◎
|
|
想定用途
|
個人 / 簡易運用
|
個人〜小規模運用
|
法人 / 本番運用
|
ひとことでまとめると
-
楽したい・事故りたくない → myQNAPcloud + LE
-
自ドメインを使いたい・無料で回したい → 自ドメイン + LE
-
統制・監査・本番重視 → 自ドメイン + 持ち込み
FQDNにこだわらないのであれば、
- myqnapcloud.comでLets encryptを使う
- こだわるのであれば、自身で用意して定期的に更新をする必要がある。
証明書に関して、あまり得意でなければ、myqnapcloud.comが楽。
myQNAPcloud.comでの名前解決の設定
証明書をLet’s encryptで取るならば、myQNAPcloud.comの証明書だろうが、自ドメイン名だろうが設定しておいたほうが楽。
myQNAPcloudには、DDNSクライアントが入っている。

これは何気に便利で自ドメインのDNSにNASを登録する際、エイリアスで組めてしまう。
AWS Route53の例

ちなみに、DNSがパブリックIPv4を返している。なので、家のLAN内からアクセスをすると、ルータのWAN側のIPv4にアクセスをしてしまう。
ルータによってはこのようなアクセスを許していない。あるいは、ルータの設定でヘアピン(トロンボーン)NATを設定しておく。(EdgeRouterにはあるが、他はどうなんだろうか?)

あるいは、IPv6化をしておけば、LAN内からつながると思う。
自分の環境は、ヘアピンNATが有効でIPv6も有効なので、どっちが効いているかはわからない。
ただし、QNAP再起動直後にアクセスをすると、ヘアピンNATがうまく処理されないことがある。
究極の手段としては、
hostsファイルあるいは、内部DNSにIPv4あるいはIPv6のアドレスを書いてしまったほうがいいかも
192.168.x.x xxxx.myqnapcloud.com
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX xxxx.myqnapcloud.com
として登録しておけばいい。この後に説明をする、SSL証明書は、IPアドレスではなく、FQDNを証明するだけなので、アクセスするときのFQDNと証明書に書かれているFQDNが合致していれば、証明書アクセスは機能する。
あるいは、もし、設置場所がIPv6環境であるならば、いっそのこと潔く、名前解決はIPv4をオフにして、IPv6だけにしてしまえば、NATとか関係なり、内部DNSへの登録やhostファイルの追記も不要になる。IPv6だけに。
(今は、携帯回線もIPv6で、多くの回線がIPv6対応なので、ファイヤーウォール以外の条件で繋がらないとすれば、フレッツなのにIPv6を設定していない一般家庭、あるいは、わざとIPv6を切っている企業ネットワークくらいだと思う。)

QNAPに証明書をインストールする
QNAPにはデフォルトの自己証明書しか入っていない。

この状態だと、無効なのをクリックして受け入れるか、Chrome系の場合は、呪文を空打ちしないとログインができない。
xxxx.myqnapcloud.comのSSL証明書を入れるには
自ドメインの証明書は、ここでは登録できない。あくまでもQNAPが持っている、myqnapcloud.comの証明書となる。
myQNAPcloud Linkでは以下の証明書を入れることができる
-
有償の証明書(2026/3/14までは398日のがもらえるが、段階的に短くなって2029/3/15からは47日となる)
-
Let’s Encryptは無償の証明書。3か月しか有効期限がないが、自動で更新してくれる。
証明書自体、有効期限はどんどん短くなっていき、ブラウザも有効期間の長い証明書は受け入れなくなりつつあるので、3か月といえでも今や普通の長さ。
また、有償か無償かの違いは、有償はお金を払った分だけ保証が付くと思えばいい。無償のものは何かあっても補償はされない。
(昔、1ドルの証明書というのがあったが、契約書には、何かあっても1ドルしか保証をしてくれないという記載があった。)

Let’s Encryptの場合は、以下に必要な情報を入れる

成功すると以下のようになる。

ブラウザからアクセスすると

自ドメインの証明書(例えば xxx.example.com)を入れるには
Control Panel -> System -> Security -> SSL Certificate & Private key
先ほど入れた、myqnapcloud.comの証明書が登録されている。

Replace Certificateをクリックすると、証明書をインポート、Let’s Encryptを使う、自己証明書を入れるか選べる。

証明書をインポートする場合
証明書、プライベートキー、中間証明書を指定してApplyをクリックして完了。

注意:Lets Encryptで中間証明書をいれなくても動いてしまうことがあるが、入れないと端末によっては証明書が認識されないことがあるので、必ずすべてを入れること。
また、中間証明書の有効期限も毎回確認すること。中間証明書の有効期限が切れた場合のデバックは本当に大変。
Lets Encryptの証明書を使う場合
インターネット側から、NASに対して、TCP 80, 443を開けてあげる必要がある。そうしないと失敗する。
これはかなりリスクが高いのでお勧めしない。もし、どうしてもということなら、Let’s Encryptのドメイン証明書を作成して、通常の証明書としてインポートをしたほうがいい。
自己証明書を使う場合
自己証明書を使う場合に関しては割愛。
これらの操作をする場合は、httpサーバを再起動させる必要がある。
証明書ファイルの実態
証明書ファイルの実態は一体どこにあるか?
/etc/stunnel/stunnel.pem
にある。これを使えばいいのだが、更新とかの時に少し面倒。
さて、これで証明書の話は終わりだが、ここで終わってしまうと、セキュアな自己満足で終わってしまう。
QNAPのリバースプロキシ
QNAPにはリバースプロキシがついている。リバースプロキシーは、ホスト名、IPアドレスなどを書き換えてくれるというもので説明はもはや不要だと思うが、なぜNASにリバースプロキシが付いていると何が便利なのか?
NASのFQDNを利用した割り振りをしてくれる。つまり、NASの証明書を利用して、Virtualization StationのVMややContainer Stationのコンテナがアクセスができる。
以下は、jellyfinで利用している例

Jellyfinをhttpsで使う場合は、前段にリバースプロキシを入れてくれと書いてある。コンテナでnginxを立てればいいのだが、そのnginxにも証明書をいれなければならない。一度だけの証明書の導入なら問題ないが、頻繁に更新させるとなると面倒な時もある。
しかし、QNAPにはリバースプロキシがあるので、httpsをjellyfinのhttpに振り分けてあげれば簡単にhttps化できる。それも証明書の管理は、NAS側だけでいい。
別の用途としては、DockerのContainer Registry。Container Registryは、httpsにしておかないと、docker pullするホスト、端末やkubernetsの各ノードで、証明書を無効にする設定を入れておかなければならない。地味に面倒。しかし、このリバースプロキシを使えば簡単にhttps化ができるので、ホスト、端末の設定を変える必要はない。
ここまでマスターすれば、NASは完全に正規の証明書で利用することができる。自己証明書とオサラバ。