반응형
작성일: 2024년 4월 11일

 

새로 만든 Web 서비스를 운영하기 위해서 인터넷 도메인을 등록했다.

"YesNIC.com" 에서 .KR 도메인을 등록했고,

새로 등록한 Domain name에 맞는 서버 인증서(Certificate)도 발급했다.

 

SSL Certificate(인증서)을 발급하는 순서를 간단하게 정리하면 이렇다. 

  1. "https://yesnic.com/" 에서 인터넷 도메인 등록하기 (예: sejong.kr)
  2. "https://www.sslcert.co.kr/" 에서 *.sejong.kr 도메인을 위한 서버 보안 인증서 발급 요청
    1. DNS, Email 인증 방식 중에서 DNS 인증 방식으로 Domain name 소유자 임을 증명.
    2. Domain name 소유자 증명이 끝나면, 바로 내 Certificate과 Root/Chain Certificate 파일이 압축 파일 1개로 묶여서 Email 첨부로 수신됨.
  3. Email로 수신한 Certificate을 Web server에 등록하기

 

자세한 발급 절차는 아래 Web docs를 참고하면 좋다.

    https://www.sslcert.co.kr/supports/usage

 

 

SSL Certificate(인증서) 발급 비용

인증서 용도 및 도메인 범위에 따라 다르지만, 나는 Wildcard 도메인 옵션을 포함해서 10만원에 발급했다.

인증서 발급 기관, 기관 인증 범위, 도메인 범위에 따른 자세한 금액은 아래 문서를 참고하길~

    https://www.sslcert.co.kr/products

    https://www.sslcert.co.kr/products/wildcard-ssl-certificate-comparison

 

SSL Certificate 발급 심사 수준에 따른 Level 

DV(Domain Validation)

인터넷 도메인 네임의 소유 여부를 검사하고 Certificate을 발급한다.

해당 웹 사이트를 운영하는 회사의 실존 여부를 확인하지 않고 Certificate을 발급하기 때문에 신뢰성이 낮다.

OV(Organization Validation)

사업의 적법성을 검증하고 인터넷 도메인 네임의 소유 여부를 확인하고 Certificate을 발급한다.

이 OV Level의 Certificate을 설치한 Web site는 믿고 거래할 수 있다.

EV(Extended Validation)

Certificate 발급 기관(CA)이 까다롭게 기업 실체를 확인하고 EV Level의 Certificate을 발급한다.

 

지식 공유하는 수준으로 개인 웹 사이트를 운영하는 경우라면, DV Level의 Certificate도 충분하다.
그러나 기업 홍보, 신뢰성이 필요한 기관의 웹 사이트라면 OV Level의 Certificate이 있어야 Client가 믿고 접속할 수 있을 것이다.

 

 


 

 

Apache2 웹 서버에 SSL 인증서 설치하기

 

 

발급 받은 인증서 파일을 Apache2 Web Server에 복사

인증서 관련 파일을 Apache2 Web Server에 복사한다. (아래와 같은 Path에 복사)

파일 종류 파일 경로
CA Root Chain 통합 파일 /etc/apache2/ssl.crt/root-chain-bundle.pem
SSL Certificate 파일 /etc/ssl/certs/_wildcard_.my-domain.kr_20240312.crt.pem
SSL Sertificate Key 파일 /etc/ssl/private/_wildcard_.my-domain.kr_20240312.key.pem

 

mod_ssl 모듈을 활성화

아래 a2enmod 명령을 실행하여 mod_ssl 모듈을 활성화한다.

$ a2enmod ssl

$ cd /etc/apache2/sites-enabled

$ ln -s ../sites-available/default-ssl.conf

 

 

SSL 관련 설정을 추가

$ cd /etc/apache2/sites-enabled

$ vi default-ssl.conf

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin sejong-kanadaramabara-king@gmail.com
                ServerName my-domain.kr
                ServerAlias my-domain.kr
                SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
                
                ... 중간 생략 ...
                
                SSLEngine on
                
                ... 중간 생략 ...
                
                SSLCertificateFile      /etc/ssl/certs/_wildcard_.my-domain.kr_20240312.crt.pem
                SSLCertificateKeyFile   /etc/ssl/private/_wildcard_.my-domain.kr_20240312.key.pem

... 중간 생략 ...

        </VirtualHost>
</IfModule>

 

 

Apache2 Web Server를 재기동

$ systemctl restart apache2

$ systemctl status apache2

$ netstat -anp | grep apache2
tcp6       0      0 :::80                   :::*                    LISTEN      369206/apache2
tcp6       0      0 :::443                  :::*                    LISTEN      369206/apache2

 

위와 같이 TCP 443 포트를 LISTEN하고 있으면 정상적으로 SSL 적용된 것이다.

Web browser를 이용해서 https://my-domain.kr 과 같은 주소로 접속하면 보안 경고 없이 웹 페이지가 보일 것이다.

 


 

반응형

 

작성일: 2023년 8월 16일
참고 사항:
- Let’s Encrypt 는 SSL, TLS 무료로 인증서를 제공해주는 인증 기관이다.
- 인증서 유효기간이 90일이다.
- 따라서 90일이 지나기 전에 기존 인증서를 Renewal해주어야 한다.

 

자세한 발급 방법은 아래 Web Docs를 참고하기.


https://certbot.eff.org/

https://letsencrypt.org/ko/getting-started/

https://namu.wiki/w/Let's%20Encrypt

 

 

 

반응형

 


 

Case (A)

  연동할 Registry 주소가 Server 인증서의 SAN(Subject Alt Name) 리스트에 포함되지 않은 경우

연동하려는 Registry 주소가 인증서 발급 시 설정한 SAN(Subject Alternative Name) 리스트에 포함되어 있지 않으면 발생하는 인증 에러이다.

따라서 SAN(Subject Alternative Name) 리스트에 있는 주소 값으로 접속 시도해야 한다.

##
## Certificate(인증서) 만들 때, SAN(Subject Alt Name)에 없는 주소 값을 이용하여
## Container Image Registry에 접근하려고 하면, 아래와 같이 오류가 발생한다.
## 즉, Docker Registry(v2) 또는 Harbor를 구동할 때 사용한 Server Certificate이 있을 텐데,
## 그 Certificate을 만들 때 "Subject Alternative Name" 리스트에 서버의 domain name 주소나 IP Address를
## 입력했었을 것이다.
## 그 입력했던 "Subject Alt Name" 리스트 중에 아래와 같이 Registry에 접속할 때 사용한 Server의 주소 값이 없으면
## "Authenticting creds error"가 발생한다.
##

$  podman login 10.10.12.10:5000
Username: myid
Password: ~~~~~
Error: error authenticating creds for "10.10.12.10:5000": error pinging docker registry 10.10.12.10:5000: Get "https://10.10.12.10:5000/v2/": x509: cannot validate certificate for 10.10.12.10 because it doesn't contain any IP SANs


##
## 인증서의 Subject Alt Name과 동일한 값으로 Registry에 접근하면 문제 없이 접속된다.
## 즉, 아래 예제로 본다면,  "my-registry.my-domain"이 
## 인증서의 Subject Alt Name인 것이다.
##

$ podman login my-registry.my-domain:5000
Username: myid
Password: ~~~~~
Login Succeeded!

 

 

Case (B) 

  Client OS에 Server Certificate이 등록되지 않은 경우

정확히 표현하면,  Podman 명령, Docker 명령을 실행하려는 장비에 Harbor 또는 Docker Registry의 Server Certificate(인증서)가 등록되어 있지 않은 경우에 이런 Unknown Authority 에러가 발생한다.

보통 Self-signed Certificate을 사용한 경우라면, 이 인증 에러가 발생할 것이다.

심각한 에러는 아니고, Podman명령을 수행할 장비(예: Macbook, Ubuntu, Windows 10, Windows 11)에서 아래와 같이 OS에 Self-signed Certificate을 신뢰(Trust)하겠다는 명령만 수행하면 된다.

##
## podman 명령이나 docker 명령을 수행하는 Client OS 쪽에 CA로부터 Sign받은 Server Certificate 이 없는 경우,
## 아래와 같이 인증 에러가 발생한다.
##

$ podman login my-registry.my-domain:5000

Username: myid
Password: ~~~~~
Error: authenticating creds for "my-registry.my-domain:5000": 
  error pinging docker registry registry.base.twcm.cloud:5000: 
  Get "https://registry.base.twcm.cloud:5000/v2/": x509: 
  certificate signed by unknown authority

$


##
## 이럴 때는 CA에게 Sign받은 Certificate을 아래와 같이 Client OS에 복사해주고 등록(Update)하면 된다.
##
## 참고 사항:  my-server-domain.crt 파일은 Image Registry를 구동할 때 사용했던 파일이다.
##          (즉, my-server-domain.crt는 harbor 구동시 사용한 server certificate이라는 뜻이다)
##

$ cp  my-server-domain.crt  /etc/pki/ca-trust/source/anchors/my-server-domain.crt

$ update-ca-trust

$ podman login my-registry.my-domain:5000

Username: myid
Password: ~~~~~
Login Succeeded!

$

 

 

참고: 위 설명은 CentOS, RHEL을 사용할 때를 예로 든 것이고, Ubuntu OS에서 Server Certificate 등록하는 방법은 아래와 같다.
##
## Ubuntu OS를 사용하는 경우는 아래처럼 update-ca-certificates 명령을 사용해야 한다.
## Ubuntu에서 Certificate을 등록하는 방법은 CentOS, RHEL 8와 다르다.
##

$ cp  my-domain.crt  /usr/local/share/ca-certificates/domain.crt

$ update-ca-certificates

Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

$ podman login my-registry.my-domain:5000

Username: myid
Password:
Login Succeeded!

$

 

 

참고: Mac OS(OS X)에 Server Certificate 등록하는 방법
$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/my-new-root-ca.crt

 

 

 

참고: 각 OS별로 Root CA의 인증서(Certificate)를 등록, 삭제하는 방법을 설명하고 있는 블로그

 

 

root certificates 추가하기

https 디버깅할려니 필요해서.. 출처: https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html Adding trusted roo..

opencloud.kr

 

 


게시물 작성자: sejong.jeonjo@gmail.com

 

 

반응형

 


 

 

이 블로그 내용을 테스트한 날짜: 2023년 02월 17일

 

 

아래 예시처럼 따라하면, Kubernetes 자원에 대한 Metrics 정보를 볼 수 있다.

단, 아래 절차에서 "NOTE:" 라고 표시된 부분을 추가해야 한다.

 

##
## 아래 명령을 수행해서 metrics-server를 설치하기 위한 manifest file을 download한다.
##
$  curl -L https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -o components.yaml


## 
## 다운로드한 components.yaml 파일에
## "--kubelet-insecure-tls=true" 옵션을 추가한다.
##  (아래 예제를 따라하면 된다)
$  vi components.yaml
... 중간 생략 ...
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-insecure-tls=true     ## <-- NOTE: 이 부분을 추가한다.
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2
... 중간 생략 ...        


$  kubectl apply -f components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
$

$  kubectl  get  -n kube-system  pod  -l k8s-app=metrics-server
NAME                             READY   STATUS    RESTARTS   AGE
metrics-server-ddfcd777b-lktxx   1/1     Running   0          67s

$ kubectl  top  node
NAME      CPU(cores)   CPU%   MEMORY(bytes)    MEMORY%
node-69   219m         5%     23607Mi          24%
node-73   202m         5%     48753Mi          50%
node-75   173m         4%     51048Mi          52%
... 중간 생략 ...

$ kubectl  top  -n istio-system  pod --containers
POD                                     NAME                                 CPU(cores)   MEMORY(bytes)
grafana-68cc7d6d78-7kjw8                grafana                              3m           51Mi
istio-egressgateway-6cb7bdc7fb-2wg57    istio-proxy                          3m           47Mi
istio-ingressgateway-694d8d7656-fk4tw   istio-proxy                          7m           62Mi
istiod-6c68579c55-xk6cm                 discovery                            2m           80Mi
jaeger-5d44bc5c5d-rb4v6                 jaeger                               10m          3612Mi
kiali-fd9f88575-z4wrm                   kiali                                1m           131Mi
prometheus-77b49cb997-zvjm8             prometheus-server                    9m           454Mi
prometheus-77b49cb997-zvjm8             prometheus-server-configmap-reload   1m           6Mi
... 중간 생략 ...
$

 

위에서 "--kubelet-insecure-tls=true" 라고 설정을 추가했는데, 자세한 설명은 아래 원문을 참고할 것~~~

Metrics Server Pod랑 Kubelet 이랑 API 연동할 때, CA(Certificate Authority)를 검사하지 말고 연동하라는 뜻이다.

 

kubelet-insecure-tls 옵션에 대한 설명

 

 

Reference

딱히 어려운 내용이 없어서, 아래 원문을 읽고 따라해도 잘 설치되고, 동작한다.

 

GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in aut

Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines. - GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container reso...

github.com

 

반응형

  


 

공인된 CA가 아닌, 내가 CA가 되서 openssl 명령을 이용하여 Private Key를 Signing하고 Certificate을 생성하는 절차를 알아보자.

(2~3년에 한번씩 하는 작업이라서 메모하지 않으면 잊는다. 잘 메모해야지.. ㅠㅠ)

 

아래 예시 순서대로 따라서 실행하면 된다.

 

 

CA Certificate, Server Certificate 만들기

######################################################################
## 1)   Generate a Certificate Authority Certificate (CA Certificate)
######################################################################

##
## 1-a) Generate a CA certificate private key
##
$  openssl genrsa -out ca.key 4096

##
## 1-b) Generate the CA certificate
##
$  openssl req -x509 -new -nodes -sha512 -days 3650 \
    -subj "/C=CN/ST=Seoul/L=Seoul/O=AndrewInc/OU=Personal/CN=sejong.cluster" \
    -key ca.key \
    -out ca.crt



######################################################################
## 2)   Generate a Server Certificate
######################################################################

##
## 2-a) Generate a private key
##
$  openssl genrsa -out sejong.cluster.key 4096

##
## 2-b) Generate a certificate signing request (CSR).
##
$  openssl req -sha512 -new \
    -subj "/C=CN/ST=Seoul/L=Seoul/O=AndrewInc/OU=Personal/CN=sejong.cluster" \
    -key sejong.cluster.key \
    -out sejong.cluster.csr

##
## 2-c) Generate an x509 v3 extension file.
##
$  cat << EOF > v3.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1=sejong.cluster
DNS.2=sejong
DNS.3=registry
DNS.4=registry.sejong.cluster
DNS.5=10.1.4.51
DNS.6=registry.andrewinc.co.kr
EOF

$

##
## 2-d) Use the v3.ext file to generate a certificate for your server host.
##
$  openssl x509 -req -sha512 -days 3650 \
    -extfile v3.ext \
    -CA ca.crt -CAkey ca.key -CAcreateserial \
    -in sejong.cluster.csr \
    -out sejong.cluster.crt



######################################################################
## 3)   Merge the intermediate certificate with your own certificate 
##      to create a certificate bundle
######################################################################
## 참고로, 아래 명령은 Ubuntu에서만 가능한 명령이다. 
$  cp sejong.cluster.crt /usr/local/share/ca-certificates/sejong.cluster.crt
$  update-ca-certificates

## CentOS, Red Hat(RHEL)을 사용한다면, 위 명령 대신 아래 명령을 수행해야 한다.
$  cp sejong.cluster.crt /etc/pki/ca-trust/source/anchors/sejong.cluster.crt
$  update-ca-trust

 

 

 

Server Certificate  내용 확인

$  openssl x509 -in /usr/local/share/ca-certificates/sejong.cluster.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        ... 중간 생략 ...
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: C = KR, ST = Seoul, L = Seoul, O = MyCompany OU = Personal, CN = sejong.cluster
        Validity
            Not Before: Dec 21 04:08:37 2022 GMT
            Not After : Dec 18 04:08:37 2032 GMT
        Subject: C = KR, ST = Seoul, L = Seoul, O = MyCompany, OU = Personal, CN = sejong.cluster
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:bd:07:06:cb:ee:e9:0b:5a:51:bb:cc:a3:5c:a0:
                    ... 중간 생략 ...
                    ad:18:05
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                ... 중간 생략 ...
            X509v3 Basic Constraints:
                ... 중간 생략 ...
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:sejong.cluster, DNS:sejong, DNS:registry, DNS:registry.sejong.cluster, DNS:10.1.4.51
            X509v3 Subject Key Identifier:
                ... 중간 생략 ...
    Signature Algorithm: sha512WithRSAEncryption
    Signature Value:
        82:b9:5d:81:e7:90:85:20:08:8a:da:bb:a7:fc:30:fb:62:bf:
        ... 중간 생략 ...
        b4:64:b7:45:98:37:e8:f4
        
$

 


  

'Security' 카테고리의 다른 글

Zero Trust (개념, 관련 사업, 관련 표준 동향)  (0) 2024.05.14

+ Recent posts