OpenSSL 3 업그레이드
Let’s Encrypt 통합 활성화
HTTPS 수동 구성
리버스 프록시 또는 로드 밸런서 SSL 종료 구성
사용자 지정 SSL 암호 사용
HTTP/2 프로토콜 구성
양방향 SSL 클라이언트 인증 활성화
HTTP 엄격 전송 보안(HSTS) 구성
사용자 정의 공개 인증서 설치
- 사용자 정의 인증서 체인 사용하기
GitLab 및 SSL작동 방식에 대한 세부정보
문제 해결

Linux 패키지 설치를 위한 SSL 구성

Tier: Free, Premium, Ultimate Offering: Self-managed

Linux 패키지는 SSL 구성을 위한 여러 일반 사용 사례를 지원합니다.

기본적으로 HTTPS는 활성화되어 있지 않습니다. HTTPS를 활성화하려면 다음을 수행할 수 있습니다:

무료 자동 HTTPS를 사용하기 위해 Let’s Encrypt를 사용합니다.
직접 인증서로 HTTPS를 수동으로 구성합니다.

프록시, 로드 밸런서 또는 기타 외부 장치를 사용하여 GitLab 호스트 이름에 대한 SSL 처리를 하는 경우,
외부, 프록시 및 로드 밸런서 SSL 종료를 참조하세요.

다음 표는 각 GitLab 서비스가 지원하는 방법을 보여줍니다.

서비스	수동 SSL	Let’s Encrypt 통합
GitLab 인스턴스 도메인	예	예
컨테이너 레지스트리	예	예
Mattermost	예	예
GitLab Pages	예	아니오

OpenSSL 3 업그레이드

버전 17.5부터,
GitLab은 OpenSSL 3을 사용합니다. 일부 오래된 TLS 프로토콜 및 암호화 설정, 또는
외부 통합을 위한 약한 TLS 인증서가 OpenSSL 3 기본값과 호환되지 않을 수 있습니다.

GitLab 17.5로 업그레이드하기 전에, OpenSSL 3 가이드를 사용하여
외부 통합의 호환성을 식별하고 평가하세요.

Let’s Encrypt 통합 활성화

기본적으로 external_url이 HTTPS 프로토콜로 설정되고 다른 인증서가 구성되어 있지 않으면
Let’s Encrypt가 활성화됩니다.

사전 요구 사항:

포트 80 및 443은 Let’s Encrypt 서버가 검증을 진행할 수 있도록 공개적으로 접근 가능해야 합니다.
검증은 비표준 포트에서 작동하지 않습니다.
환경이 비공식적이거나 공기 갭 상태인 경우, certbot (Let’s Encrypt에서 사용하는 도구)은
수동 방법을 제공하여
Let’s Encrypt 인증서를 설치할 수 있습니다.

Let’s Encrypt를 활성화하려면:

/etc/gitlab/gitlab.rb를 편집하고 다음 항목을 추가하거나 변경합니다:
```
## GitLab 인스턴스  
external_url "https://gitlab.example.com"         # 반드시 https 프로토콜 사용  
letsencrypt['contact_emails'] = ['foo@email.com'] # 선택적  

## 컨테이너 레지스트리 (선택적), 반드시 https 프로토콜 사용  
registry_external_url "https://registry.example.com"  
#registry_nginx['ssl_certificate'] = "path/to/cert"      # 반드시 없음 또는 주석 처리되어야 함  

## Mattermost (선택적), 반드시 https 프로토콜 사용  
mattermost_external_url "https://mattermost.example.com"  
```
- 인증서는 90일마다 만료됩니다. contact_emails에 지정한 이메일 주소는
  만료일이 가까워지면 경고를 받습니다.
- GitLab 인스턴스는 인증서의 기본 도메인 이름입니다.
  컨테이너 레지스트리와 같은 추가 서비스는 동일한 인증서에 대한 대체 도메인 이름으로 추가됩니다.
  위의 예에서 기본 도메인은 gitlab.example.com이고
  컨테이너 레지스트리 도메인은 registry.example.com입니다.
  와일드카드 인증서를 설정할 필요는 없습니다.
GitLab 재구성:
```
sudo gitlab-ctl reconfigure  
```

Let’s Encrypt가 인증서를 발급하는 데 실패할 경우,
문제 해결 섹션을 참조하여
가능한 솔루션을 확인하세요.

인증서 자동 갱신

기본 설치는 매달 4일 자정 이후에 갱신을 예약합니다.

분은 external_url의 값에 의해 결정되어, 업스트림 Let’s Encrypt 서버의 부하를 분산시킵니다.

명시적으로 갱신 시간을 설정하려면:

/etc/gitlab/gitlab.rb를 편집합니다:

# 매달 7일마다 12:30에 갱신
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

인증서는 30일 이내에 만료될 경우에만 갱신됩니다.
예를 들어, 매달 1일 00:00에 갱신하도록 설정하고
인증서가 31일에 만료되는 경우, 인증서는 갱신되기 전에 만료됩니다.

자동 갱신은 go-crond로 관리됩니다.
원하는 경우, /etc/gitlab/gitlab.rb를 편집하여
go-crond에 CLI 인수를 전달할 수 있습니다:

crond['flags'] = {
  'log.json' = true,
  'server.bind' = ':8040'
}

자동 갱신을 비활성화하려면:

/etc/gitlab/gitlab.rb를 편집합니다:
```
letsencrypt['auto_renew'] = false
```
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

인증서를 수동으로 갱신

다음 명령어 중 하나를 사용하여 Let’s Encrypt 인증서를 수동으로 갱신합니다:

sudo gitlab-ctl reconfigure

sudo gitlab-ctl renew-le-certs

이전 명령어는 인증서가 만료에 가까울 경우에만 갱신을 생성합니다.
갱신 중 오류가 발생하는 경우, 업스트림 속도 제한을 고려하세요.

Let’s Encrypt 외부의 ACME 서버 사용

Let’s Encrypt 외부의 ACME 서버를 사용하고,
GitLab을 구성하여 해당 서버를 사용하여 인증서를 가져올 수 있습니다.
자체 ACME 서버를 제공하는 서비스는 다음과 같습니다:

GitLab이 맞춤 ACME 서버를 사용하도록 구성하려면:

/etc/gitlab/gitlab.rb를 편집하고 ACME 엔드포인트를 설정합니다:
```
external_url 'https://example.com'
letsencrypt['acme_staging_endpoint'] = 'https://ca.internal/acme/acme/directory'
letsencrypt['acme_production_endpoint'] = 'https://ca.internal/acme/acme/directory'
```
맞춤 ACME 서버가 제공하는 경우, 스테이징 엔드포인트도 사용하세요.
스테이징 엔드포인트를 먼저 확인하면 요청을 ACME 프로덕션에提交하기 전에
ACME 구성이 올바른지 확인할 수 있습니다.
이는 구성 작업 중 ACME 속도 제한을 피하기 위해 수행합니다.

기본 값은 다음과 같습니다:
```
https://acme-staging-v02.api.letsencrypt.org/directory
https://acme-v02.api.letsencrypt.org/directory
```
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

인증서에 대체 도메인 추가

Let’s Encrypt 인증서에 대체 도메인(또는 주 대체 이름)을 추가할 수 있습니다.

이것은 번들 NGINX를 사용하여 다른 백엔드 애플리케이션을 위한 리버스 프록시로 사용하고자 할 때 유용할 수 있습니다.

대체 도메인에 대한 DNS 레코드는 GitLab 인스턴스를 가리켜야 합니다.

Let’s Encrypt 인증서에 대체 도메인을 추가하려면:

/etc/gitlab/gitlab.rb를 편집하고 대체 도메인을 추가합니다:

# 여러 도메인은 쉼표로 구분합니다
letsencrypt['alt_names'] = ['another-application.example.com']

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

주 GitLab 애플리케이션에 대해 생성된 Let’s Encrypt 인증서에는 지정된 대체 도메인이 포함됩니다. 생성된 파일은 다음 위치에 있습니다:

/etc/gitlab/ssl/gitlab.example.com.key는 키 파일입니다.
/etc/gitlab/ssl/gitlab.example.com.crt는 인증서입니다.

HTTPS 수동 구성

경고: NGINX 구성은 브라우저와 클라이언트에 대해 다음 365일 동안 HSTS를 사용하여 보안 연결을 통해 GitLab 인스턴스와만 통신하도록 지시합니다.

HTTP 엄격 전송 보안 구성을 참조하여 추가 구성 옵션을 확인하세요. HTTPS를 활성화하려면, 최소 24개월 동안 인스턴스에 대한 보안 연결을 제공해야 합니다.

HTTPS를 활성화하려면:

/etc/gitlab/gitlab.rb를 편집합니다:
1. external_url을 도메인으로 설정합니다. URL의 https를 주의하세요:
```
external_url "https://gitlab.example.com"
```
2. Let’s Encrypt 통합을 비활성화합니다:
```
letsencrypt['enable'] = false
```
  GitLab은 매 재구성 시마다 Let’s Encrypt 인증서를 갱신하려고 합니다. 수동으로 생성한 인증서를 사용할 계획이라면 Let’s Encrypt 통합을 비활성화해야 합니다. 그렇지 않으면 인증서가 자동 갱신으로 인해 덮어쓰일 수 있습니다.
/etc/gitlab/ssl 디렉토리를 생성하고 여기에서 키와 인증서를 복사합니다:
```
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/
```
이 예제에서 호스트 이름은 gitlab.example.com이므로, 리눅스 패키지 설치가 개인 키 및 공개 인증서 파일을 /etc/gitlab/ssl/gitlab.example.com.key 및 /etc/gitlab/ssl/gitlab.example.com.crt라는 이름으로 찾습니다. 원한다면 기본 SSL 인증서 위치 및 이름 변경할 수 있습니다.

SSL 오류를 방지하기 위해 클라이언트가 연결할 때 올바른 순서로 전체 인증서 체인을 사용해야 합니다: 먼저 서버 인증서, 그 다음 모든 중간 인증서, 마지막으로 루트 CA.
선택 사항. certificate.key 파일이 비밀번호로 보호되어 있는 경우, NGINX는 GitLab을 재구성할 때 비밀번호를 요청하지 않습니다. 이 경우 리눅스 패키지 설치가 오류 메시지 없이 조용히 실패합니다.

키 파일의 비밀번호를 지정하려면 비밀번호를 텍스트 파일에 저장하고 /etc/gitlab/gitlab.rb에 다음을 추가합니다:
```
nginx['ssl_password_file'] = '/etc/gitlab/ssl/key_file_password.txt'
```
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

선택 사항. 방화벽을 사용하는 경우, 인바운드 HTTPS 트래픽을 허용하기 위해 포트 443을 열어야 할 수 있습니다:

# UFW 예제 (Debian, Ubuntu)
sudo ufw allow https

# lokkit 예제 (RedHat, CentOS 6)
sudo lokkit -s https

# firewall-cmd (RedHat, Centos 7)
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld

기존 인증서를 업데이트하는 경우, 다른 프로세스를 따르세요.

HTTP 요청을 HTTPS로 리디렉션하기

기본적으로, https로 시작하는 external_url을 지정하면 NGINX는 더 이상 포트 80에서 암호화되지 않은 HTTP 트래픽을 수신하지 않습니다. 모든 HTTP 트래픽을 HTTPS로 리디렉션하려면:

/etc/gitlab/gitlab.rb 파일을 편집하세요:
```
nginx['redirect_http_to_https'] = true
```
GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```

참고: 이 동작은 Let’s Encrypt 통합을 사용할 때 기본적으로 활성화됩니다.

기본 HTTPS 포트 변경

기본 포트(443) 외에 다른 HTTPS 포트를 사용해야 하는 경우, external_url의 일부로 지정하세요:

/etc/gitlab/gitlab.rb 파일을 편집하세요:

external_url "https://gitlab.example.com:2443"

GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```

기본 SSL 인증서 위치 변경

호스트 이름이 gitlab.example.com인 경우, Linux 패키지 설치는 기본적으로 /etc/gitlab/ssl/gitlab.example.com.key라는 개인 키와 /etc/gitlab/ssl/gitlab.example.com.crt라는 공개 인증서를 찾습니다.

SSL 인증서의 다른 위치를 설정하려면:

디렉터리를 만들고, 적절한 권한을 부여한 후, .crt 및 .key 파일을 해당 디렉터리에 배치하세요:
```
sudo mkdir -p /mnt/gitlab/ssl
sudo chmod 755 /mnt/gitlab/ssl
sudo cp gitlab.key gitlab.crt /mnt/gitlab/ssl/
```
클라이언트가 연결할 때 SSL 오류를 방지하려면 올바른 순서로 전체 인증서 체인을 사용해야 합니다: 먼저 서버 인증서, 다음에는 모든 중간 인증서, 마지막으로 루트 CA입니다.

/etc/gitlab/gitlab.rb 파일을 편집하세요:

nginx['ssl_certificate'] = "/mnt/gitlab/ssl/gitlab.crt"
nginx['ssl_certificate_key'] = "/mnt/gitlab/ssl/gitlab.key"

GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```

SSL 인증서 업데이트

SSL 인증서의 내용이 업데이트되었지만 /etc/gitlab/gitlab.rb에 구성 변경이 없는 경우, GitLab을 재구성해도 NGINX에 영향을 주지 않습니다. 대신, NGINX가 기존 구성 및 새 인증서를 부드럽게 다시 로드하도록 해야 합니다:

sudo gitlab-ctl hup nginx
sudo gitlab-ctl hup registry

리버스 프록시 또는 로드 밸런서 SSL 종료 구성

기본적으로, Linux 패키지 설치는 external_url이 https://를 포함하는 경우 SSL 사용 여부를 자동 감지하고 NGINX를 SSL 종료를 위해 구성합니다. 그러나 GitLab을 리버스 프록시 또는 외부 로드 밸런서 뒤에서 실행하도록 구성하는 경우, 일부 환경은 GitLab 애플리케이션 외부에서 SSL을 종료하고 싶어 할 수 있습니다.

번들된 NGINX가 SSL 종료를 처리하지 않도록 하려면:

/etc/gitlab/gitlab.rb 파일을 편집하세요:

nginx['listen_port'] = 80
nginx['listen_https'] = false

GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```

외부 로드 밸런서는 200 상태 코드를 반환하는 GitLab 엔드포인트에 접근해야 할 수 있습니다 (로그인이 필요한 설치의 경우, 루트 페이지는 로그인 페이지로 302 리디렉션됩니다). 그런 경우, 헬스 체크 엔드포인트를 활용하는 것이 좋습니다.

Container Registry, GitLab Pages 또는 Mattermost와 같은 다른 번들된 구성 요소는 프록시 SSL에 대해 유사한 전략을 사용합니다. 특정 구성 요소의 *_external_url을 https://로 설정하고, 구성 요소 이름으로 nginx[...] 구성을 접두사로 붙입니다. 예를 들어, GitLab Container Registry 구성은 registry_로 접두사 붙여집니다:

/etc/gitlab/gitlab.rb 파일을 편집하세요:
```
registry_external_url 'https://registry.example.com'

registry_nginx['listen_port'] = 80
registry_nginx['listen_https'] = false
```
동일한 형식은 Pages(pages_ 접두사) 및 Mattermost(mattermost_ 접두사)에도 사용될 수 있습니다.
GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```
선택 사항. 리버스 프록시 또는 로드 밸런서를 구성하여 특정 헤더(예: Host, X-Forwarded-Ssl, X-Forwarded-For, X-Forwarded-Port)를 GitLab(그리고 Mattermost를 사용하는 경우 Mattermost로)로 전달해야 할 수 있습니다. 이 단계를 잊어버리면 부적절한 리디렉션 또는 “422 Unprocessable Entity” 또는 “CSRF 토큰의 진위를 확인할 수 없습니다”와 같은 오류가 발생할 수 있습니다.

AWS Certificate Manager(ACM)과 같은 일부 클라우드 제공업체 서비스는 인증서를 다운로드할 수 없습니다. 이는 GitLab 인스턴스에서 종료하는 데 사용될 수 없도록 합니다. 이러한 클라우드 서비스와 GitLab 간에 SSL이 필요할 경우, GitLab 인스턴스에서 다른 인증서를 사용해야 합니다.

사용자 지정 SSL 암호 사용

기본적으로, 리눅스 패키지는 SSL 암호를 사용하여 https://gitlab.com에서의 테스트와 GitLab 커뮤니티에서 기여한 다양한 모범 사례의 조합을 사용합니다.

SSL 암호를 변경하려면:

/etc/gitlab/gitlab.rb를 편집합니다:

nginx['ssl_ciphers'] = "CIPHER:CIPHER1"

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

ssl_dhparam 지시어를 활성화하려면:

dhparams.pem을 생성합니다:

openssl dhparam -out /etc/gitlab/ssl/dhparams.pem 2048

/etc/gitlab/gitlab.rb를 편집합니다:

nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem"

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

HTTP/2 프로토콜 구성

기본적으로, GitLab 인스턴스가 HTTPS를 통해 접근 가능하다고 지정하면 HTTP/2 프로토콜도 활성화됩니다.

리눅스 패키지는 HTTP/2 프로토콜과 호환되는 필요한 SSL 암호를 설정합니다.

자신만의 사용자 지정 SSL 암호를 지정하고 암호가 HTTP/2 암호 블랙리스트에 있을 경우, GitLab 인스턴스에 접근하려고 할 때 브라우저에서 INADEQUATE_SECURITY 오류가 표시됩니다. 이 경우, 해당 암호를 목록에서 제거하는 것을 고려하세요. 암호를 변경하는 것은 매우 특정한 사용자 지정 설정이 있는 경우에만 필요합니다.

HTTP/2 프로토콜을 활성화해야 하는 이유에 대한 더 많은 정보는 NGINX HTTP/2 백서를 확인하세요.

암호 변경이 불가능한 경우, HTTP/2 지원을 비활성화할 수 있습니다:

/etc/gitlab/gitlab.rb를 편집합니다:
```
nginx['http2_enabled'] = false
```
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

참고: HTTP/2 설정은 주요 GitLab 애플리케이션에만 적용되며, GitLab Pages, Container Registry, Mattermost와 같은 다른 서비스에는 적용되지 않습니다.

양방향 SSL 클라이언트 인증 활성화

신뢰할 수 있는 인증서로 웹 클라이언트가 인증하도록 요구하려면 양방향 SSL을 활성화할 수 있습니다:

/etc/gitlab/gitlab.rb를 편집합니다:

nginx['ssl_verify_client'] = "on"
nginx['ssl_client_certificate'] = "/etc/pki/tls/certs/root-certs.pem"

선택 사항. 클라이언트가 유효한 인증서를 가지고 있지 않다고 결정하기 전에 NGINX가 인증서 체인에서 얼마나 깊이 확인할지를 구성할 수 있습니다 (기본값은 1입니다). /etc/gitlab/gitlab.rb를 편집합니다:
```
nginx['ssl_verify_depth'] = "2"
```
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

HTTP 엄격 전송 보안(HSTS) 구성

HSTS 설정은 주 GitLab 애플리케이션에만 적용되며, GitLab Pages, Container Registry 및 Mattermost와 같은 다른 서비스에는 적용되지 않습니다.

HTTP 엄격 전송 보안(HSTS)은 기본적으로 활성화되어 있으며, 브라우저에 HTTPS를 사용하여 웹사이트에만 접속해야 한다고 알립니다. 브라우저가 GitLab 인스턴스를 방문하면, 사용자가 일반 HTTP URL(http://)을 명시적으로 입력하더라도 더 이상 안전하지 않은 연결을 시도하지 않을 것임을 기억합니다. 일반 HTTP URL은 브라우저에 의해 자동으로 https:// 변형으로 리디렉션됩니다.

기본적으로 max_age는 2년으로 설정되어 있으며, 이는 브라우저가 HTTPS를 통해서만 연결해야 한다는 것을 기억하는 시간입니다.

max age 값을 변경하려면:

/etc/gitlab/gitlab.rb를 편집합니다:
```
nginx['hsts_max_age'] = 63072000
nginx['hsts_include_subdomains'] = false
```
max_age를 0으로 설정하면 HSTS가 비활성화됩니다.
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

HSTS 및 NGINX에 대한 더 많은 정보는 https://blog.nginx.org/blog/http-strict-transport-security-hsts-and-nginx를 참조하세요.

사용자 정의 공개 인증서 설치

일부 환경은 다양한 작업을 위해 외부 리소스에 연결되며 GitLab은 이러한 연결에 HTTPS를 사용할 수 있도록 허용하고, 자체 서명된 인증서로의 연결도 지원합니다. GitLab에는 /etc/gitlab/trusted-certs 디렉토리에 개별 사용자 정의 인증서를 배치하여 추가할 수 있는 고유한 ca-cert 번들이 있습니다. 이렇게 하면 번들에 추가됩니다. 인증서는 openssl의 c_rehash 방법을 사용하여 추가되며, 이는 단일 인증서에서만 작동합니다.

Linux 패키지는 인증서 진위 확인에 사용되는 신뢰할 수 있는 루트 인증 기관의 공식 Mozilla 컬렉션을 포함하고 있습니다.

자체 서명된 인증서를 사용하는 설치에서는 Linux 패키지가 이러한 인증서를 관리할 수 있는 방법을 제공합니다. 이 방법에 대한 더 많은 기술적 세부정보는 이 페이지 하단의 세부사항을 참조하세요.

사용자 정의 공개 인증서를 설치하려면:

개인 키 인증서에서 PEM 또는 DER 인코딩된 공개 인증서를 생성합니다.
공개 인증서 파일만 /etc/gitlab/trusted-certs 디렉토리에 복사합니다. 다중 노드 설치가 있는 경우, 모든 노드에 인증서를 복사해야 합니다.
- GitLab이 사용자 정의 공개 인증서를 사용하도록 구성할 때, 기본적으로 GitLab은 .crt 확장자를 가진 인증서를 GitLab 도메인 이름으로 찾을 것으로 예상합니다. 예를 들어, 서버 주소가 https://gitlab.example.com인 경우 인증서 이름은 gitlab.example.com.crt여야 합니다.
- GitLab이 사용자 정의 공개 인증서를 사용하는 외부 리소스에 연결해야 하는 경우, 인증서를 /etc/gitlab/trusted-certs 디렉토리에 .crt 확장자로 저장합니다. 관련 외부 리소스의 도메인 이름을 기반으로 파일 이름을 지정할 필요는 없지만, 일관된 이름 지정 체계를 사용하는 것이 좋습니다.
다른 경로 및 파일 이름을 지정하려면
기본 SSL 인증서 위치 변경을 사용할 수 있습니다.
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

사용자 정의 인증서 체인 사용하기

알려진 문제로 인해 사용자 정의 인증서 체인을 사용할 경우, 서버, 중간 및 루트 인증서는 반드시 /etc/gitlab/trusted-certs 디렉토리의 별도의 파일로 나누어져 있어야 합니다.

이는 GitLab 자체 또는 GitLab이 연결해야 하는 외부 리소스가 사용자 정의 인증서 체인을 사용하는 경우 모두 해당됩니다.

예를 들어, GitLab 자체의 경우 다음을 사용할 수 있습니다:

/etc/gitlab/trusted-certs/example.gitlab.com.crt
/etc/gitlab/trusted-certs/example.gitlab.com_intermediate.crt
/etc/gitlab/trusted-certs/example.gitlab.com_root.crt

GitLab이 연결해야 하는 외부 리소스의 경우 다음을 사용할 수 있습니다:

/etc/gitlab/trusted-certs/external-service.gitlab.com.crt
/etc/gitlab/trusted-certs/external-service.gitlab.com_intermediate.crt
/etc/gitlab/trusted-certs/external-service.gitlab.com_root.crt

GitLab 및 SSL작동 방식에 대한 세부정보

Linux 패키지는 자체 OpenSSL 라이브러리를 포함하고 있으며 모든 컴파일된 프로그램(예: Ruby, PostgreSQL 등)을 이 라이브러리와 연결합니다. 이 라이브러리는 /opt/gitlab/embedded/ssl/certs에서 인증서를 찾도록 컴파일되어 있습니다.

Linux 패키지는 /etc/gitlab/trusted-certs/에 추가된 모든 인증서를 /opt/gitlab/embedded/ssl/certs에 심볼릭 링크하여 사용자 인증서를 관리합니다. 이 과정은 c_rehash 도구를 사용합니다. 예를 들어, customcacert.pem을 /etc/gitlab/trusted-certs/에 추가한다고 가정해 보겠습니다:

$ sudo ls -al /opt/gitlab/embedded/ssl/certs

total 272
drwxr-xr-x 2 root root   4096 Jul 12 04:19 .
drwxr-xr-x 4 root root   4096 Jul  6 04:00 ..
lrwxrwxrwx 1 root root     42 Jul 12 04:19 7f279c95.0 -> /etc/gitlab/trusted-certs/customcacert.pem
-rw-r--r-- 1 root root 263781 Jul  5 17:52 cacert.pem
-rw-r--r-- 1 root root    147 Feb  6 20:48 README

여기에서 인증서의 지문은 7f279c95이며, 이는 사용자 정의 인증서에 링크되어 있습니다.

HTTPS 요청을 만들면 어떤 일이 발생할까요? 간단한 Ruby 프로그램을 보겠습니다:

#!/opt/gitlab/embedded/bin/ruby
require 'openssl'
require 'net/http'

Net::HTTP.get(URI('https://www.google.com'))

비하인드에서 발생하는 일은 다음과 같습니다:

“require openssl” 줄은 인터프리터가 /opt/gitlab/embedded/lib/ruby/2.3.0/x86_64-linux/openssl.so를 로드하게 합니다.
Net::HTTP 호출은 기본 인증서 번들을 /opt/gitlab/embedded/ssl/certs/cacert.pem에서 읽으려고 시도합니다.
SSL 협상이 발생합니다.
서버는 SSL 인증서를 전송합니다.
전송된 인증서가 번들에 포함된 경우, SSL이 성공적으로 완료됩니다.
그렇지 않은 경우, OpenSSL은 미리 정의된 인증서 디렉토리 내에서 해당 지문과 일치하는 파일을 검색하여 다른 인증서를 검증할 수 있습니다. 예를 들어, 인증서에 지문 7f279c95가 있으면 OpenSSL은 /opt/gitlab/embedded/ssl/certs/7f279c95.0를 읽으려고 시도합니다.

OpenSSL 라이브러리는 SSL_CERT_FILE 및 SSL_CERT_DIR 환경 변수의 정의를 지원합니다. 전자는 로드할 기본 인증서 번들을 정의하고, 후자는 더 많은 인증서를 검색할 디렉토리를 정의합니다. 이 변수들은 trusted-certs 디렉토리에 인증서를 추가한 경우 필요하지 않을 것입니다. 그러나 어떤 이유로 설정해야 하는 경우, 환경 변수로 정의할 수 있습니다. 예를 들어:

gitlab_rails['env'] = {"SSL_CERT_FILE" => "/usr/lib/ssl/private/customcacert.pem"}

문제 해결

우리의 SSL 문제 해결 가이드를 참조하세요.

Linux 패키지 설치를 위한 SSL 구성

OpenSSL 3 업그레이드

Let’s Encrypt 통합 활성화

인증서 자동 갱신

인증서를 수동으로 갱신

Let’s Encrypt 외부의 ACME 서버 사용

인증서에 대체 도메인 추가

HTTPS 수동 구성

HTTP 요청을 HTTPS로 리디렉션하기

기본 HTTPS 포트 변경

기본 SSL 인증서 위치 변경

SSL 인증서 업데이트

리버스 프록시 또는 로드 밸런서 SSL 종료 구성

사용자 지정 SSL 암호 사용

HTTP/2 프로토콜 구성

양방향 SSL 클라이언트 인증 활성화

HTTP 엄격 전송 보안(HSTS) 구성

사용자 정의 공개 인증서 설치

사용자 정의 인증서 체인 사용하기

GitLab 및 SSL작동 방식에 대한 세부정보

문제 해결

도움말

기능 사용 가능성과 제품 평가판

도움받기