Microsoft Secure Boot 인증서 만료: 산업용 Linux 점검 체크리스트

작성자:

산업용 Linux 장비의 Secure Boot를 관리한다면 인증서 만료일만 보고 부팅 장애부터 예상하기 쉽다. 하지만 Microsoft의 2011 계열 인증서가 만료돼도 기존 장비는 계속 시작하고 동작한다. 점검 대상은 당장의 부팅이 아니라 새 boot component와 보안 업데이트를 받아들일 신뢰 체인이다. 이 글은 UEFI, Secure Boot 상태, firmware db, shim 순서로 장비를 분류하고 두 실측 사례에 적용한다.

만료 영향은 부팅과 갱신을 나눠 본다

Microsoft 공식 표에는 세 갈래의 만료가 나온다. KEK에 저장된 Microsoft Corporation KEK CA 2011은 2026년 6월 24일, db의 Microsoft UEFI CA 2011은 6월 27일 만료됐다. db의 Microsoft Windows Production PCA 2011은 10월 19일 만료된다. 실측 장비의 Subject에는 두 번째 인증서가 Microsoft Corporation UEFI CA 2011로 표시됐다. Microsoft의 인증서 만료·CA 업데이트 안내

대체 인증서의 역할도 나뉜다. KEK의 Microsoft Corporation KEK 2K CA 2023은 db와 dbx 업데이트에 서명한다. 기존 UEFI CA 2011은 db의 Microsoft UEFI CA 2023과 Microsoft Option ROM UEFI CA 2023 두 장으로 나뉜다. 전자는 Linux shim 같은 third-party boot loader와 EFI application, 후자는 third-party option ROM 서명에 사용한다. Windows UEFI CA 2023은 Windows boot loader와 boot component용이다. Microsoft Act now 안내

여기서 만료를 즉시 부팅 중단으로 해석하면 안 된다. Microsoft는 2023 인증서를 받지 못한 장비도 계속 시작하고 정상 동작한다고 설명한다. 표준 Windows 업데이트도 계속 설치된다. 다만 Windows Boot Manager, Secure Boot database, revocation list, 새 boot-level 취약점 완화 같은 초기 부팅 보안 업데이트를 더는 받지 못한다. 이 설명은 Windows 장비 기준이지만, Linux에서도 기존 설치와 새 shim·설치 미디어의 신뢰 여부를 나눠 봐야 한다. LWN은 별도의 shim 서명 인증서 전환을 다루면서, 설치된 배포판은 계속 부팅해도 새 키로 서명된 shim 설치 미디어에는 firmware db의 새 키가 필요하다고 설명한다. LWN의 Linux Secure Boot 분석

현장에서는 다음 두 질문을 따로 기록한다.

  1. 현재 부팅 가능한가? 기존 boot chain과 현재 Secure Boot 설정의 문제다.
  2. 다음 갱신도 신뢰할 수 있는가? firmware db의 2023 인증서와 새 shim을 실제로 함께 검증했는지의 문제다.

1단계: UEFI와 Secure Boot 상태를 확인한다

먼저 UEFI로 부팅했는지 확인한다. /sys/firmware/efi가 없으면 현재 부팅 세션은 UEFI Secure Boot 점검 대상이 아니다.

[ -d /sys/firmware/efi ] && echo "UEFI" || echo "비UEFI(Legacy)"

mokutil이 있으면 Secure Boot 상태를 바로 읽는다.

mokutil --sb-state

SecureBoot enabled는 현재 신뢰 체인이 부팅을 통제한다는 뜻이다. SecureBoot disabled는 현재 부팅이 인증서 만료 때문에 즉시 막히지는 않는다는 뜻이다. 그러나 향후 Secure Boot를 켤 제품이거나 동일 firmware를 쓰는 다른 SKU가 있다면 점검을 끝내면 안 된다. db와 실제 boot chain까지 확인해야 한다.

mokutil이 없는 Yocto 환경에서는 efivarfs를 직접 읽는다.

od -An -tx1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

이 파일의 앞 4바이트는 EFI 변수 속성이다. 실측값 06 00 00 00 00에서는 마지막 1바이트 00이 Secure Boot disabled를 뜻했다. 파일이 없으면 현재 image에서 efivarfs가 mount됐는지부터 확인한다.

2단계: firmware KEK와 db의 인증서를 찾는다

mokutil이 있는 장비에서는 KEK와 db의 Microsoft 인증서와 만료일을 함께 본다.

mokutil --kek | grep -E "Microsoft|Not After"
mokutil --db | grep -E "Microsoft|Not After"

첫 명령은 점검 절차다. 이번 x86 실측에는 KEK 출력이 없으므로 설치 여부나 값을 추정하지 않는다.

판정할 이름은 다음과 같다.

  • KEK 만료 경과: Microsoft Corporation KEK CA 2011 — 2026-06-24
  • KEK 대체: Microsoft Corporation KEK 2K CA 2023
  • db 만료 경과: Microsoft Corporation UEFI CA 2011 — 2026-06-27
  • db 대체: Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023
  • db 만료 예정: Microsoft Windows Production PCA 2011 — 2026-10-19
  • db 대체: Windows UEFI CA 2023

efi-readvar가 있으면 db의 certificate list를 구조화해 확인할 수 있다.

sudo efi-readvar -v db

mokutil과 efi-readvar가 모두 없는 image에서는 먼저 PK, KEK, db, dbx 변수 자체가 등록됐는지 확인한다.

ls /sys/firmware/efi/efivars/ | grep -E "^(PK|KEK|db|dbx)-"

efivarfs의 변수 존재 여부와 SecureBoot 값만으로도 키 미등록 장비는 분류할 수 있다. 반대로 db가 존재하면 파일에 들어 있는 X.509 certificate의 Subject와 만료일을 확인해야 한다. 운영 image에 parser를 임의로 추가하기보다 같은 firmware를 사용하는 정비 image에서 efi-readvar로 읽고 결과를 자산 정보에 남기는 편이 안전하다.

3단계: Linux가 shim에 의존하는지 확인한다

firmware db에 Microsoft 인증서가 있어도 실제 boot chain이 이를 쓰지 않을 수 있다. Ubuntu 계열에서는 설치된 signed package부터 확인한다.

dpkg -l | grep -E "shim|grub-efi.*signed"

shim-signed는 Secure Boot를 켰을 때 Microsoft가 서명한 shim을 첫 단계로 사용하는 구조를 뜻한다. shim은 배포판 키로 GRUB 같은 다음 단계를 검증한다. 따라서 firmware의 Microsoft UEFI CA 2023 수신, 배포판의 새 shim 제공, 후속 boot component 검증을 하나의 전환 시험으로 묶어야 한다.

Yocto처럼 boot chain을 직접 구성하는 장비는 package 이름으로 판정하지 않는다. image recipe, 실제 EFI binary, 서명 주체, PK/KEK/db 등록 절차를 제품의 boot chain 문서와 대조한다. 사용자 키로만 서명했다면 Microsoft CA 만료와 직접 연결되지 않는다.

사례 A: x86 Ubuntu는 db 전환 준비 상태다

2026년 7월 13일 x86 Ubuntu 22.04 머신을 확인한 결과는 다음과 같다.

  • UEFI로 부팅했다.
  • 현재 Secure Boot는 disabled다.
  • db에 2011 인증서 두 개와 2023 인증서 두 개가 공존했다.
  • shim-signed 15.8과 signed GRUB package가 설치돼 있었다.
  • db에는 보드 제조사 OEM 인증서도 있었다.

efi-readvar -v db에서 확인한 Subject는 아래 네 개다.

CN=Microsoft Corporation UEFI CA 2011
CN=Microsoft Windows Production PCA 2011
CN=Windows UEFI CA 2023
CN=Microsoft UEFI CA 2023

이 장비는 Linux shim용 firmware db 수신 기준으로 준비됨으로 판정했다. Microsoft UEFI CA 2023이 이미 들어 있기 때문이다. Windows UEFI CA 2023도 확인했다. 반면 KEK 2023과 Microsoft Option ROM UEFI CA 2023은 실측하지 않았으므로 전체 인증서 전환 완료로 판정하지 않는다. 현재 Secure Boot도 꺼져 있어 새 shim의 부팅 성공은 대표 장비에서 별도로 시험해야 한다.

사례 B: Jetson Yocto는 Microsoft 체계와 무관하다

같은 날 Jetson Orin Nano (Yocto)에서는 UEFI 디렉터리가 존재했다. 그러나 efivarfs를 직접 읽은 결과가 달랐다.

$ od -An -tx1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
 06 00 00 00 00

$ ls /sys/firmware/efi/efivars/ | grep -E "^(PK|KEK|db|dbx)-"
(출력 없음)

Secure Boot는 disabled였고 PK, KEK, db, dbx 변수도 등록되지 않았다. Microsoft 인증서가 없는 키 등록 전 상태이므로 이 장비는 Microsoft 2011 인증서 만료 영향 없음으로 판정했다. Secure Boot를 제품 요구사항으로 삼는다면 Microsoft 인증서 갱신이 아니라 사용자 키 등록부터 설계해야 한다.

이 사례는 SecureBoot disabled라는 같은 상태만으로 결론을 내리면 안 된다는 점을 보여준다. 사례 A는 향후 Secure Boot 활성화 시 Microsoft 서명 체인에 들어간다. 사례 B는 사용자 키 체계를 새로 구성해야 한다.

조치 경로는 세 가지로 나눈다

1. OEM firmware와 db 업데이트

Microsoft 2011 인증서를 쓰는 장비는 OEM이 제공하는 firmware 또는 Secure Boot KEK·db 업데이트 경로를 먼저 확인한다. Linux shim 전환에는 Microsoft UEFI CA 2023이 필요하다. third-party option ROM을 신뢰하는 제품은 Microsoft Option ROM UEFI CA 2023도 확인한다. 인증서 파일을 출처 불명의 절차로 직접 넣지 말고, 장비 제조사가 검증한 경로를 따른다.

Windows와 dual boot하는 Linux 장비는 Windows가 Linux에서 쓰는 새 인증서를 갱신할 수 있다. 순수 Linux 장비에는 이 자동 경로가 없다. OEM firmware 업데이트나 제조사가 운영하는 자체 KEK·db 갱신 경로를 확보해야 한다. Microsoft 문서의 Intune·registry·GPO 절차는 Windows용이므로 순수 Linux 장비에 그대로 적용하지 않는다. Microsoft Secure Boot playbook

2. shim·GRUB 갱신 시험

firmware db 갱신과 OS package 갱신을 따로 완료 처리하지 않는다.

Secure Boot를 단순히 껐다 켜서 시험하지 않는다. Microsoft는 이 조작이 갱신된 인증서를 기본값으로 되돌리거나 지울 수 있다고 경고한다. 현재 disabled인 장비는 OEM 절차와 복구 방법을 먼저 확인한 뒤 별도 시험 장비에서 전환한다.

대표 hardware revision마다 다음 순서로 검증한다.

  1. 갱신 전 PK, KEK, db, dbx를 읽기 전용으로 export하거나 목록을 기록한다.
  2. firmware 또는 db 업데이트 뒤 2023 인증서의 Subject를 확인한다.
  3. 배포판이 제공하는 새 shim과 GRUB를 적용한다.
  4. Secure Boot enabled 상태에서 cold boot와 reboot를 확인한다.
  5. 실패 시 되돌릴 firmware·boot media·console 접근 경로를 확보한다.

3. 사용자 키 체계

장비 제조사가 boot chain 전체를 통제한다면 자체 PK, KEK, db를 등록하고 boot component를 사용자 키로 서명하는 방식을 선택할 수 있다. 이 경로는 Microsoft CA 만료와 분리할 수 있지만 키 생성으로 끝나지 않는다. 제조 단계의 등록, private key 보호, 서명 자동화, key rotation, revocation, 복구 절차를 함께 운영해야 한다. Jetson Orin Nano (Yocto) 사례는 바로 이 설계를 시작할 수 있는 키 미등록 상태다.

현장 점검 체크리스트

  • [ ] 현재 부팅이 UEFI인지 확인했다.
  • [ ] Secure Boot enabled/disabled를 기록했다.
  • [ ] PK, KEK, db, dbx 등록 여부를 기록했다.
  • [ ] KEK에서 2011·2023 Microsoft 인증서의 정확한 Subject와 만료일을 확인했다.
  • [ ] db에서 UEFI·Option ROM·Windows용 2011·2023 인증서를 구분했다.
  • [ ] 실제 boot chain이 Microsoft-signed shim에 의존하는지 확인했다.
  • [ ] OEM firmware/db 업데이트 제공 여부를 확인했다.
  • [ ] Secure Boot toggle의 인증서 초기화 위험과 OEM 절차를 확인했다.
  • [ ] 2023 인증서 수신 뒤 새 shim·GRUB로 실제 부팅을 시험했다.
  • [ ] 실패 시 console 접근과 rollback 경로를 확보했다.
  • [ ] 사용자 키 체계라면 등록·보호·rotation·revocation 책임자를 정했다.

정리

2026년 Secure Boot 인증서 만료는 모든 Linux 장비가 같은 날 멈추는 사건이 아니다. 기존 부팅과 향후 갱신 신뢰를 분리해야 실제 위험이 보인다. UEFI 여부, Secure Boot 상태, firmware db, shim 의존성을 차례로 확인하면 장비를 전환 준비, 추가 조치 필요, Microsoft 체계와 무관으로 나눌 수 있다.

사례 A는 2023 인증서를 이미 받았지만 Secure Boot enabled 실부팅 시험이 남았다. 사례 B는 Microsoft 인증서가 없어 이번 만료와 무관하며, Secure Boot 도입 시 사용자 키 등록부터 시작해야 한다. 현장 판정은 인증서 이름 한 줄이 아니라 firmware와 실제 boot chain을 함께 확인한 결과여야 한다.

참고 자료

  1. LWN, Linux and Secure Boot certificate expiration
  2. Microsoft Windows IT Pro Blog, Act now: Secure Boot certificates expire in June 2026
  3. Microsoft Support, Windows Secure Boot certificate expiration and CA updates
  4. Microsoft Windows IT Pro Blog, Secure Boot playbook for certificates expiring in 2026
  5. 자체 실측(2026-07-13): x86 Ubuntu 22.04 머신과 Jetson Orin Nano (Yocto)의 UEFI·Secure Boot·firmware 변수·shim package 로그