
SSL 認証書ドメイン適用成功後期
初期には夜明けに何回も試みたが失敗した.
原因は gateway 設定間違いだったし, 該当の部分を直した後正常に SSL 認証書が適用された.
SSL 認証書ドメイン適用はウェブサイトと使用者の間のデータを 暗号化して
HTTPS 接続ができるようにする核心保安作業だ.
現在は
-
Apache ウェップサーバー正常動作
-
HTTPS 接続問題なし
-
無料 2次ドメイン 環境でも SSL 適用完了
すなわち, サーバー ・ ドメイン ・ 認証書構成が皆安定的に連動された状態だ.
が位なら “個人クルラウドサーバー保安 1次関門”はこぎれいにパスしたわけです.
次の段階では
-
HSTS 適用
-
HTTP → HTTPS 強制リデ−レックション
-
認証書自動更新(cron)
同じことさえ取りそらえればかなりがっちりしている構成です.
SSL vs TLS 関係整理
1 歴史的観点
-
SSL (Secure Sockets Layer)
→ 過去に使われた暗号化プロトコル
→ 現在は完全に廃棄される -
TLS (Transport Layer Security)
→ SSLの後続標準
→ 現在実際に使われる唯一の方式
2 どうしてまだ “SSL”と呼ぼうか?
慣行的な表現
-
HTTPS = “SSL 適用”
-
SSL 認証書 = TLS 認証書
-
SSL 設定 = TLS 設定
業界イディオムで残っているだけ,
実際通信は全部 TLSです
IOTでは TLSと用語を言っていたからしばらく混乱..
SSLがすぐ TLS となるわけだ.
—————————-
計画は IOT 器機とウェップサーバーと通信.
良い方向です. 今構成なら充分に安定的に行くことができます.
IoT 器機 ⇔ ウェップサーバー通信 基準で整理して見れば核心は下です.
1 基本構造
IoT 器機 → サーバー
-
HTTPS(REST API)
-
MQTT(TCP / TLS)
-
WebSocket(WSS)
サーバー役目
-
Apache (プロキシ or API エンドポイント)
-
認証・権限管理
-
データ保存(DB)
-
ダッシュボード(Web UI)
2 推薦アキテクチャー (現状況基準)
もう言及したように Mosquitto + Apache 調合が一番效率的です.
通信
-
IoT → Mosquitto (MQTT over TLS)
-
ウェップサーバー → Mosquitto 購読
-
ウェブダッシュボード → サーバー API
[ IoT センサー ]↓ MQTT(TLS)[ Mosquitto ]↓[ サーバーアプリケーション ]↓[ DB / Nextcloud / Web UI ]
3 保安ポイント (重要)
もう SSLを成功したから半分は終わりました.
通信保安
-
MQTT over TLS (8883)
-
サーバー認証書再使用可能
-
器機別 ID / トピック権限分離
認証
-
器機ごとに:
-
client ID
-
username / password
または -
client 認証書
-
4 ウェップサーバー連動方式
方法 A (一番有り勝ち)
-
Apache → 内部 API (Python / Node / PHP)
-
APIが MQTT subscribe
方法 B (軽く)
-
Mosquitto → webhook → Apache
5 拡張計画まで考慮すれば
-
センサー数増加 → MQTT 必須
-
リアルタイムグラフ → WebSocket
-
外部接続 → HTTPS + 防火壁 + フォト最小化
今使う 低電力ミニ PC + 無料 2次ドメイン + SSL 調合は
個人 IoT サーバーではほとんど教科書的な構成です.
願えば次に
-
Mosquitto TLS 設定例示
-
IoT 器機認証戦略
-
Apache ⇔ MQTT 実際連動例題

16g msata 用量ではコンテナをこれ以上追加不可能な..

