ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Add goosefarminvesting domain recovery docs

Browse Source
This commit is contained in:
happybell80 2026-03-12 14:07:05 +09:00
parent 6593af1532
commit fa657f3e85
5 changed files with 308 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
journey/README.md
View File

@ -46,6 +46,7 @@
- [23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구](./troubleshooting/260310_23gateway_monitor_url_구주소잔존_24monitor프록시실패_복구.md)
- [24 자동배포 0초 종료와 runtime SSOT 불일치 이슈](./troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md)
- [51123 포트경계 복잡성 및 진입구조불일치 이슈](./troubleshooting/260311_51123_포트경계_복잡성_및_진입구조불일치_이슈.md)
- [goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈](./troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md)
- [Gitea git credential helper 표준화](./troubleshooting/260309_gitea_git_credential_helper_표준화.md)
- [23서버 워크스페이스 인프라 구조정리 이슈](./troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
- [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](./ideas/260307_external_nas_companyx_sync_아이디어.md)
@ -59,12 +60,15 @@
- [23서버 워크스페이스 SSOT 구조전환 리서치](./research/260309_23서버_워크스페이스_SSOT_구조전환_리서치.md)
- [51123 포트 진입점 프로젝트 경계 리서치](./research/260310_51123_포트_진입점_프로젝트경계_리서치.md)
- [24 자동배포 0초 종료와 runtime SSOT 불일치 리서치](./research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md)
- [goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치](./research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md)
- [51123 구 IP 하드코딩 실행 경로 제거 계획](./plans/260309_51123_구IP하드코딩_실행경로제거_계획.md)
- [24서버 실서비스 운영전환 계획](./plans/260309_24서버_실서비스운영전환_계획.md)
- [24 자동배포 0초 종료 runtime SSOT 복구 계획](./plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md)
- [23서버 워크스페이스 SSOT 구조전환 계획](./plans/260309_23서버_워크스페이스_SSOT_구조전환_계획.md)
- [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 운영계획](./plans/260311_external_nas_companyx_sync_운영계획.md)
- [rb8001 24 자동배포 SSOT 복구 및 SSH 인증 수정 완료](./worklog/260311_rb8001_24자동배포_ssot복구_및_ssh인증수정_완료.md)
- [goosefarminvesting 도메인 인증서 및 nginx 정합화 계획](./plans/260311_goosefarminvesting_도메인_인증서_및_nginx_정합화_계획.md)
- [goosefarminvesting 도메인 vhost 인증서 적용 및 실도메인 검증](./worklog/260311_goosefarminvesting_도메인_vhost_인증서_적용_및_실도메인_검증.md)
- [24서버 ONNX 모델 NAS 백업 정리](./worklog/260309_24서버_onnx모델_nas백업_정리.md)
- [23제어면 gateway workspace-config 단일화](./worklog/260309_23제어면_gateway_workspace_config_단일화.md)
- [51123 구IP active runtime 제거 1차](./worklog/260309_51123_구IP_active_runtime_제거_1차.md)

112
journey/plans/260311_goosefarminvesting_도메인_인증서_및_nginx_정합화_계획.md Normal file
View File

@ -0,0 +1,112 @@
---
tags: [infra, goosefarminvesting, nginx, ssl, dns, plans]
---
# 260311 goosefarminvesting 도메인 인증서 및 nginx 정합화 계획
**상태**: 완료 (2026-03-11)
## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [260311 goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈](../troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md)
- [260311 goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치](../research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md)
- [260310 51123 포트 진입점 프로젝트 경계 리서치](../research/260310_51123_포트_진입점_프로젝트경계_리서치.md)
- [260311 goosefarminvesting 도메인 vhost 인증서 적용 및 실도메인 검증](../worklog/260311_goosefarminvesting_도메인_vhost_인증서_적용_및_실도메인_검증.md)
## 2026-03-11 완료 반영
- `goosefarminvesting.com` 전용 80/443 vhost를 추가했습니다.
- 루트 경로는 basename 유지 원칙에 따라 `https://goosefarminvesting.com/goosefarm/` 리다이렉트로 고정했습니다.
- Let's Encrypt 인증서를 `goosefarminvesting.com` 단일 SAN으로 발급했습니다.
- `/etc/nginx/sites-available/default`와 `/etc/nginx/sites-enabled/default` 불일치를 확인하고 둘 다 같은 SSOT로 동기화했습니다.
- 외부 검증 기준 HTTP/HTTPS 리다이렉트, `/goosefarm/` 200, 인증서 SAN 일치를 모두 확인했습니다.
- 후속 적용으로 인증서를 `goosefarminvesting.com + www.goosefarminvesting.com` SAN으로 확장했고, nginx `server_name`에도 `www`를 포함해 `www -> apex 301` 리다이렉트를 고정했습니다.
- 외부 검증 기준 `http://www.goosefarminvesting.com -> 301`, `https://www.goosefarminvesting.com/goosefarm/ -> 301`, SAN `DNS:www.goosefarminvesting.com`이 확인됐습니다.
## 목표
- `goosefarminvesting.com`이 51123에서 HTTP/HTTPS 모두 도메인 이름과 일치하는 방식으로 응답하게 합니다.
- 기본 서버 응답에 기대지 않고, 전용 `server_name`과 전용 인증서로 도메인 진입면을 고정합니다.
- 적용 후 실제 외부 도메인 기준으로 HTTP, HTTPS, 인증서 SAN, 콘텐츠 경로를 검증합니다.
## 변경 범위
### 1. nginx vhost 정합화
- `goosefarminvesting.com` 전용 80/443 서버 블록을 추가합니다.
- 필요 시 `www.goosefarminvesting.com`도 같은 작업 단위에서 함께 결정합니다.
- 루트 도메인에서 어떤 경로를 반환할지 고정합니다.
- 옵션 A: 기존 `/var/www/html/goosefarm` 정적 자산을 루트 도메인으로 직접 매핑
- 옵션 B: 루트는 리다이렉트하고 기존 `/goosefarm` 경로 구조를 유지
- `/api` 또는 기존 goosefarm API는 현재 `localhost:8200` 경로와 충돌 없이 이어지게 합니다.
### 2. 인증서 정합화
- `goosefarminvesting.com`용 Let's Encrypt 인증서를 발급합니다.
- `www`를 운영한다면 SAN에 함께 포함합니다.
- 기존 `ro-being.com` 인증서를 재사용하지 않고, 도메인 이름과 일치하는 인증서를 연결합니다.
### 3. 반영과 검증
- `sudo nginx -t`로 문법 검증
- `sudo systemctl reload nginx`로 반영
- 외부 기준으로 `curl -I http://goosefarminvesting.com`, `curl -I https://goosefarminvesting.com` 재확인
- `openssl s_client`로 SAN과 만료일 검증
- 실제 브라우저에서 `https://goosefarminvesting.com` 접속 시 경고 없이 의도한 화면이 뜨는지 확인
## 실행 원칙
- DNS를 다시 건드리기 전에 51123 nginx 진입면과 인증서를 먼저 정리합니다.
- HTTP 200만 보고 완료 처리하지 않습니다.
- `goosefarminvesting.com`을 `ro-being.com` 기본 서버에 얹어 임시로 숨기지 않습니다.
- 인증서 문제를 `-k` 또는 브라우저 예외 승인으로 우회하지 않습니다.
## 단계별 계획
### 1. 실제 적용 nginx 파일 확인
- `/etc/nginx/sites-enabled/*`에서 현재 적용 중인 `server_name`, `listen 443`, `ssl_certificate` 구성을 확인합니다.
- `goosefarminvesting.com` 전용 블록이 없다는 사실을 실제 운영 파일 기준으로 다시 닫습니다.
### 2. 도메인 진입 정책 결정
- 루트 도메인에서 기존 goosefarm 프런트 자산을 직접 보여줄지, 경로 리다이렉트로 둘지 결정합니다.
- 결정이 나면 `/`, `/api`, 정적 자산, 캐시 정책을 같은 vhost 안에서 정리합니다.
### 3. 인증서 발급 및 연결
- Certbot 또는 현재 운영 표준 방식으로 `goosefarminvesting.com` 인증서를 발급합니다.
- 443 블록에 새 인증서를 연결합니다.
- 80 블록은 ACME 챌린지와 HTTPS 리다이렉트 정책을 함께 정리합니다.
### 4. 반영 후 외부 검증
- `curl -I http://goosefarminvesting.com`가 의도한 리다이렉트 또는 200을 반환하는지 확인합니다.
- `curl -I https://goosefarminvesting.com`가 인증서 오류 없이 정상 응답하는지 확인합니다.
- `openssl s_client` 결과 SAN에 `goosefarminvesting.com`이 포함됐는지 확인합니다.
- 실제 브라우저에서 루트 화면, 핵심 API, 정적 파일 로딩을 확인합니다.
## 검증 계획
### 1. 설정 검증
- `server_name goosefarminvesting.com` 존재 여부
- 443 블록의 `ssl_certificate`와 `ssl_certificate_key`가 도메인 전용 경로인지 여부
- `nginx -t` 성공 여부
### 2. 외부 응답 검증
- HTTP 상태코드
- HTTPS 상태코드
- 인증서 CN/SAN
- 실제 본문이 의도한 goosefarm 페이지인지 여부
### 3. 운영 검증
- nginx reload 직후 에러 로그 이상 유무
- 인증서 자동갱신 대상 포함 여부
- 필요 시 `www` 서브도메인까지 같은 정책으로 닫혔는지 여부
## 완료 판단 기준
- 권한 DNS는 `hosting.kr`, A 레코드는 `106.254.1.37`로 유지됩니다.
- `https://goosefarminvesting.com`이 이름 일치 인증서를 제공합니다.
- 51123 nginx에 `goosefarminvesting.com` 전용 진입면이 존재합니다.
- 외부 브라우저와 CLI에서 인증서 경고 없이 의도한 콘텐츠가 열립니다.
## 남은 결정 항목
- 없습니다.
## 상위 원칙/근거 문서 연결
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)

93
journey/research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md Normal file
View File

@ -0,0 +1,93 @@
---
tags: [infra, goosefarminvesting, dns, https, nginx, research]
---
# 260311 goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치
## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [260311 goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈](../troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md)
- [260311 goosefarminvesting 도메인 인증서 및 nginx 정합화 계획](../plans/260311_goosefarminvesting_도메인_인증서_및_nginx_정합화_계획.md)
- [260310 51123 포트 진입점 프로젝트 경계 리서치](./260310_51123_포트_진입점_프로젝트경계_리서치.md)
## Facts
### 1. 현재 인터넷이 보는 권한 DNS는 FastComet이 아니라 hosting.kr이다
- 2026-03-11 외부 조회 기준 `dig +short NS goosefarminvesting.com` 결과는 아래와 같습니다.
- `ns1.hostingkr.net.`
- `ns2.hostingkr.net.`
- WHOIS에서도 `Name Server: NS1.HOSTINGKR.NET`, `Name Server: NS2.HOSTINGKR.NET`로 확인됩니다.
- 따라서 이 시점의 실제 DNS SSOT는 FastComet Zone Editor가 아니라 `hosting.kr` 네임서버입니다.
### 2. A 레코드는 이미 `106.254.1.37`로 전환됐다
- 2026-03-11 외부 조회 기준 `dig +short A goosefarminvesting.com` 결과는 `106.254.1.37`입니다.
- 따라서 사용자 설명 중 "현재 인터넷이 172.104.94.112를 본다"는 상태는 2026-03-11 시점에는 더 이상 유효하지 않습니다.
### 3. HTTP는 51123 nginx 기본 진입면으로 응답한다
- `curl -I http://goosefarminvesting.com` 결과는 `HTTP/1.1 200 OK`, `Server: nginx`입니다.
- 본문 첫 줄 확인 결과는 Vite 정적 자산을 로드하는 HTML이며, 현재 51123 nginx가 어떤 정적 프런트엔드 페이지를 반환하고 있습니다.
- 로컬 설정 파일 `infra/nginx/sites-available/default`에는 80번 포트 `default_server`가 있고 `root /var/www/html/robeing`, `server_name _;`가 설정돼 있습니다.
- 이 구성은 `goosefarminvesting.com` 전용 80번 블록이 없을 때 기본 서버가 응답하는 현재 관측과 일치합니다.
### 4. HTTPS는 `ro-being.com` 인증서를 반환한다
- `curl -I https://goosefarminvesting.com`는 `SSL: no alternative certificate subject name matches target host name 'goosefarminvesting.com'`로 실패합니다.
- `openssl s_client ... | openssl x509 -noout -subject -issuer -dates -ext subjectAltName` 결과는 아래와 같습니다.
- `subject=CN = ro-being.com`
- `issuer=Let's Encrypt R12`
- `notBefore=Mar 11 09:13:15 2026 GMT`
- `notAfter=Jun 9 09:13:14 2026 GMT`
- `SAN: DNS:git.ro-being.com, DNS:ro-being.com`
- 즉 443 응답 자체는 살아 있지만, `goosefarminvesting.com` 이름을 포함하지 않는 다른 도메인 인증서를 제공하고 있습니다.
### 5. 로컬 nginx 기준 파일에는 goosefarminvesting 전용 443 서버 블록이 보이지 않는다
- `infra/nginx/sites-available/default` 검색 기준 `goosefarminvesting.com` 문자열은 없습니다.
- 같은 파일의 443 서버 블록은 `server_name ro-being.com;`이며 인증서 경로도 아래로 고정돼 있습니다.
- `/etc/letsencrypt/live/ro-being.com/fullchain.pem`
- `/etc/letsencrypt/live/ro-being.com/privkey.pem`
- `git.ro-being.com`, `auth.ro-being.com`용 블록은 따로 존재하지만 `goosefarminvesting.com`용 블록은 없습니다.
### 6. 기존 goosefarm 서비스는 루트 도메인 전용이 아니라 경로 기반으로 운영돼 왔다
- `infra/nginx/sites-available/default`에는 `location /goosefarm` 정적 서빙과 `location /goosefarm/api/ -> localhost:8200/api/` 프록시가 존재합니다.
- 기존 포트/진입점 문서도 `goosefarminvesting`를 `nginx -> 8200 직접` 구조로 설명하지만, 도메인 전용 vhost까지는 아직 고정하지 않았습니다.
### 7. `www.goosefarminvesting.com`은 DNS는 연결됐지만 vhost와 인증서가 없다
- 2026-03-11 외부 조회 기준 `dig +short CNAME www.goosefarminvesting.com` 결과는 `goosefarminvesting.com.`입니다.
- `dig +short A www.goosefarminvesting.com` 결과는 `106.254.1.37`입니다.
- `curl -I http://www.goosefarminvesting.com` 결과는 `HTTP/1.1 200 OK`이며, 응답 본문은 현재 `ro-being` 기본 정적 페이지입니다.
- `curl -I https://www.goosefarminvesting.com`는 이름 불일치로 실패합니다.
- `openssl s_client -connect www.goosefarminvesting.com:443 -servername www.goosefarminvesting.com` 결과는 `subject=CN = ro-being.com`, SAN `DNS:git.ro-being.com, DNS:ro-being.com`입니다.
- 즉 `www`는 DNS 관점에서는 goosefarminvesting apex를 따라오지만, nginx와 TLS 관점에서는 여전히 `ro-being` 기본 서버로 처리됩니다.
## Interpretation
### 1. 현재 이슈의 닫힌 원인은 DNS가 아니라 51123 HTTPS vhost 부재다
- DNS는 이미 `106.254.1.37`로 바뀌었으므로, 사용자가 보는 인증서 오류는 DNS 전파 지연보다 51123 nginx의 443 라우팅/인증서 부재로 해석하는 편이 맞습니다.
- 외부 관측값과 로컬 설정 파일이 같은 방향을 가리킵니다.
### 2. HTTP 성공은 서비스 완료가 아니라 기본 서버 응답일 가능성이 높다
- 80번 포트 응답이 있다는 사실만으로 `goosefarminvesting.com` 전용 진입면이 구성됐다고 볼 수는 없습니다.
- 현재는 `server_name _` 기본 서버가 페이지를 내리고 있을 가능성이 높고, 이는 도메인 정합성과 HTTPS 신뢰를 보장하지 않습니다.
### 3. 해결 포인트는 세 가지로 압축된다
- `goosefarminvesting.com`과 필요 시 `www.goosefarminvesting.com`용 `server_name` 블록 추가
- 해당 블록의 루트/프록시 정책을 기존 `/goosefarm` 자산과 어떻게 연결할지 결정
- 도메인 이름과 일치하는 Let's Encrypt 인증서 발급 및 nginx 적용
### 4. 남은 이슈는 `www` 별칭 수용 실행으로 닫혔다
- apex `goosefarminvesting.com`은 전용 vhost와 인증서로 이미 닫혔습니다.
- 남은 구조적 빈칸은 `www`가 DNS에서는 따라오지만 애플리케이션 계층에서는 수용되지 않는 점입니다.
- `www`가 `ro-being`으로 보이던 동작은 구조적으로 잘못된 fallback이었고, 실제 적용에서 `www -> apex 301`로 교정했습니다.
## Unresolved
- 이 문서 범위에서 남은 미확정 항목은 없습니다.
## 상위 원칙/근거 문서 연결
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)

63
journey/troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md Normal file
View File

@ -0,0 +1,63 @@
---
tags: [infra, goosefarminvesting, dns, https, nginx, troubleshooting]
---
# 260311 goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈
**상태**: 해결 (2026-03-11)
## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
## 관련 문서
- [Infra Journey](../README.md)
- [260310 51123 포트 진입점 프로젝트 경계 리서치](../research/260310_51123_포트_진입점_프로젝트경계_리서치.md)
- [260311 goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치](../research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md)
- [260311 goosefarminvesting 도메인 인증서 및 nginx 정합화 계획](../plans/260311_goosefarminvesting_도메인_인증서_및_nginx_정합화_계획.md)
- [260311 goosefarminvesting 도메인 vhost 인증서 적용 및 실도메인 검증](../worklog/260311_goosefarminvesting_도메인_vhost_인증서_적용_및_실도메인_검증.md)
## 문제 정의
- `goosefarminvesting.com`의 권한 DNS는 `hosting.kr` 기준으로 이미 `106.254.1.37`을 가리키지만, HTTPS 접속 시 `goosefarminvesting.com`용 인증서가 아니라 `ro-being.com` 인증서가 내려옵니다.
- 따라서 도메인 연결 자체는 51123 진입면으로 이동했지만, 외부 사용자는 HTTPS에서 이름 불일치 경고를 보게 됩니다.
## 재현 조건
- 2026-03-11 기준 외부 네트워크에서 `goosefarminvesting.com`으로 HTTP/HTTPS 접속
- 확인 명령
- `dig +short NS goosefarminvesting.com`
- `dig +short A goosefarminvesting.com`
- `curl -I http://goosefarminvesting.com`
- `curl -I https://goosefarminvesting.com`
- `openssl s_client -connect goosefarminvesting.com:443 -servername goosefarminvesting.com`
## 확인된 사실
- 권한 NS는 `ns1.hostingkr.net`, `ns2.hostingkr.net`입니다.
- A 레코드는 `106.254.1.37`입니다.
- `http://goosefarminvesting.com`은 `200 OK`로 응답합니다.
- `https://goosefarminvesting.com`은 인증서 CN `ro-being.com`을 내려주며 SAN도 `ro-being.com`, `git.ro-being.com`만 포함합니다.
- 로컬 nginx 기준 파일 `infra/nginx/sites-available/default`에는 `goosefarminvesting.com`용 `server_name` 또는 전용 `ssl_certificate` 블록이 없습니다.
- 같은 파일에는 `ro-being.com`용 443 서버 블록과 `/etc/letsencrypt/live/ro-being.com/*` 인증서 경로가 존재합니다.
- 실제 운영 파일 기준으로는 `/etc/nginx/sites-enabled/default`가 `/etc/nginx/sites-available/default`의 심볼릭 링크가 아니라 별도 파일이었고, 이 불일치 때문에 초기 반영 후에도 live 443 응답이 계속 `ro-being.com` 인증서를 유지했습니다.
## 영향 범위
- 외부 브라우저의 HTTPS 신뢰가 깨집니다.
- 검색엔진/공유 미리보기/자동 수집기 등 HTTPS 기본 클라이언트도 인증서 오류를 만날 수 있습니다.
- DNS는 이미 새 서버를 가리키므로, 남은 문제를 FastComet DNS 오설정으로 해석하면 원인을 잘못 짚게 됩니다.
## 닫힘 근거
- `goosefarminvesting.com` 전용 80/443 vhost를 추가하고, 루트 경로는 `https://goosefarminvesting.com/goosefarm/`로 리다이렉트하도록 고정했습니다.
- Let's Encrypt `goosefarminvesting.com` 인증서를 발급해 443 블록에 연결했습니다.
- `/etc/nginx/sites-available/default`와 `/etc/nginx/sites-enabled/default`를 같은 SSOT 설정으로 동기화하고 `sudo systemctl reload nginx`까지 반영했습니다.
- 외부 검증 기준 `http://goosefarminvesting.com -> 301`, `https://goosefarminvesting.com -> 301`, `https://goosefarminvesting.com/goosefarm/ -> 200`, 인증서 SAN `DNS:goosefarminvesting.com`이 확인됐습니다.
- 이후 `www.goosefarminvesting.com`도 같은 인증서 SAN과 `server_name`에 포함해 `www -> goosefarminvesting.com` 301로 정리했습니다.
- 외부 검증 기준 `http://www.goosefarminvesting.com -> 301 https://goosefarminvesting.com/`, `https://www.goosefarminvesting.com/goosefarm/ -> 301 https://goosefarminvesting.com/goosefarm/`, 인증서 SAN `DNS:www.goosefarminvesting.com`까지 확인됐습니다.
## 미확정 항목
- 현재 이 이슈 범위에서 남은 미확정 항목은 없습니다.
## 상위 원칙/근거 문서 연결
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)

36
journey/worklog/260311_goosefarminvesting_도메인_vhost_인증서_적용_및_실도메인_검증.md Normal file
View File

@ -0,0 +1,36 @@
---
tags: [infra, goosefarminvesting, nginx, ssl, worklog]
---
# 260311 goosefarminvesting 도메인 vhost 인증서 적용 및 실도메인 검증
## 관련 문서
- [260311 goosefarminvesting 도메인 DNS전환후 HTTPS 인증서불일치 이슈](../troubleshooting/260311_goosefarminvesting_도메인_DNS전환후_https_인증서불일치_이슈.md)
- [260311 goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치](../research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md)
- [260311 goosefarminvesting 도메인 인증서 및 nginx 정합화 계획](../plans/260311_goosefarminvesting_도메인_인증서_및_nginx_정합화_계획.md)
## 작업
- `infra/nginx/sites-available/default`에 `goosefarminvesting.com` 전용 80/443 vhost를 추가했습니다.
- 루트 도메인 `/`는 기존 basename 구조를 유지하기 위해 `https://goosefarminvesting.com/goosefarm/`로 리다이렉트하도록 고정했습니다.
- `sudo certbot certonly --webroot -w /var/www/html -d goosefarminvesting.com`로 인증서를 발급했습니다.
- `/etc/nginx/sites-available/default`와 `/etc/nginx/sites-enabled/default`를 같은 설정으로 동기화했습니다.
- `sudo nginx -t` 통과 후 `sudo systemctl reload nginx`로 반영했습니다.
- 후속으로 `www.goosefarminvesting.com`을 같은 vhost의 `server_name`에 추가했습니다.
- `sudo certbot certonly --webroot -w /var/www/html -d goosefarminvesting.com -d www.goosefarminvesting.com --cert-name goosefarminvesting.com --expand`로 SAN을 확장했습니다.
- `www.goosefarminvesting.com` 요청은 apex `goosefarminvesting.com`으로 301 리다이렉트되도록 고정했습니다.
## 검증
- `http://goosefarminvesting.com -> 301 Location: https://goosefarminvesting.com/goosefarm/`
- `https://goosefarminvesting.com -> 301 Location: https://goosefarminvesting.com/goosefarm/`
- `https://goosefarminvesting.com/goosefarm/ -> 200`
- `https://goosefarminvesting.com/goosefarm/api/books -> 405 Allow: GET`
- `http://www.goosefarminvesting.com -> 301 Location: https://goosefarminvesting.com/`
- `https://www.goosefarminvesting.com -> 301 Location: https://goosefarminvesting.com/`
- `https://www.goosefarminvesting.com/goosefarm/ -> 301 Location: https://goosefarminvesting.com/goosefarm/`
- `openssl s_client -connect goosefarminvesting.com:443 -servername goosefarminvesting.com` 기준
- `subject=CN = goosefarminvesting.com`
- `SAN: DNS:goosefarminvesting.com, DNS:www.goosefarminvesting.com`
- `notAfter=Jun 9 11:06:13 2026 GMT`
## 한 줄 결론
- `goosefarminvesting.com`과 `www.goosefarminvesting.com`은 이제 같은 인증서와 vhost 아래에서 동작하며, `www`는 apex로 정규화되고 루트는 `/goosefarm/` 구조를 유지한 채 HTTPS 기준으로 정상 진입합니다.