Spring Boot 프로젝트 서버 배포 시 HTTPS 적용은 더 이상 선택이 아닌 필수가 되었다.
AWS나 GCP 같은 클라우드 환경이 아닌, 라즈베리파이에 직접 백엔드 서버를 배포 후 간단한 방법으로 SSL 인증서를 적용하는 방법을 작성하려 한다.
AWS를 사용하지 않고 라즈베리파이에서 운영 중인 서버에 Cloudflare를 활용해 SSL을 적용한 과정을 정리해본다.
Cloudflare를 선택한 이유
- DNS + SSL + Proxy
- 비용
- 사용자는 HTTPS(443)로만 접근
- 라즈베리파이 서버는 기존 7777 포트 유지
- Nginx 및 인증서 관리 불필요
- 설정 단순 + 유지보수 용이
전체 구조
[ 사용자 브라우저 ]
|
HTTPS (443)
|
[ Cloudflare ]
HTTP (7777)
|
[ Raspberry Pi ]
Backend Server
(Port: 7777)
- 사용자는 항상 443 (HTTPS) 로 접근
- 실제 라즈베리파이 서버는 7777 포트 유지
- 포트 변환은 Cloudflare Origin Rule에서 처리
현재는 간단하게 클라우드 플레어에서 7777로 포트를 변환 후 전송하지만 다른 방법으론 Ngnix 방식도 존재한다.
그러나 이번 프로젝트에서는 설정을 최대한 단순하게 유지하기 위해 Nginx를 사용하지 않고, Cloudflare의 Origin Rule 기능을 사용하였다.
Nginx 방식
- 라즈베리파이에 Nginx 설치 필요
- SSL 설정 필요
443 (Nginx)
↓
7777 (Backend)
1. 가비아에서 도메인 구매하기
웹을 넘어 클라우드로. 가비아
그룹웨어부터 멀티클라우드까지 하나의 클라우드 허브
www.gabia.com
- 회원가입 후 원하는 도메인을 찾아 구매

2. Cloudflare에 도메인 등록하기
https://www.cloudflare.com/ko-kr/
모든 곳에서 연결하고, 보호하고, 구축하기
복잡성과 비용을 줄이면서 직원, 애플리케이션, 네트워크를 어디에서든 더 빠르고 안전하게 만듭니다.
www.cloudflare.com
- 클라우드 플레어에 회원가입 후 도메인 온보딩을 추가해준다

- 가비아에서 구매한 도메인 입력

- 요금제 선택

- 레코드를 설정해준다
A 레코드란?
- 도메인을 IPv4 주소(서버 IP) 로 연결해주는 레코드
- 배포 한 서버의 공인 IP를 넣어주면 된다
CNAME (www)이란?
- 구매한 DNS 이름 앞에 www. 이 붙어도, 붙지 않아도 같은 서버로 접근 가능

- 레코드 설정 후 네임서버 2개의 값을 복사한다

3. 네임서버를 Cloudflare로 변경하기
1. 가비아로 돌아가 도메인 관리 -> 본인이 구매한 도메인 설정을 들어간다
2. 복사한 클라우드플레어에 네임서버를 넣어준다.

4. Cloudflare SSL 설정
- SSL/TLS 개요로 진입

- 구성으로 들어가 준다

- Cloudflare에서 SSL을 설정할 때 Cloudflare와 원본 서버(Raspberry Pi) 사이를 어떻게 암호화할 것인가 설정 가능
현재 설정은
- 원본 서버에는 암호화 없이 HTTP로 요청
- 원본 서버에 SSL 설정이 전혀 없어도 동작
실제 서비스하는 서버라면 Full로 설정하여 전체(엄격)을 사용해야 한다. ( Cloudflare Origin Certificate 설치 필요)
즉 지금은 간단하게 설정 한 상황으로 Cloudflare와 원본 서버 간 통신은 HTTP로 이루어진다.

5. Origin Rule로 포트 변경 처리
- 규칙 -> 개요

- 규칙 생성 -> Origin Rule 클릭

- 규칙 이름 입력 후 모든 수신 요청 클릭

- 배포한 서버의 PORT 번호 입력 후 배포 클릭

- HTTPS 통신 성공

다시 작성하지만 현재 설정 방식은 실제 운영을 목적으로 하는 설정이 아니므로 설정의 주의가 필요합니다 !
Cloudflare의 Flexible SSL(가변) 모드는 구성은 간단하지만,
종단 간 암호화(End-to-End Encryption)를 제공하지 않기 때문에 보안 측면에서 주의가 필요합니다.
이 구조의 문제점
- Cloudflare ↔ 서버 구간이 평문(HTTP)
- 중간에서 패킷 스니핑 가능
- 내부 네트워크가 아니라면 MITM 공격 가능성 존재
- “자물쇠”는 있지만 종단 간 암호화 아님
즉 보안적으로는 반쪽짜리 HTTPS
언제 이런 설정을 사용할 수 있을까?
- 프론트엔드 개발팀과 협업하는 과정에서, 서로 다른 개발 서버 간 통신 시 HTTPS가 아니면 요청이 차단되는 문제가 발생하는 경우가 있다.
- 이러한 상황에서 운영 목적이 아닌 개발·테스트 환경이라면 간단한 해결책으로 Flexible SSL 방식을 가볍게 사용하는 것을 고려할 수 있다.
현제 설정의(Flexible(가변)) 이득은?
- 사용자 ↔ Cloudflare 구간 보호하여 공용 환경에서 쿠키 / 세션 / 요청 내용 탈취 방지 가능
- 공용 와이파이
- 회사 네트워크
- 카페 환경
요약
- Flexible SSL은 HTTPS가 반드시 필요한 개발 환경’에서는 빠르게 적용할 수 있는 편의성 있는 선택지일 수 있다.
- 하지만 실제 운영 환경에서는 Cloudflare와 원본 서버 간 통신까지 암호화되는 Full 또는 Full (Strict) 모드를 사용하는 것이 바람직하다.