
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 용량으로는 컨테이너를 더 이상 추가 불가능한..

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 用量ではコンテナをこれ以上追加不可能な..

