도메인의 인증서가 서브도메인의 인증서로 적용되었던 사례.

환경

• Let’s Encrypt
• Nginx
• Certbot

배경

• 궁금해서 운영하던 도메인의 인증서를 확인해봤는데 도메인의 인증서가 서브도메인으로 되어있는걸 발견하여 수정했다. 예를 들어 도메인이 twpower.org라고 하면 브라우저에서 봤을 때 subdomain.twpower.org의 인증서로 되어 있었다.
• 사용하는 서버의 경우 Nginx를 이용하는 환경이고 certbot을 통해서 인증서 설정을 했었다.

이유

• Let’s Encrypt의 인증서를 사용했고, certbot을 통해 설정했었는데, 확인해보니 도메인별로 따로 인증서 설정을 해야 했었다. 그런데 하나의 명령어로 서브도메인까지 함께 적용했었다.
• 링크를 찾아보면 와이드카드로 서브도메인까지 포함해 설정이 가능했다. 그런데 방법이 조금 복잡해보여 적용하지는 않았다.

수정 방법

• 도메인별로 각각 따로 지정해줘야 한다고 한다. 예를 들어 twpower.org 그리고 서브도메인이 subdomain.twpower.org라면 아래처럼 따로 적용하면 된다.
• 아니면 위 링크에 있는 방법으로 서브도메인까지 적용 가능하다. 하지만 이 글에서는 다루지 않는다.

sudo certbot --nginx -d twpower.org -d www.twpower.org
sudo certbot --nginx -d subdomain.twpower.org

조치 과정

기존에 certbot에 의해 설정되었던 부분들을 제거하고 다시 인증서를 설정했다.

certbot에 의해 작성된 기존 설정들 제거

/etc/nginx/sites-enabled/에 설정 파일들이 아래처럼 도메인명으로 만들어져 있다.

twpower@twpower-private-server:/etc/nginx/sites-enabled$ ls /etc/nginx/sites-enabled/
subdomain.twpower.org  twpower.org

certbot에 의해 설정된 부분들을 아래와 같이 주석이 달려있다. 아래는 일부를 발췌했다.

if ($host = www.twpower.org) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = twpower.org) {
    return 301 https://$host$request_uri;
} # managed by Certbot

기존에 적용된 부분들을 없애기 위해 # managed by Certbot로 되어있는 부분들을 모두 삭제했다.

Nginx 영향 확인

sudo nginx -t

certbot을 통해 인증서 다시 설정

nginx 설정이 정상이라면 아래 명령어를 참고하여 도메인과 서브 도메인에 인증서를 적용한다.

sudo certbot --nginx -d twpower.org -d www.twpower.org
sudo certbot --nginx -d subdomain.twpower.org

결과

• 각 도메인으로 들어가서 인증서를 확인해보면 서로 다른 인증서가 적용되어 있다.

의견

• 요즘에는 클라우드 서비스를 이용하면 이런 작업은 다 해주는데 또 접할 기회가 있을지 모르겠다.
• 클라우드 서비스에서 해줄 뿐 아니라 ChatGPT 같은 서비스에서 다 자세하게 알려주는 시대라 이걸 다시 접할 기회가 올지는 모르겠다.
• 나처럼 작은 서버 운영할 때는 도움이 될 수 있겠다.

참고자료

• https://certbot.eff.org/instructions?ws=nginx&os=debianbuster
• https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04
• https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04

Case of subdomain’s certificate was applied to root domain.

Environment and Prerequisite

• Let’s Encrypt
• Nginx
• Certbot

Background

• Due to my Curiosity, I searched my domain certificate and found that domain’s certificate was configured to subdomain’s certificate so I modified it. For example, if domain is twpower.org, the certificate was displayed as subdomain.twpower.org’s certificate in browser.
• Running server is Nginx environment and set certificate by using certbot.

Reason

• I used a Let’s Encrypt certificate and set it up using certbot. I found that I needed to set certificate per doamin. However I set up domain and subdomain simultaneously.
• Link shows a way of applying wildcard which contain subdomain. However I did not follow that way because it looks not easy.

Fix Method

• Certificate setting should be applied per domain. For example if there are domain twpower.org and subdomain subdomain.twpower.org then it can be applied like below command.
• It is possible to apply to subdomain using above Link. However this post does not include that method.

sudo certbot --nginx -d twpower.org -d www.twpower.org
sudo certbot --nginx -d subdomain.twpower.org

Fix Process

Remove exist previous setting by certbot and set certificate again.

Remove existing configurations created by certbot

There are setting files per domain in /etc/nginx/sites-enabled/.

twpower@twpower-private-server:/etc/nginx/sites-enabled$ ls /etc/nginx/sites-enabled/
subdomain.twpower.org  twpower.org

The parts configured by certbot are commented as shown below.

if ($host = www.twpower.org) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = twpower.org) {
    return 301 https://$host$request_uri;
} # managed by Certbot

To remove previous exist setting, I removed codes which commented with # managed by Certbot.

Check Nginx

sudo nginx -t

Set Certificate Using certbot

If nginx configuration is correct, refer to the command below to apply the certificate to both domain and subdomain.

sudo certbot --nginx -d twpower.org -d www.twpower.org
sudo certbot --nginx -d subdomain.twpower.org

Result

• Each domain has each own certificate.

Opinion

• These days, cloud services handle these tasks, so I may not encounter this situation again.
• Not only do cloud services handle this, but we also live in an era where services like ChatGPT provide detailed instructions, so I might not have the chance to encounter this again.
• When running a small server like me, this could be helpful.

Reference

• https://certbot.eff.org/instructions?ws=nginx&os=debianbuster
• https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04
• https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-22-04

workflow_dispatch와 workflow_call을 사용하지 않을 때 기본값 설정하기

환경

• Github Actions

배경

• Github Actions에서 workflow_dispatch와 workflow_call에 정의된 inputs을 사용하는 부분이 있었는데 이 부분이 push와 같이 다른 이유로 호출될 때 사용하지 못하는 이슈가 발생하여 기본값을 설정해두면 대처가 가능할거 같아 찾아서 정리했다.

방법

• push와 같이 workflow_dispatch와 workflow_call이 아니라서 inputs을 사용할 수 없는 경우 기본값을 설정할 수 있다.
• workflow_dispatch 또는 workflow_call을 통해 실행된 workflow의 경우 inputs에 명시된 값을 사용하고 그렇지 않다면 || 뒤에 나온 기본값을 사용하는 방식이다.
• 기본값을 환경변수에 저장하고 그 환경변수를 가져오는 방식이다.

코드

name: Workflow Return Test
on:
  push:
    branches: [ main ]
  workflow_call:
    inputs:
      key:
        type: string
  workflow_dispatch:
    inputs:
      key:
        type: string
jobs:
  print_default_value_test:
    name: print value
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Set default value
        run: |
          echo "VALUE_NAME=${{ inputs.key || "default value" }}" >> $GITHUB_ENV
      - name: Print value
        run: echo "${{ env.VALUE_NAME }}"

결과

• push를 통해 실행된 경우

Run echo "default value"
  echo "default value"
  shell: /usr/bin/bash -e {0}
  env:
    VALUE_NAME: default value
default value

• “test input value”라는 문자열 값을 전달해 workflow_dispatch 또는 workflow_call을 통해 실행된 경우

Run echo "test input value"
  echo "test input value"
  shell: /usr/bin/bash -e {0}
  env:
    VALUE_NAME: test input value
test input value

의견

이렇게 하는게 권장하는 방법인지는 모르겠으나 검색했더니 나온 결과가 있어서 사용했다.

참고자료

• https://stackoverflow.com/questions/73955908/how-to-use-env-variable-as-default-value-for-input-in-github-actions
• https://docs.github.com/ko/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions

Setting default value when not using workflow_dispatch and workflow_call

Environment and Prerequisite

• Github Actions

Background

• In GitHub Actions, there was an issue where the inputs defined in workflow_dispatch and workflow_call could not be used when triggered by other events like push. To address this, it seems that setting default value could be a potential solution so I wrote this.

Solution

• In cases when inputs cannot be used like push because it is not triggered by workflow_dispatch or workflow_call, you can set default values as shown below.
• For workflows triggered by workflow_dispatch or workflow_call, the values specified in inputs are used. Otherwise the default value following || is used.
• Save default value to environment variable and use it.

Code

name: Workflow Return Test
on:
  push:
    branches: [ main ]
  workflow_call:
    inputs:
      key:
        type: string
  workflow_dispatch:
    inputs:
      key:
        type: string
jobs:
  print_default_value_test:
    name: print value
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Set default value
        run: |
          echo "VALUE_NAME=${{ inputs.key || "default value" }}" >> $GITHUB_ENV
      - name: Print value
        run: echo "${{ env.VALUE_NAME }}"

Result

• Triggered by push

Run echo "default value"
  echo "default value"
  shell: /usr/bin/bash -e {0}
  env:
    VALUE_NAME: default value
default value

• Triggered by workflow_dispatch or workflow_call with passing string value “test input value”

Run echo "test input value"
  echo "test input value"
  shell: /usr/bin/bash -e {0}
  env:
    VALUE_NAME: test input value
test input value

Opinion

I’m not sure if this is the recommended one but I used it because I found it by searching.

Reference

• https://stackoverflow.com/questions/73955908/how-to-use-env-variable-as-default-value-for-input-in-github-actions
• https://docs.github.com/ko/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions

Github Actions Matrix 사용법과 예제

환경

• Github Actions

배경

• 작업은 동일한데 일부 값들만 변경하여 CI/CD를 실행하고 싶은 경우가 있어서 찾아보고 적용하여 정리한다.
• 자세한 사용법과 예제는 https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/using-a-matrix-for-your-jobs에 나와있다.

사용법

• 문서에 나온대로 아래와 같은 방법으로 사용할 수 있다.
• jobs.<job_id>.strategy.matrix에 행렬의 변수와 값을 정의해주면 된다.
• 아래 예제의 경우 version에 해당하는 값들이 [10, 12, 14]이며 os도 마찬가지이다.

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]

예시

Jekyll 빌드를 여러 OS에서 실행하고 싶은 경우 아래처럼 작성할 수 있다. 실제로 이 블로그에 사용하는 workflow 예제다.

코드

• 문서에 나온대로 적용했으며 다른 부분들도 포함되어 있지만 jobs에 있는 build job의 strategy를 보면된다.
• os: [ubuntu-22.04, ubuntu-20.04, macos-latest]를 통해 사용할 os를 목록으로 정의했고 runs-on: ${{ matrix.os }}에서 해당 os들을 사용하도록 작성했다.
• jobs.<job_id>.strategy.fail-fast 설정이 true이거나 해당 식이 true로 평가되면, matrix의 어떤 job이라도 실패할 경우 matrix에서 진행 중인 job과 대기 중인 job을 모두 취소한다고 문서에 나와 있다. 여러개의 job에서 하나가 실패하더라도 나머지 job들은 계속 진행하도록 하고 싶어서 false로 적용했다.

name: Jekyll Build CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:
    inputs:
      ruby-version:
        required: true
        type: string
        default: "3.2.2"
        
jobs:
  build:
    name: jekyll build
    strategy:
      matrix:
        os: [ubuntu-22.04, ubuntu-20.04, macos-latest]
      fail-fast: false
    runs-on: ${{ matrix.os }}
    steps:
    - name: Checkout Repository
      uses: actions/checkout@v4
    - name: Setup Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ github.event.inputs.ruby-version }}
    - name: Install Bundler
      run: |
        gem install bundler
    - name: Install Dependencies
      run: |
        bundle install
    - name: Build Jekyll Site
      run: |
        bundle exec jekyll build

결과

• 실행한 결과를 이미지로 보여주는게 이해하기 편해 이미지를 첨부한다

참고자료

• https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/using-a-matrix-for-your-jobs