PKI 시크릿 엔진 - 회전 프리미티브

PKI 시크릿 엔진 - 회전 프리미티브 (rotation primitives)

Vault 1.11.0부터 Vault의 PKI 시크릿 엔진은 단일 마운트 지점에서 여러 발급자(issuer)를 지원해요. 아래 인증서 유형을 사용하면 Vault가 관리하는 루트 및 중간 CA를 둘 다 포함한 다양한 상황에서 회전(rotation)을 달성할 수 있어요.

출처: 문서

본문

X.509 인증서 필드

X.509는 복잡한 명세예요. 현대 구현은 구체적 세부 사항을 RFC 5280을 참조하는 경향이 있어요. 인증서 검증을 위해 회전을 달성하는 방법을 이해하려면 RFC 5280과 TLS 검증 RFC 6125 모두 중요해요.

다음은 이 문서의 목적을 위해 이 표준들을 단순화한 것이에요.

모든 X.509 인증서는 RSA나 ECDSA 같은 알고리즘을 사용하는 비대칭 키 쌍으로 시작해요. 이 키 쌍은 인증서 서명 요청(CSR)을 만드는 데 사용되는데, CSR에는 요청자가 최종 인증서에 넣고 싶은 필드 집합이 포함돼요(그러나 어떤 필드를 CSR에서 가져올지 어떤 필드를 덮어쓸지는 인증 기관(CA)의 결정에 달려 있어요). CSR에는 또한 키 쌍의 공개 키가 포함되는데, 소유를 증명하기 위해 키 쌍의 개인 키로 서명돼요. 보통 요청자는 CSR의 Subject 필드나 Subject Alternative Name 확장의 속성이 최종 인증서에 반영되도록 요청해요. 이 값들을 신뢰할지 여부는 CA의 결정에 달려 있어요. 발급 기관(루트 자체 서명 인증서의 경우 이 비대칭 키 자체가 백업일 수 있음)이 승인하면, 기관은 자신의 인증서의 Subject를 발급된 인증서의 Issuer 필드에 첨부하고, 발급된 인증서에 고유 시리얼 번호를 할당한 다음, 필드 집합을 자신의 개인 키로 서명해 인증서를 만들어요.

여기에는 몇 가지 중요한 제한이 있어요.

• 하나의 인증서는 Issuer가 하나만일 수 있지만, 이 발급자는 발급 인증서의 Subject와 그 공개 키로 식별돼요.
• 하나의 키 쌍은 여러 인증서에 사용될 수 있지만, 하나의 인증서는 하나의 백업 키 자료만 가질 수 있어요.

최종 인증서의 다음 필드는 회전과 관련이 있어요.

• 백업 공개 및 개인 키 자료 (Subject Public Key Info).
  • 개인 키는 인증서에 포함되지 않지만 공개 키 자료에 의해 고유하게 결정된다는 점을 기억하세요.
• 인증서의 Subject.
  • 이는 인증서가 발급된 엔티티를 식별해요. (Subject Alternative Name 확장의) SAN 값은 TLS 서버 인증서를 협상된 호스트명·URI와 검증할 때 유용하지만, 중간 인증서 체인 검증이나 회전 목적에는 일반적으로 관련이 없어요.
• 이 인증서의 유효 기간(Validity).
  • 특히 RFC 5280은 발급 인증서의 유효 기간과 관련해 발급된 인증서의 유효 기간에 어떤 요구 사항도 두지 않아요. 그러나 명시하길 인증서 상태를 notAfter 날짜까지 유지할 수 없다면 폐기되어야 한다고 해요. 이것이 Vault 1.11의 /pki/issuer/:issuer_ref 구성 엔드포인트가 leaf_not_after_behavior를 역할별이 아니라 발급자별로 유지하는 이유예요.
  • 또한 일부 브라우저는 인증서가 만료됐어도 신뢰 저장소의 인증서를 최종적으로 신뢰해요.
    • 이는 신뢰 저장소의 인증서에만 적용된다는 점을 기억하세요. 저장소에 없는 인증서(중간 같은)에는 유효 기간이 여전히 시행돼요.
• 이 인증서의 Issuer와 signatureValue.
  • 발급된 인증서의 Issuer 필드에서 발급 인증서는 자신의 Subject 값을 넣어요. 이렇게 하면 제시된 인증서와 체인을 검증할 때 (모든 알려진 로컬 인증서에 대해 서명 검증을 시도할 필요 없이) 나중에 발급자를 식별할 수 있어요.
  • (발급자의 개인 키로) 인증서 전체에 대한 서명은 signatureValue 필드에 들어가요.
• 선택적 Authority Key Identifier 필드.
  • 이 필드는 두 값 중 하나(또는 둘 다)를 포함할 수 있어요.
    • 발급자 공개 키의 해시. 이 확장이 설정되고 이 값은 Vault가 채워요.
    • 발급자의 Subject와 Serial Number. 이 값은 Vault가 설정하지 않아요.
  • 후자는 회전 목적에 위험한 제한이에요: 교차 서명과 재발급을 막는데, 새 발급 인증서(같은 백업 키 자료를 가지지만)는 서로 다른 시리얼 번호를 갖기 때문이에요. 이 제한에 대한 자세한 내용은 아래의 프리미티브의 제한 사항 섹션을 참고하세요.
• 이 인증서의 Serial Number.
  • 이 필드는 특정 발급자에게 고유해요. 인증서가 부모 기관에 의해 재발급되면 항상 다른 시리얼 번호 필드를 가져요.
• CRL 배포 지점 필드.
  • 이는 이 인증서에 대해 CRL이 어디에 존재할 것으로 예상되고, 어떤 CRL 발급자(기본적으로 발급 인증서 자체) 아래에서 CRL이 서명될 것으로 예상되는지 상세히 설명하는 필드예요. 이것은 대부분 정보용이며, nginx, Vault의 Cert Auth 방식, Apache 같은 서버 소프트웨어의 경우 서버가 인증서에 대한 CRL을 자동으로 가져오는 것이 아니라 CRL이 서버에 제공돼요.
  • 루트 인증서(브라우저 신뢰 저장소의)는 일반적으로 폐기 가능한 것으로 간주되지 않는다는 점을 기억하세요. 그러나 중간이 시리얼로 폐기되면 부모의 CRL에 나타나고, 회전이 일어나는 것을 막을 수 있어요.

X.509 회전 프리미티브

(조직 관점의) 회전은 특정 중간 X.509 인증서가 발급될 때만 안전하게 일어날 수 있어요. 회전을 달성하는 데 사용되는 두 인증서 유형을 구분하기 위해 이 문서에서는 이를 *프리미티브(primitives)*라고 표기해요.

종단 엔티티(리프) 인증서의 회전은 X.509 신뢰 체인 관점에서 사소해요. 이 과정은 매일 발생하며 신뢰 저장소에 있는 것과 종단 엔티티 인증서 자체에만 의존해야 해요. Vault에서 요청자는 다양한 발급 엔드포인트(/pki/issue/:name 또는 /pki/sign/:name — 또는 안전하지 않은 /pki/sign-verbatim)를 두드려 옛 인증서를 새 인증서로 교체하고 구성을 다시 로드하거나 서비스를 재시작해요. 조직의 다른 부분은 인증서 발급과 회전에 ACME를 사용할 수 있는데, 특히 서비스가 공개 노출되어(그래서 공개 CA가 발급해야 하는) 경우에 그렇습니다. 신뢰받는 루트가 서명했으므로 서비스에 연결하는 어떤 디바이스도 차이를 알지 못해요.

중간 인증서의 회전은 거의 비슷하게 쉽다. 적절한 운영 설정(종단 엔티티 발급 중 서비스 구성에서 전체 인증서 체인이 갱신되는)을 가정하면, 새 중간 CA를 만들고 루트 CA에 서명하고 새 중간 인증서에 대한 발급을 시작하기만 하면 돼요. Vault에서 중간이 기존 마운트 경로에서 생성되면(또는 그렇게 이동되면) 요청 엔티티는 크게 신경 쓰지 않아야 해요. ACME 아래에서 Let's Encrypt는 교차 서명된 체인(구형 Android 디바이스용)을 제시하도록 중간을 성공적으로 회전했어요. 옛 중간의 부모가 여전히 유효하고 신뢰된다면, 옛 중간 아래에서 발급된 인증서는 계속 검증되어야 해요.

회전의 어려운 부분—이 프리미티브들의 사용을 요구하는—은 루트 인증서를 회전하는 것이에요. 루트는 모든 디바이스의 신뢰 저장소에 있고 조직 전체 운영 관점에서 갱신하기 어려워요. 조직이 (예: 에이전트를 통해) 루트를 거의 순간적으로 동시에 교체할 수 있고 놓친 디바이스가 없다면, 이 과정은 아마 수 개월에 걸칠 거예요.

이 과정의 위험을 낮추기 위해 위의 인증서 필드를 사용하는 다양한 프리미티브 인증서 유형이 있어요. 성공의 핵심은 다음 참고 사항이에요.

참고: 인증서가 신뢰 저장소에 추가되는 동안 궁극적으로 신뢰를 결정하는 것은 연결된 키 자료예요. 같은 주체지만 다른 공개 키를 가진 두 발급자 인증서는 같은 리프 인증서를 검증할 수 없어요. 키가 같을 때만 가능해요.

교차 서명 (Cross-Signed) 프리미티브

이것은 가장 흔한 유형의 회전 프리미티브예요. 공통 CSR이 두 CA에 서명되어 두 인증서가 만들어져요. 이 인증서들은 같은 Subject(그러나 Issuer가 다를 수 있고 Serial Number는 다를 것)와 같은 백업 키 자료를 가져야 해요. 그래야 이들이 서명한 인증서가 어느 변형에 의해서든 신뢰될 수 있어요.

종단 엔티티 인증서가 사용·검증되는 방식의 제한(서비스와 검증 라이브러리는 하나만 기대함) 때문에, 교차 서명은 가장 전형적으로 중간 인증서에만 적용된다는 점을 기억하세요.

교차 서명된 루트에 대한 참고

기술적으로 교차 서명은 두 루트 사이에서 일어날 수 있어, 어느 루트든 다른 쪽을 통해 발급된 인증서를 검증하는 신뢰 번들을 허용해요. 그러나 이 과정은 사실상 중간 인증서가 되는(더 이상 자체 서명이 아니므로) 인증서를 만들고, 보통 신뢰 체인과 함께 서비스되어야 해요. 이 제한 때문에, 옛 루트가 리프 인증서를 직접 발급하는 데 사용된 때가 아니라면, 엄격히 필요할 때가 아니면 루트 아래의 최상위 중간을 교차 서명하는 것이 더 바람직해요.

그래서 나머지 과정 흐름은 더 흔하기 때문에 중간이 교차 서명되는 것을 가정해요.

과정 흐름 (Process flow)

        -------------------
       | generate key pair | -------------> ...
        -------------------                 ...
           |            |                   ...
 --------------        --------------       ...
| generate CSR |      | generate CSR |      ...
 --------------        --------------       ...
         |                   |              ...
    -----------         -----------         ...
   | signed by |       | signed by |        ...
   | root A    |       | root B    |        ...
    -----------         -----------         ...

여기서 어느 시점에 키 쌍이 생성됐어요. 두 CSR이 만들어져 두 개의 서로 다른 루트 기관(Root A와 Root B)으로 보내져요. 이는 (잠재적으로 다른 유효 기간을 가진) 같은 Subject와 같은 백업 키 자료를 가진 두 개의 별도 인증서를 만들어요.

이 교차 서명은 동시에 일어날 필요가 없다는 점을 기억하세요. 첫 번째와 두 번째 인증서 사이에 몇 년의 간격이 있을 수 있어요. 또한 교차 서명된 "중복"(느슨하게—같은 주체와 키 자료를 가진) 인증서의 수에는 제한이 없어요. 필요하고 원한다면 많은 다른 루트 인증서가 교차 서명할 수 있어요.

인증서 계층 구조 (Certificate hierarchy)

 --------                                            --------
| root A |                                          | root B |
 --------                                            --------
   |                                                      |
 ----------------                            ----------------
| intermediate C |  <- same key material -> | intermediate D |
 ----------------              |             ----------------
                               |
                      -------------------
                     | leaf certificates |
                      -------------------

위 과정은 두 개의 신뢰 경로를 만들어요. root A 또는 root B(또는 둘 다)가 클라이언트의 신뢰 저장소에 존재할 수 있고 리프 인증서가 올바르게 검증돼요. 두 중간 인증서(C와 D)에 같은 키 자료가 사용되므로, 발급된 리프 인증서의 서명 필드는 어느 중간에 접촉했는지와 무관하게 같을 거예요.

교차 서명은 따라서 통합하는 프리미티브예요. (체인에서 인증서를 복제함으로써) 리프 인증서의 발급자 필드가 두 개의 별도 경로를 가리키게 해 두 개의 별도 신뢰 경로가 하나로 합쳐지고, 어떤 루트가 신뢰 저장소에 있느냐에 따라 조건부로 검증되어요.

이 구조는 여러 곳에서 문서화되고 사용돼요.

• https://letsencrypt.org/certificates/
• https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/
• https://security.stackexchange.com/questions/14043/what-is-the-use-of-cross-signing-certificates-in-x-509

Vault에서의 실행

Vault에서 교차 서명된 인증서를 만들려면 /intermediate/cross-sign 엔드포인트를 사용해요. 여기서 cert A가 검증할 cert B에 대한 교차 서명을 만들 때, 중간 생성 중에 cert B에 대한 값(key_ref, 모든 Subject 파트, 등)을 제공해요. 그런 다음 이 CSR을 /issuer/:issuer_ref/sign-intermediate 엔드포인트로 cert A의 참조로 서명하고 cert B에서 필요한 값(예: Subject 파트)을 제공해요. cert A는 Vault 밖에 있을 수 있어요. 마지막으로 교차 서명된 인증서를 /issuers/import/cert 엔드포인트로 Vault로 가져와요.

이 과정이 성공하면, cert A와 cert B 및 그 키 자료가 Vault에 있으면, 새로 가져온 교차 서명된 인증서는 읽는 동안 cert A를 포함하는 ca_chain 응답 필드를 갖고, cert B의 ca_chain은 교차 서명된 인증서와 그 ca_chain 값을 포함할 거예요.

참고: 발급자 유형과 무관하게 모든 관련 파라미터를 원래대로 제공하는 것이 중요해요. Vault는 예를 들어 기존 발급자에서 Subject 이름 파라미터를 추론하지 않아요. 같은 키 자료를 재사용할 뿐이에요.

manual_chain에 대한 참고

중간이 교차 서명되고 그 짝과 같은 마운트로 가져오면, Vault는 자동 체인 구축 중에 교차 서명된 짝을 감지하지 못해요. 결과적으로 리프 발급은 이 체인 짝 중 하나만 포함하는 체인을 갖게 돼요. 이는 리프 발급의 ca_chain 파라미터가 자체적으로 체인의 사본을 계산하는 대신 서명 발급자에서 값을 직접 복사하기 때문이에요.

이를 고치려면 발급자들의 manual_chain 필드를 두 짝 모두의 체인을 포함하도록 갱신해요. 예를 들어 rootA가 서명한 intA와 그 교차 서명 버전인 rootB가 서명한 intB가 있다면, 다음을 할 수 있어요.

$ vault patch pki/issuer/intA manual_chain=self,rootA,intB,rootB
$ vault patch pki/issuer/intB manual_chain=self,rootB,intA,rootA

이렇게 하면 리프 인증서에 서명할 때 중간의 어느 복사본으로 발급하든 전체 교차 서명 체인이 보고되도록 보장돼요.

재발급 (Reissuance) 프리미티브

두 번째로 흔한 유형의 회전 프리미티브예요. 이 방식에서는 기존 키 자료를 사용해 새 인증서를 생성하는데, 보통 기존 발급 시점보다 훨씬 나중에 생성해요.

교차 서명 프리미티브와 비슷하지만, 이 프리미티브는 보통 원래 인증서가 만료되었거나 만료에 가까워진 후에 재발급이 일어나고 원래 루트 CA가 재발급해요. 자체 서명 인증서(예: 루트 인증서)의 경우 이 부모 인증서는 자기 자신이 될 거예요. 두 경우 모두 새 시리얼 번호 때문에 인증서 내용이 바뀌지만, 모든 기존 리프 서명이 여전히 검증되도록 허용해요.

교차 서명 프리미티브와 달리 이 프리미티브 유형은 모든 유형의 인증서(리프, 중간, 루트 포함)에 사용될 수 있어요.

과정 흐름

          -------------------
         | generate key pair | ---------------> ...
          -------------------                   ...
           |              |                     ...
 --------------           --------------        ...
| generate CSR |   <->   | generate CSR |       ...
 --------------           --------------        ...
         |                    |                 ...
 ------------------      ------------------     ...
| signed by issuer | -> | signed by issuer | -> ...
 ------------------      ------------------     ...

이 과정 흐름에서 단일 키 쌍이 어느 시점에 생성되고 저장돼요. (같은 요청 필드를 가진) CSR이 이 공통 키 자료에서 생성되고 여러 시점에 같은 발급자가 서명해 모든 중요한 필드(Subject, Issuer, 등)를 보존해요. 키가 재발급될 수 있는 횟수에는 엄격한 제한이 없지만, 어느 시점에는 안전상 키 자료를 계속 재발급하는 대신 키를 회전해야 한다고 판단할 거예요.

인증서 계층 구조

                          ------
              -----------| root |-------------
             /            ------              \
             |                                |
 ---------------                           ---------------
| original cert | <- same key material -> | reissued cert |
 ---------------              |            ---------------
                              |
                      -------------------
                     | leaf certificates |
                      -------------------

이것은 다시 두 개의 신뢰 경로를 만들지만, 제시된 중간 인증서 중 어느 것이 여전히 유효한지에 따라 루트만 신뢰하면 돼요. 재발급된 인증서가 루트 인증서일 때 발급 링크는 단순히 자기 루프예요. 그러나 이 경우 두 인증서 모두 (기술적으로) 서로의 유효한 발급자라는 점을 기억하세요. 즉 TLS 인증서 체인에 재발급된 루트 인증서를 제공하고 신뢰 저장소의 기존 루트 인증서로 체이닝되는 것이 가능해야 해요.

이 프리미티브 유형은 따라서 증가하는(incrementing) 프리미티브예요. 기존 키의 생명 주기가 기존 기관의 같은 키 자료로 새 인증서를 발급함으로써 미래로 확장돼요.

Vault에서의 실행

Vault에서 재발급된 루트 인증서를 만들려면 /issuers/generate/root/existing 엔드포인트를 사용해요. 이는 기존 키 자료(key_ref 요청 파라미터를 통해)로 새 루트 인증서의 생성을 허용해요. 이 과정이 성공하면 발급자 읽기 시(GET /issuer/:issuer_ref), 두 발급자(옛 것과 재발급된 것)가 서로의 ca_chain 응답 필드에 나타날 거예요(manual_chain 값이 막지 않는 한).

Vault에서 재발급된 중간 인증서를 만들려면 세 단계 과정이에요.

1. /issuers/generate/intermediate/existing 엔드포인트를 사용해 key_ref 요청 파라미터로 기존 키 자료를 가진 새 CSR을 생성해요.
2. 같은 발급자 아래에서 같은 서명 과정으로 이 CSR에 서명해요. 이 단계는 Vault일 수도 아닐 수도 있는 부모 CA에 특정합니다.
3. 마지막으로 /intermediate/set-signed 엔드포인트를 사용해 2단계의 서명된 인증서를 가져와요.

중간 인증서를 재발급하는 과정이 성공하면, 발급자 읽기 시(GET /issuer/:issuer_ref), 두 발급자(옛 것과 재발급된 것)가 첫 번째 항목을 제외하고 같은 ca_chain 응답 필드를 가질 거예요(manual_chain 값이 막지 않는 한).

참고: 발급자 유형과 무관하게 모든 관련 파라미터를 원래대로 제공하는 것이 중요해요. Vault는 예를 들어 기존 발급자에서 Subject 이름 파라미터를 추론하지 않아요. 같은 키 자료를 재사용할 뿐이에요.

시간적 (Temporal) 프리미티브

위 프리미티브 유형을 사용해 루트와 중간을 새 키로 회전하고 그 수명을 연장할 수 있어요. 이 시간 기반 회전이 궁극적으로 루트 인증서 회전을 가능하게 해요.

두 가지 주요 변형이 있어요: 옛 인증서가 새 키 자료를 승인(bless)하는 전방(forward) 프리미티브, 그리고 새 인증서가 옛 키 자료를 승인하는 후방(backwards) 프리미티브. 이 두 프리미티브 모두 앞서 언급한 신뢰 체인 문서에서 Let's Encrypt가 독립적으로 사용해요.

• DST Root CA X3에서 ISRG Root X1으로의 연결은 전방 프리미티브의 예시예요.
• ISRG Root X1에서 R3(원래 DST Root CA X3가 서명한)으로의 연결은 후방 프리미티브의 예시예요.

계층적 구조의 CA 설정을 가진 대부분의 조직에서 모든 중간을 새 루트와 옛 루트 둘 다로 교차 서명하는 것이 루트 회전에 충분해요.

그러나 루트에서 리프 인증서를 직접 발급한 조직의 경우, 이 인증서들이 계속 검증되도록 하려면 옛 루트를 새 루트 아래에서(더 짧은 기간으로) 재발급해야 해요. 이는 위의 두 프리미티브(교차 서명과 재발급)를 단일 후방 프리미티브 단계로 결합해요. 미래에는 이 조직들이 더 표준적인 계층 구조 설정으로 이동해야 할 거예요.

프리미티브의 제한 사항

인증서의 Authority Key Identifier 확장 필드는 발급자의 keyIdentifier(공개 키의 해시) 또는 발급자의 Subject와 Serial Number 필드 중 하나 또는 둘 다를 포함할 수 있어요. 후자가 활성화된(Vault에서는 다행히 불가능한데, 특히 Vault가 엄격히 무작위 시리얼 번호를 사용하므로) 인증서를 생성하면, 같은 시리얼 번호를 재발급하지 않으면 적절한 교차 서명 체인을 구축할 수 없어요. 이는 성공적인 검증에 사용되는 인증서 캐싱 때문에 대부분 브라우저의 신뢰 저장소와 검증 엔진에서 작동하지 않아요. 엄밀히 말해 (다른 CA의) 교차 서명 프리미티브를 사용할 때, 그 CA가 그 시리얼로 이전에 발급한 인증서가 없다면 중간은 같은 시리얼 번호로 재발급될 수 있어요. 이는 재발급 프리미티브를 사용할 때는 작동하지 않는데, 재발급은 기술적으로 같은 기관이라 이 기관은 고유 시리얼 번호로 인증서를 발급해야 하기 때문이에요.

제안된 루트 회전 절차

다음은 모범 사례를 따르고 있다고 가정하고, 더 넓은 조직에 (중단) 영향 없이 루트 회전을 쉽게 달성하기 위한 제안된 과정이에요. 약간의 적응이 필요할 거예요.

이 과정은 시간이 걸린다는 점을 기억하세요. 얼마나 걸릴지는 조직의 자동화 수준과 운영 인식에 달려 있어요.

1. 새 루트 인증서를 생성해요. 명확성을 위해 옛 루트 인증서와 구분되도록 새 common name을 사용하는 것을 권장해요. 키 자료는 같을 필요가 없어요.
2. 모든 기존 중간을 교차 서명해요. 그 섹션에서 논의한 대로 발급자의 manual chain을 갱신하는 것이 중요한데, 서버가 갱신·발급 시 certificate 필드를 ca_chain 필드와 결합하도록 구성되어 교차 서명된 중간을 얻는다고 가정하기 때문이에요.
3. 회전이 새 교차 서명된 중간을 가져오도록 장려해요. 짧은 수명 인증서로는 이는 자동으로 일어나야 해요. 그러나 일부 장수명 인증서의 경우 수동으로 선제적으로 회전하는 것을 권장해요. 이 단계는 시간이 걸리며 발급된 인증서 유형(예: 서버 인증서, 코드 서명, 클라이언트 인증)에 따라 달라져요.
4. 모든 체인이 갱신되면 새 시스템은 새 루트 인증서만으로 온라인에 올라올 수 있고 모든 기존 시스템에 연결할 수 있어요.
5. 기존 시스템은 이제 일회성 루트 전환으로 마이그레이션할 수 있어요: 새 루트를 추가하고 동시에 옛 루트를 제거할 수 있어요. 위 3단계가 합리적인 시간 안에 달성될 수 있다면, 대부분의 시스템을 새 루트를 완전히 사용하고 더 이상 옛 루트를 신뢰하지 않는 쪽으로 옮기는 데 걸리는 시간이 줄어들어요. 이 단계도 조직이 루트를 얼마나 빨리 마이그레이션하고 모든 그러한 시스템이 마이그레이션되도록 보장할 수 있는지에 따라 시간이 걸려요. 일부 시스템이 오프라인이고 드물게만 온라인이라면(또는 하드코딩된 인증서 저장소가 있어 먼저 폐기되어야 한다면), 조직은 다음 단계로 진행할 준비가 안 될 수 있어요.
6. 이 시점에서 모든 시스템이 새 루트를 사용하므로, 옛 루트와 중간을 안전하게 제거하거나 아카이브하고 manual chain을 엄격히 새 중간+루트를 가리키도록 갱신할 수 있어요.

이 시점에서 회전이 완전히 완료돼요.

튜토리얼 (Tutorial)

나만의 인증 기관(CA) 구축하기 가이드를 참고하면 단계별 튜토리얼을 볼 수 있어요.

PKI에 외부 관리 키를 사용하는 방법이 궁금하다면 관리 키를 사용한 PKI 시크릿 엔진도 함께 살펴보세요.

API

PKI 시크릿 엔진은 완전한 HTTP API를 제공해요. 자세한 내용은 PKI 시크릿 엔진 API 문서를 참고해 주세요.

더 알아보기 (Learn more)

• 회전과 관련된 고려 사항은 PKI 시크릿 엔진 고려 사항 문서를 참고하세요.
• Vault PKI 시크릿 엔진 전체 API는 PKI API 문서를 참고하세요.