Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Движки секретов. PKI (API)

В данном разделе представлена документация для движка секретов StarVault PKI. Для общей информации об использовании и функционировании движка секретов PKI см. документацию по PKI.

Данный движок может использовать внешние сертификаты X.509 в качестве части валидации TLS или подписи. Верификация подписей против сертификатов X.509, использующих SHA-1, устарела и больше не может быть использована без обходных решений.

Документация предполагает, что движок секретов PKI включен по пути /pki в StarVault. Поскольку возможно включение движков секретов в любом месте, пожалуйста, обновите свои API-вызовы соответствующим образом.

1. Содержание

2. Примечание о новой мультииздательской функциональности

StarVault позволяет одному монтированию PKI иметь несколько сертификатов Центра сертификации (CA) ("издателей") в одном монтировке, с целью облегчения ротации. Все издатели в едином монтировании рассматриваются как единый орган, это означает, что:

  • Конфигурация списка отзывов сертификатов (CRL) общая для всех издателей;

  • Все URL-адреса доступа к органу общие для всех издателей;

  • Серийные номера выданных сертификатов будут уникальны по всем издателям.

Однако, поскольку каждый издатель может иметь отличающийся субъект и ключи, разные издатели могут иметь разные CRL.

Настоятельно рекомендуется ограничить область действия CAs в пределах монтирования и не смешивать разные типы CAs (корневые и промежуточные).

Некоторая функциональность не будет работать, если не настроен стандартный издатель. StarVault автоматически выбирает стандартного издателя из текущего выдаваемого сертификата при миграции с более ранней версии StarVault.

3. Выдача сертификатов ACME

StarVault поддерживает протокол управления жизненным циклом сертификатов ACME для выдачи и обновления сертификатов серверов-листьев.

Чтобы использовать ACME, необходимо установить путь к кластеру и ACME должен быть включен в его конфигурацию с необходимыми заголовками, включенными в регулировку монтирования.

Использование ACME с ролью требует установки no_store=false на роль; это позволяет сохранять сертификат для последующего получения через протокол ACME.

3.1. Каталоги ACME

StarVault PKI поддерживает следующие каталоги ACME, предоставляющие различные ограничения по использованию (по умолчанию, для конкретного издателя и/или для конкретной роли). Чтобы взаимодействовать с этими каталогами, укажите URL каталога в ACME-клиенте. Например, с помощью CertBot:

$ certbot certonly --server https://localhost:8200/v1/pki/acme/directory ...

Эти конечные точки не требуют аутентификации в модели аутентификации StarVault, но внутри аутентифицированы через протокол ACME.

Метод Путь Политика каталога по умолчанию Издатель Роль

ACME

/pki/acme/directory

sign-verbatim

default

Sign-Verbatim

ACME

/pki/acme/directory

role:role_ref

Определяется ролью

:role_ref

ACME

/pki/issuer/:issuer_ref/acme/directory

sign-verbatim

:issuer_ref

Sign-Verbatim

ACME

/pki/issuer/:issuer_ref/acme/directory

role:role_ref

:issuer_ref

:role_ref

ACME

/pki/roles/:role/acme/directory

(любой)

Определяется ролью

:role

ACME

/pki/issuer/:issuer_ref/roles/:role/acme/directory

(любой)

:issuer_ref

:role

Когда роль не указана (для первых двух URL каталогов или четырех строк в таблице), поведение задается default_directory_policy в конфигурации ACME. Эти каталоги также могут быть запрещены, установив эту политику как forbid. Если политика sign-verbatim, то любой идентификатор, для которого клиент может доказать владение, будет выдан. Это похоже на использование конечной точки Sign Verbatim, но с дополнительной проверкой, что клиент доказал владение (в рамках протокола ACME) запрашиваемыми идентификаторами сертификата.

3.1.1. Типы вызовов ACME

StarVault в настоящее время поддерживает следующие типы вызовов ACME:

  • http-01, поддерживающий как dns, так и ip идентификаторы.

  • dns-01, поддерживающий dns идентификаторы, включая подстановочные знаки.

  • tls-alpn-01, поддерживающий только не подстановочные dns идентификаторы.

Дополнительный DNS-резолвер, используемый сервером для поиска DNS-имен для использования с обеими механизмами, можно добавить через конфигурацию ACME.

Политика привязки внешней учетной записи ACME (EAB) может требовать от клиентов наличия валидной внешней привязки учетной записи к StarVault. Перед регистрацией новой учетной записи аутентифицированному клиенту StarVault необходимо получить новый токен EAB. Это возвращает два значения: идентификатор ключа и HMAC-ключ, используемый клиентом ACME для аутентификации с EAB. Например:

 $ starvault write -f /pki/acme/new-eab
 $ certbot certonly --server https://localhost:8200/v1/pki/acme/directory \
                    --eab-kid <id> --eab-hmac-key <hmac-key>

С EAB или без EAB запросы от клиента ACME не аутентифицируются с использованием традиционной аутентификации StarVault, а вместо этого аутентифицируются через протокол ACME. Однако с EAB аутентифицированному клиенту StarVault необходимо будет получить токен EAB и передать его клиенту ACME для использования при первоначальной регистрации: это связывает регистрацию клиента ACME с аутентифицированной конечной точкой StarVault, но не связывает ее далее с сущностью клиента или другой информацией.

Включение EAB настоятельно рекомендуется для общедоступных раз deployments StarVault. Использование переменной окружения VAULT_DISABLE_PUBLIC_ACME может быть использовано для обеспечения включения EAB во всех инстансах ACME.

3.1.3. Необходимые заголовки ACME

ACME требует, чтобы следующие заголовки ответа (allowed_response_headers) были указаны в регулировке монтирования:

  • Replay-Nonce

  • Link

  • Location

На существующем монтировании эти параметры можно указать, выполнив следующую команду:

 $ starvault secrets tune -allowed-response-headers=Location -allowed-response-headers=Replay-Nonce \
                      -allowed-response-headers=Link \
                      pki/

3.2. Получить токен привязки EAB ACME

Эта конечная точка возвращает новый токен привязки EAB ACME. Поле id в ответе может быть использовано как идентификатор ключа, а поле key — как ключ EAB HMAC в клиенте ACME.

Каждый вызов к этой конечной точке сгенерирует и вернет новый токен привязки EAB, который связан с конкретным каталогом ACME, к которому он принадлежит. Токены EAB не могут быть использованы в разных каталогах ACME.

Метод Путь

POST

/pki/acme/new-eab

POST

/pki/issuer/:issuer_ref/acme/new-eab

POST

/pki/roles/:role/acme/new-eab

POST

/pki/issuer/:issuer_ref/roles/:role/acme/new-eab

3.2.1. Параметры

Нет параметров.

Пример запроса:
 $ curl \
     --header "X-Vault-Token: ..." \
     --request POST \
     http://127.0.0.1:8200/v1/pki/acme/new-eab
Пример ответа:
{
  "data":
  {
    "created_on": "2025-07-30T14:33:00-04:00",
    "id": "bc8088d9-3816-5177-ae8e-d8393265f7dd",
    "key_type": "hs",
    "acme_directory": "acme/directory",
    "key": "MHcCAQE... дополнительные данные упущены ...",
  }
}

3.3. Список неиспользуемых токенов привязки EAB ACME

Эта конечная точка возвращает список всех неиспользуемых токенов привязки EAB ACME; как только токены были использованы, они будут удалены из этого списка.

Метод Путь

LIST

/pki/eab

3.3.1. Параметры

  • after (string: "") - необязательную запись, с которой начать перечисление для постраничной навигации; не обязательно должна существовать.

  • limit (int: 0) - необязательное количество записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
 $ curl \
     --header "X-Vault-Token: ..." \
     --request LIST \
     http://127.0.0.1:8200/v1/pki/eab
Пример ответа:
{
  "data": {
    "key_info": {
      "bc8088d9-3816-5177-ae8e-d8393265f7dd": {
        "created_on": "2025-07-30T14:33:00-04:00",
        "key_type": "hs",
        "acme_directory": "acme/directory"
      }
    },
    "keys": [
      "bc8088d9-3816-5177-ae8e-d8393265f7dd"
    ]
  }
}

3.4. Удаление неиспользуемых токенов привязки EAB ACME

Эта конечная точка позволяет удалить неиспользуемый токен привязки EAB ACME.

Метод Путь

DELETE

/pki/eab/:key_id

3.4.1. Параметры

  • key_id (string: <required>) - идентификатор токена привязки EAB для удаления. Это часть URL запроса.

Пример запроса:
 $ curl \
     --header "X-Vault-Token: ..." \
     --request DELETE \
     http://127.0.0.1:8200/v1/pki/eab/bc8088d9-3816-5177-ae8e-d8393265f7dd

3.5. Получить конфигурацию ACME

Эта конечная точка позволяет читать текущую конфигурацию сервера ACME, используемую данным монтированием.

Метод Путь

GET

/pki/config/acme
Пример запроса:
 $ curl \
     --header "X-Vault-Token: ..." \
     http://127.0.0.1:8200/v1/pki/config/acme
Пример ответа:
{
  "data": {
    "allowed_issuers": [
      "*"
    ],
    "allowed_roles": [
      "*"
    ],
    "default_directory_policy": "sign-verbatim",
    "dns_resolver": "",
    "eab_policy": "not-required",
    "enabled": true
  },
}

3.6. Установка конфигурации ACME

Эта конечная точка позволяет устанавливать конфигурацию сервера ACME, используемую данным монтированием.

Метод Путь

POST

/pki/config/acme

3.6.1. Параметры

  • allowed_issuers (list: [""]) - указывает список издателей, которым разрешено выдавать сертификаты через явные пути ACME. Если разрешенная роль указывает издателя вне этого списка, это будет разрешено. Значение по умолчанию разрешает каждого издателя в пределах монтирования.

  • allow_role_ext_key_usage (bool: false) - указывает, используется ли поле ExtKeyUsage из роли, значение по умолчанию - false, что означает, что сертификат будет подписан с ServerAuth.

  • allowed_roles (list: [""]) - указывает список ролей, которым разрешено выдавать сертификаты через явные пути ACME. Значение по умолчанию позволяет использовать любую роль в пределах монтирования. Если default_directory_policy указывает роль, она должна быть разрешена в рамках этой конфигурации.

  • default_directory_policy (string: "sign-verbatim") - указывает поведение каталога ACME по умолчанию. Могут быть значения forbid, sign-verbatim или роль, заданная role:<role_name>. Если используется роль, она должна быть представлена в allowed_roles.

  • dns_resolver (string: "") - необязательный переопределяющий DNS-резолвер, который будет использоваться для проверки верификации вызовов. Если не указано, будет использован стандартный системный резолвер. Это позволяет проверять домены в пировых сетях с доступным DNS-резолвером.

  • eab_policy (string: "not-required") - политика, установленная для применения к внешним привязкам учетных записей (EAB).

    Допустимые значения значения:

    • not-required - используется там, где EAB не требуется, но проверяется, если указано.

    • new-account-required - используется в случае, когда новые учетные записи должны иметь EAB, но существующие учетные записи все еще могут быть использованы.

    • always-required - используется, когда все учетные записи (независимо от возраста) должны иметь EAB.

  • enabled (bool: false) - указывает, включен ли ACME на данном монтировании. Когда ACME отключен, все запросы к URL-адресам каталога ACME будут возвращать 404.

Пример тела запроса:
{
    "enabled": true
}
Пример запроса:
 $ curl \
     --header "X-Vault-Token: ..." \
     --request POST \
     --data @payload.json \
     http://127.0.0.1:8200/v1/pki/config/acme
Пример ответа:
{
  "data": {
    "allowed_issuers": [
      "*"
    ],
    "allowed_roles": [
      "*"
    ],
    "default_directory_policy": "sign-verbatim",
    "dns_resolver": "",
    "eab_policy": "not-required",
    "enabled": true
  }
}

4. Выдача сертификатов

Следующие конечные точки API позволяют пользователям или операторам запрашивать сертификаты и все они требуют аутентификации.

В общем, для самообслуживания, /pki/sign/:name и /pki/issue/:name достаточно, чтобы предоставить доступ большинству пользователей для целей ACL. Варианты по каждому издателю (/pki/issuer/:issuer_ref/sign/:name и /pki/issuer/:issuer_ref/issue/:name) позволяют запрашивающему переопределить выбранный ролью издатель, потенциально позволяя пользователям запрашивать сертификаты, выданные неверной родительской инстанцией.

Некоторые API-методы, включенные здесь, являются привилегированными и должны быть доступны только доверенным пользователям или операторам; к ним относятся многие sign-verbatim, sign-self-signed и sign-intermediate конечные точки.

Если выданный сертификат был скомпрометирован, его следует отозвать. Движок секретов StarVault PKI в настоящее время позволяет отзывать сертификаты только по серийному номеру; поскольку это может позволить пользователям лишать других пользователей доступа, это должно быть зарезервировано для операторов.

4.1. Список ролей

Эта конечная точка возвращает список доступных ролей. Возвращаются только имена ролей, не значения. Это полезно как для операторов, так и для пользователей.

Метод Путь

LIST

/pki/roles

4.1.1. Параметры

  • after (string: "") - необязательная запись для начала перечисления после для постраничной навигации; не требуется существовать;

  • limit (int: 0) - необязательное количество записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/roles
Пример ответа:
{
  "auth": null,
  "data": {
    "keys": ["dev", "prod"]
  },
  "lease_duration": 0,
  "lease_id": "",
  "renewable": false
}

4.2. Чтение роли

Эта конечная точка запрашивает определение роли. Она полезна как для операторов, так и для пользователей.

Метод Путь

GET

/pki/roles/:name

4.2.1. Параметры

  • name (string: <required>) - указывает имя роли для чтения. Это является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/roles/my-role
Пример ответа:
{
  "data": {
    "allow_any_name": false,
    "allow_ip_sans": true,
    "allow_localhost": true,
    "allow_subdomains": false,
    "allowed_domains": ["example.com", "foobar.com"],
    "allowed_uri_sans": ["example.com", "spiffe://*"],
    "allowed_other_sans": [
      "1.3.6.1.4.1.311.20.2.3;utf8:devops@example.com",
      "1.3.6.1.4.1.311.20.2.4;UTF-8:*"
    ],
    "client_flag": true,
    "code_signing_flag": false,
    "key_bits": 2048,
    "key_type": "rsa",
    "ttl": "6h",
    "max_ttl": "12h",
    "server_flag": true,
    ... дополнительные поля опущены ...
  }
}

4.3. Генерация сертификата и ключа

Эта конечная точка генерирует новый набор учетных данных (закрытый ключ и сертификат) на основе роли, указанной в конечной точке. Сертификат CA и полная цепочка CA также возвращаются, так что только корневой CA должен быть в хранилище доверенных сертификатов клиента. Выбор CA определяется сначала ролью (при использовании пути /pki/issue/:name), а затем путем (при использовании шага /pki/issuer/:issuer_ref/issue/name).

Рекомендуется ограничить доступ к переопределенной конечной точке выдачи (на /pki/issuer/:issuer_ref/issue/:name).

Закрытый ключ не хранится. Если вы не сохраните закрытый ключ из ответа, вам потребуется запросить новый сертификат.
Метод Путь Издатель

POST

/pki/issue/:name

Выбранная роль

POST

/pki/issuer/:issuer_ref/issue/:name

Выбранный путь

4.3.1. Параметры

  • name (string: <required>) - указывает имя роли, против которой будет создан сертификат. Это является частью URL запроса.

  • issuer_ref (string: <required>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Этот параметр отсутствует в пути /pki/issue/:name и принимает значение из поля issuer_ref роли.

  • common_name (string: "") - указывает запрашиваемый CN для сертификата. Если CN допускается политикой роли, он будет выдан. Если требуется более одного common_name, укажите альтернативные имена в списке alt_names.

Значение для common_name требуется, когда require_cn установлено в true.

  • alt_names (string: "") - указывает запрашиваемые альтернативные имена субъектов, в виде списка, разделенного запятыми. Это могут быть имена хостов или адреса электронной почты; они будут разобраны в соответствующие поля. Если любые запрашиваемые имена не соответствуют политике роли, будут отклонены все запросы.

  • ip_sans (string: "") - указывает запрашиваемые IP альтернативные имена субъектов, в виде списка, разделенного запятыми. Действительно только если роль позволяет IP SAN (что является стандартным значением).

  • uri_sans (string: "") - указывает запрашиваемые URI альтернативные имена субъектов, в виде списка, разделенного запятыми. Если любые запрашиваемые URI не соответствуют политике роли, будет отклонен весь запрос.

  • other_sans (string: "") - указывает пользовательские OID/UTF8-строковые SAN. Это должно соответствовать значениям, указанным в роли в allowed_other_sans (см. создание роли для правил глоббинга allowed_other_sans). Формат аналогичен OpenSSL: <oid>;<type>:<value>, где единственный допустимый тип - UTF8. Это может быть список, разделенный запятыми, или часть строки JSON.

  • ttl (string: "") - указывает запрашиваемое время жизни. Не может превышать значение max_ttl роли. Если не указано, будет использовано значение ttl роли. Обратите внимание, что значения роли по умолчанию соответствуют системным значениям, если они не были явно установлены. Смотрите not_after как альтернативу для установки абсолютной даты завершения (вместо относительной).

  • format (string: "pem") - указывает формат для возвращаемых данных. Может быть pem, der или pem_bundle; значение по умолчанию - pem. Если der, вывод будет закодирован в base64. Если pem_bundle, поле certificate будет содержать закрытый ключ и сертификат, объединенные; если издатель не является самоподписанным корневым издателем StarVault, это также будет включено.

  • private_key_format (string: "der") - указывает формат для сериализации закрытого ключа в поле ответа private_key. Значение по умолчанию - der, что вернет либо base64-кодированный DER, либо PEM-кодированный DER в зависимости от значения format. Другим вариантом является pkcs8, который вернет ключ, сериализованный как PEM-кодированный PKCS8.

Перечисленное выше не относится к закрытому ключу внутри поля сертификата, если указан параметр format=pem_bundle.

  • exclude_cn_from_sans (bool: false) - если установлено в true, указанный common_name не будет включен в альтернативные имена субъектов DNS или электронной почты (в зависимости от случая). Полезно, если CN не является именем хоста или адресом электронной почты, а вместо этого представляет собой некоторый идентификатор, понятный человеку.

  • not_before (string) - указывает поле "Not Before" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Это значение не влияет на срок действия запрашиваемого сертификата, указанное в поле ttl.

  • not_after (string) - установите поле "Not After" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z.

  • remove_roots_from_chain (bool: false) - если установлено в true, возвращенное поле ca_chain не будет включать никаких самоподписанных сертификатов CA. Полезно, если конечные пользователи уже имеют корневой CA в своем хранилище доверенных сертификатов.

  • user_ids (string: "") - указывает запрашиваемый список идентификаторов пользователя (OID 0.9.2342.19200300.100.1.1) в значениях субъектов, которые будут размещены на подписанном сертификате. Это поле проверяется по полю allowed_user_ids на роли.

  • key_type (string: "") - указывает желаемый тип ключа, когда роль допускает любой тип ключа; должен быть rsa, ed25519 или ec. Используйте буквальную пустую строку, когда необходимо уважать тип ключа роли.

  • key_bits (int: 0) - указывает количество бит для использования для сгенерированных ключей, когда роль допускает любой тип ключа. Допустимые значения: 0 (универсальное значение по умолчанию); при key_type=rsa, допустимые значения: 2048 (по умолчанию), 3072 или 4096; при key_type=ec, допустимые значения: 224, 256 (по умолчанию), 384 или 521; игнорируется при key_type=ed25519. Игнорируется, когда у роли есть явно указанный тип ключа.

Пример тела запроса:
{
  "common_name": "www.example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/issue/my-role
Пример ответа:
{
  "lease_id": "pki/issue/test/7ad6cfa5-f04f-c62a-d477-f33210475d05",
  "renewable": false,
  "lease_duration": 21600,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
    ],
    "private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEAnVHfwoKsUG1GDVyWB1AFroaKl2ImMBO8EnvGLRrmobIkQvh+\n...\nQN351pgTphi6nlCkGPzkDuwvtxSxiCWXQcaxrHAL7MiJpPzkIBq1\n-----END RSA PRIVATE KEY-----\n",
    "private_key_type": "rsa",
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
  },
  "warnings": "",
  "auth": null
}

4.4. Подпись сертификата

Эта конечная точка подписывает новый сертификат на основе предоставленного CSR и указанных параметров, с учетом ограничений, содержащихся в роли, указанной в конечной точке. Сертификат CA и полная цепочка CA также возвращаются, так что только корневой CA должен быть в хранилище доверенных сертификатов клиента.

Рекомендуется ограничить доступ к переопределенной конечной точке подписания (на /pki/issuer/:issuer_ref/sign/:name).

Метод Путь Издатель

POST

/pki/sign/:name

Выбранная роль

POST

/pki/issuer/:issuer_ref/sign/:name

Выбранный путь

4.4.1. Параметры

  • name (string: <required>) - указывает имя роли, против которой будет создан сертификат. Это является частью URL запроса.

  • issuer_ref (string: <required>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Данный параметр отсутствует в пути /pki/sign/:name и принимает значение из поля issuer_ref роли.

  • csr (string: <required>) - указывает PEM-кодированный CSR.

  • common_name (string: <required>) - указывает запрашиваемый CN для сертификата. Если CN допускается политикой роли, он будет выдан. Если требуется более одного common_name, укажите альтернативные имена в списке alt_names.

  • alt_names (string: "") - указывает запрашиваемые альтернативные имена субъектов, в списке, разделенном запятыми. Это могут быть имена хостов или адреса электронной почты; они будут разобраны в их соответствующие поля. Если любые запрашиваемые имена не соответствуют политике роли, будет отклонён весь запрос.

  • other_sans (string: "") - указывает пользовательские OID/UTF8-строковые SANs. Эти должны соответствовать значениями, указанными в роли в allowed_other_sans (см. создание роли для правил глоббинга allowed_other_sans). Формат аналогичен OpenSSL: <oid>;<type>:<value> где единственный текущий допустимый тип - UTF8. Это может быть список, разделенный запятыми, или полоса JSON-строк.

  • ip_sans (string: "") - указывает запрашиваемые IP альтернативные имена субъектов, в списке, разделенном запятыми. Действительно только если роль позволяет IP SAN (что является стандартным значением).

  • uri_sans (string: "") - указывает запрашиваемые URI альтернативные имена субъектов, в списке, разделенном запятыми. Если любые запрашиваемые URI не соответствуют политике роли, будет отклонён весь запрос.

  • ttl (string: "") - указывает запрашиваемое время жизни. Не может превышать значение max_ttl роли. Если не указано, будет использовано значение ttl роли. Обратите внимание, что значения роли по умолчанию соответствуют системным значениям, если они не были явно установлены. См. not_after как альтернативу для установки абсолютной даты завершения (вместо относительной).

  • format (string: "pem") - указывает формат для возвращаемых данных. Может быть pem, der или pem_bundle. Если der, вывод будет закодирован в base64. Если pem_bundle, поле certificate будет содержать сертификат и, если Юридический адрес CA не является самоподписанным корнем StarVault, это будет объединино с сертификатом.

  • exclude_cn_from_sans (bool: false) - если установлен в true, данный common_name не будет включен в альтернативные имена субъектов DNS или электронной почты (в зависимости от ситуации). Полезно, если CN не является именем хоста или адресом электронной почты, а вместо этого является некоторым идентификатором, удобным для чтения.

  • not_after (string) - установите поле Not After сертификата с указанным значением даты. Формат значения должен быть в UTC в формате YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z`.

  • remove_roots_from_chain (bool: false) - если установлен в true, возвращенное поле ca_chain не будет содержать никаких самоподписанных сертификатов CA. Полезно, если конечные пользователи уже имеют корневой CA в своем хранилище доверенных сертификатов.

  • user_ids (string: "") - указывает список запрошенных пользовательских идентификаторов (OID 0.9.2342.19200300.100.1.1) для размещения на подписанном сертификате. Это поле проверяется по allowed_user_ids роли.

Пример тела запроса:
{
  "csr": "...",
  "common_name": "example.com"
}
Пример ответа:
{
  "lease_id": "pki/sign/test/7ad6cfa5-f04f-c62a-d477-f33210475d05",
  "renewable": false,
  "lease_duration": 21600,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
    ],
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
  },
  "auth": null
}

4.5. Подписание промежуточного

Эта конечная точка использует настроенный сертификат CA для выдачи сертификата с подходящими значениями для действия в качестве промежуточного CA. Точки распределения используют значения установленные через config/urls. Значения, указанные в CSR, игнорируются, если use_csr_values установлен в true, в этом случае значения из CSR используются дословно.

Эта конечная точка может использоваться как при подписании промежуточного, поддерживаемого StarVault, так и при подписании промежуточного, принадлежащего третьим лицам.

Это привилегированная конечная точка, поскольку вызвавшие лица получают новый промежуточный сертификат, с помощью которого они могут выдавать сертификаты для произвольных имен. Доступ к этой конечной точке должен быть ограничен политикой только для доверенных операторов.
Метод Путь Издатель

POST

/pki/root/sign-intermediate

default

POST

/pki/issuer/:issuer_ref/sign-intermediate

Selected

4.5.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Этот параметр отсутствует в пути /pki/root/sign-intermediate и получает значение default.

  • csr (string: <обязательный>) - указывает PEM-кодированный CSR, который будет подписан. * common_name (string: <обязательный>) - указывает запрашиваемый CN для сертификата. Если требуется более одного common_name, укажите альтернативные имена в списке alt_names.

  • alt_names (string: "") - указывает запрашиваемые альтернативные имена субъектов, в виде списка, разделенного запятыми. Это могут быть имена хостов или адреса электронной почты; они будут разобраны в соответствующие поля.

  • ip_sans (string: "") - указывает запрашиваемые IP альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • uri_sans (string: "") - указывает запрашиваемые URI альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • other_sans (string: "") - указывает пользовательские OID/UTF8-строковые SANs. Эти должны соответствовать значениям, указанным в роли в allowed_other_sans (см. создание роли для правил глоббинга allowed_other_sans). Формат аналогичен OpenSSL: <oid>;<type>:<value>, где единственный допустимый тип - UTF8. Это может быть список, разделенный запятыми, или часть строки JSON.

  • ttl (string: "") - указывает запрашиваемое время жизни (после которого сертификат будет просрочен). Это не может превышать максимальное значение движка (или, если не установлено, системный максимум). Тем не менее, это может быть после истечения срока действия подписывающего CA. См. not_after как альтернативу для установки абсолютной даты завершения (вместо относительной).

  • format (string: "pem") - указывает формат для возвращаемых данных. Может быть pem, der или pem_bundle. Если der, вывод будет закодирован в base64. Если pem_bundle, поле certificate будет содержать сертификат и, если выпускающий CA не является корневым самоподписанным сертификатом StarVault, он будет объединен с сертификатом.

  • max_path_length (int: -1) - указывает максимальную длину пути, которую нужно закодировать в сгенерированном сертификате. -1 означает отсутствие ограничений, если у сертификата, подписывающего сертификата, нет установленной максимальной длины пути; в этом случае длина пути устанавливается на одно меньшее значение, чем у подписывающего сертификата. Ограничение 0 означает буквальную длину пути ноль.

  • exclude_cn_from_sans (bool: false) - если установлено в true, указанный common_name не будет включен в альтернативные имена субъектов DNS или электронной почты (в зависимости от ситуации). Полезно, если CN не является именем хоста или адресом электронной почты, а вместо этого является некоторым идентификатором, понятным человеку.

  • use_csr_values (bool: false) - если установлено в true, то: 1) Информация о субъекте, включая имена и альтернативные имена, будет сохранена из CSR, а не используя значения, предоставленные в других параметрах для этого пути; 2) Любые использования ключей (например, неповиновение), запрошенные в CSR, будут добавлены к базовому набору использований ключей, используемых для сертификатов CA, подписанных этим путем; 3) Расширения, запрошенные в CSR, будут скопированы в выданный сертификат.

  • permitted_dns_domains (string: "") - строка, разделенная запятыми (или строковый массив), содержащая DNS-домены, для которых сертификаты могут выдавать или подписывать этот сертификат CA. Поддерживает поддомены через . перед доменом, в соответствии с RFC 5280 Раздел 4.2.1.10 - Ограничения имен.

  • ou (string: "") - указывает значения OU (OrganizationalUnit) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • organization (string: "") - указывает значения O (Organization) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • country (string: "") - указывает значения C (Country) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • locality (string: "") - указывает значения L (Locality) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • province (string: "") - указывает значения ST (Province) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • street_address (string: "") - указывает значения Улица в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • postal_code (string: "") - указывает значения почтового кода в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • serial_number (string: "") - указывает запрашиваемые значения субъекта Серийный номер, если есть. Если вы хотите больше одного, укажите альтернативные имена в alt_names, используя OID 2.5.4.5. Обратите внимание, что это не влияет на поле серийного номера сертификата, которое StarVault генерирует случайным образом.

  • not_before_duration (duration: "30s") - указывает продолжительность, на которую необходимо вернуть поле NotBefore. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl. Использует формат строк продолжительности.

  • not_before (string) - указывает поле "Not Before" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl.

  • not_after (string) - установите поле "Not After" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z.

  • signature_bits (int: 0) - указывает количество бит, которые следует использовать в алгоритме подписи; принимает 256 для SHA-2-256, 384 для SHA-2-384, и 512 для SHA-2-512. По умолчанию 0 для автоматического определения на основе длины ключа подписчика (SHA-2-256 для RSA-ключей и соответствующего размера кривой для NIST P-Curve).

    Издатели ECDSA и Ed25519 не следуют конфигурации значения signature_bits; только издатели RSA будут изменять типы подписей в зависимости от этого параметра.

  • skid (string: "") - значение для поля идентификатора ключа субъекта (RFC 5280 Раздел 4.2.1.2). Указывается как строка в шестнадцатеричном формате. По умолчанию пусто, позволяя StarVault автоматически рассчитывать SKID в соответствии с первым методом в указанном выше разделе RFC.

    Это значение следует использовать ТОЛЬКО при кросс-подписании, чтобы смоделировать существующее значение SKID сертификата; это необходимо, чтобы позволить определенным реализациям TLS (таким как OpenSSL), которые используют совпадение SKID/AKID в построении цепочки, ограничивать возможные действительные цепочки.

  • use_pss (bool: false) - указывает, следует ли использовать PSS подписи вместо PKCS#1v1.5 подписей, когда используется эмитент типа RSA. Игнорируется для эмитентов ECDSA/Ed25519.

  • key_usage (list: ["KeyAgreement", "KeyEncipherment"]) - указывает стандартное ограничение использования ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#KeyUsage - просто опустите часть KeyUsage из значения. Значения не чувствительны к регистру.

  • ext_key_usage (list: []) - указывает стандартное ограничение на использование расширенного ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#ExtKeyUsage - просто опустите часть ExtKeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие стандартных ограничений на использование ключа, установите это в пустой список.

  • ext_key_usage_oids (string: "") - строка, разделенная запятыми, или список OID расширенного использования ключа.

    Это значение используется только как стандартное, когда расширение ExtendedKeyUsage отсутствует в CSR.
Пример тела запроса:
{
  "csr": "...",
  "common_name": "example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/root/sign-intermediate
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
    ],
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
  },
  "auth": null
}

4.6. Подписать самоподписанный

Эта конечная точка использует настроенный сертификат CA для подписания самоподписанного сертификата (который обычно также является самоподписанным сертификатом).

Данная конечная точка является крайне привелегированной. Указанный сертификат будет подписан как есть с минимальным выполнением проверки (является ли он сертификатом CA и является ли он фактически самоподписанным). Единственные значения, которые будут изменены, будут идентификатор ключа удостоверяющего центра, DN эмитента и, если указано, любые точки распространения.

Рекомендуется ограничить эту конечную точку только для доверенных операторов.

Это обычно необходимо только для ротации корневых сертификатов в случаях, когда вы не хотите или не можете получить доступ к CSR (например, если это корень, хранящийся в StarVault, где ключ не раскрыт). Если вы не знаете, необходимо ли вам использовать эту конечную точку, вы, вероятно, должны использовать другую конечную точку (такую как sign-intermediate).

Метод Путь Издатель Требует возможности sudo

POST

/pki/root/sign-self-issued

default

да

POST

/pki/issuer/:issuer_ref/sign-self-issued

Выбранный

нет

4.6.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

    Этот параметр отсутствует в пути /pki/root/sign-self-issued и получает значение default.

  • certificate (string: <обязательный>) - указывает PEM-кодированный самоподписанный сертификат.

  • require_matching_certificate_algorithms (bool: false) - если установлено в true, требует, чтобы публичный алгоритм ключа CA совпадал с алгоритмом сертификата, который был отправлен.

Пример тела запроса:
{
  "certificate": "..."
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/root/sign-self-issued
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
  },
  "auth": null
}

4.7. Подписать дословно

Эта конечная точка подписывает новый сертификат на основе предоставленного CSR. Значения принимаются дословно из CSR; единственное ограничение заключается в том, что эта конечная точка откажется выдать сертификат промежуточного CA (см. конечную точку /pki/root/sign-intermediate для этой функциональности).

Это потенциально опасная конечная точка, и доступ должен иметь только высоко доверенные пользователи.
Метод Путь Издатель

POST

/pki/sign-verbatim(/:name)

default

POST

/pki/issuer/:issuer_ref/sign-verbatim(/:name)

Выбранный

4.7.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Этот параметр отсутствует в пути /pki/root/sign-self-issued и получает значение default.

  • name (string: "") - указывает роль. Если установлено, следующие параметры из роли будут иметь эффект: ttl, max_ttl, generate_lease, no_store, not_before_duration и basic_constraints_valid_for_non_ca. Однако, если параметр basic_constraints_valid_for_non_ca явно указан в запросе к API, он имеет приоритет над значением, установленным в роли.* csr (string: <обязательный>) - указывает PEM-кодированный CSR.

  • key_usage (list: ["DigitalSignature", "KeyAgreement", "KeyEncipherment"]) - указывает стандартное ограничение на использование ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#KeyUsage - просто опустите часть KeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие стандартных ограничений на использование ключа, установите это в пустой список.

  • ext_key_usage (list: []) - указывает стандартное ограничение на использование расширенного ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#ExtKeyUsage - просто опустите часть ExtKeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие стандартных ограничений на использование ключа, установите это в пустой список.

  • ext_key_usage_oids (string: "") - строка, разделенная запятыми, или список OID расширенного использования ключа.

    Это значение используется только как стандартное, когда расширение ExtendedKeyUsage отсутствует в CSR.

  • ttl (string: "") - указывает запрашиваемое время жизни. Не может превышать значение max_ttl движка. Если не предоставлено, будет использовано значение ttl движка, которое по умолчанию соответствует системным значениям, если не установлено явно. См. not_after как альтернативу для установки абсолютной даты завершения (вместо относительной).

  • format (string: "pem") - указывает формат возвращаемых данных. Может быть pem, der или pem_bundle. Если der, вывод будет закодирован в base64. Если pem_bundle, поле certificate будет содержать сертификат и, если выпускающий CA не является самоподписанным корнем StarVault, он будет объединен с сертификатом.

  • not_before (string) - указывает поле "Not Before" сертификата с указанным значением даты. Формат значения должен быть в UTC в формате YYYY-MM-ddTHH:MM:SSZ. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl.

  • not_after (string) - установите поле "Not After" сертификата с указанным значением даты. Формат значения должен быть в UTC в формате YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z.

  • signature_bits (int: 0) - указывает количество бит, чтобы использовать в алгоритме подписи; принимает 256 для SHA-2-256, 384 для SHA-2-384, и 512 для SHA-2-512. По умолчанию 0 для автоматического определения на основе длины ключа издателя (SHA-2-256 для RSA-ключей и соответствующего размера кривой для NIST P-Кривых).

    Издатели ECDSA и Ed25519 не следуют конфигурации значения signature_bits; только издатели RSA будут изменять типы подписей в зависимости от этого параметра.

  • use_pss (bool: false) - указывает, следует ли использовать PSS подписи вместо PKCS#1v1.5 подписей, когда используется эмитент типа RSA. Игнорируется для Эмитентов ECDSA/Ed25519.

  • remove_roots_from_chain (bool: false) - если установлено в true, возвращенное поле ca_chain не будет включать никаких самоподписанных сертификатов CA. Полезно, если конечные пользователи уже имеют корневой CA в своем хранилище доверенных сертификатов.

  • user_ids (string: "") - указывает запрашиваемый список пользовательских идентификаторов (OID 0.9.2342.19200300.100.1.1) субъектов, которые будут размещены на подписанном сертификате. Проверка имен при использовании этой конечной точки не выполняется.

  • basic_constraints_valid_for_non_ca (bool: false) - указывает, являются ли основные ограничения действительными при выдаче не-CA сертификатов. Когда конечная точка используется с ролью, этот параметр переопределяет значение basic_constraints_valid_for_non_ca, установленное в роли.

Пример тела запроса:
{
  "csr": "...",
  "common_name": "example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/sign-verbatim
Пример ответа:
{
  "lease_id": "pki/sign/test/7ad6cfa5-f04f-c62a-d477-f33210475d05",
  "renewable": false,
  "lease_duration": 21600,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
    ],
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
  },
  "auth": null
}

4.8. Список ролей CEL

Эта конечная точка возвращает список доступных ролей CEL. Возвращаются только имена ролей, не значения. Это полезно как для операторов, так и для пользователей.

Метод Путь

LIST

/pki/cel/roles

4.8.1. Параметры

  • after (string: "") - необязательная запись для начала перечисления после для постраничной навигации; не требуется существовать.

  • limit (int: 0) - необязательное количество записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/cel/roles
Пример ответа:
{
  "request_id": "8aa74f79-6e7f-9157-38fd-2a66b1be9071",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": { "keys": ["testrole"] },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

4.9. Чтение роли CEL

Эта конечная точка запрашивает определение роли CEL. Она полезна как для операторов, так и для пользователей.

Метод Путь

GET

/pki/cel/roles/:name

4.9.1. Параметры

  • name (string: <обязательный>) - указывает имя роли для чтения. Это является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/cel/roles/my-role
Пример ответа:
{
  "request_id": "a888afe3-1bd4-01cb-8dd4-4ea4118e14e1",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "name": "testrole",
    "cel_program": {
      "variables": [
        {
          "name": "validate_cn",
          "expression": "has(request.common_name) && request.common_name == \"example.com\""
        },
        {
          "name": "small_ttl",
          "expression": "has(request.ttl) && duration(request.ttl) == duration(\"4h\")"
        },
        {
          "name": "cn_value",
          "expression": "request.common_name"
        },
        {
          "name": "not_after",
          "expression": "now + duration(request.ttl)"
        },
        {
          "name": "cert",
          "expression": "CertTemplate{
            Subject: PKIX.Name{
              CommonName: cn_value,
              Country: [\"ZW\", \"US\"]
            },
            NotBefore: now,
            NotAfter: not_after,
            IsCA: true,
            MaxPathLen: 10,
            PolicyIdentifiers: [
              ObjectIdentifier{ arc: [1u, 2u, 3u] },
              ObjectIdentifier{ arc: [2u, 59u, 1u] }
            ],
            IPAddresses: [
              net.IP{ IP: b\"\\x0A\\x00\\x00\\x00\" }
            ]
          }"
        },
        {
          "name": "output",
          "expression": "ValidationOutput{
            template: cert,
            generate_lease: small_ttl,
            no_store: !small_ttl,
            issuer_ref: \"default\",
            key_type: request.key_type,
            key_bits: uint(request.key_bits)
          }"
        },
        {
          "name": "err",
          "expression": "'Request should have Common name.'"
        }
      ],
      "expression": "validate_cn ? output : err"
    },
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

4.10. Генерация сертификата и ключа для роли CEL

Эта конечная точка генерирует новый набор учетных данных (закрытый ключ и сертификат) на основе роли, указанной в конечной точке. Сертификат CA и полная цепочка CA также возвращаются, так что только корневой CA должен быть в хранилище доверенных сертификатов клиента.

Закрытый ключ не хранится. Если вы не сохраните закрытый ключ из ответа, вам потребуется запросить новый сертификат.
Метод Путь Издатель

POST

/pki/cel/issue/:name

Выбранная роль

4.10.1. Параметры

  • name (string: <обязательный>) - указывает имя роли, против которой будет создан сертификат. Это является частью URL запроса.

  • Любое произвольное поле может быть предоставлено и будет использоваться, если будет признано в программе CEL.

Каждый ключ/значение в теле запроса передается объекту request в CEL. Программа CEL может решить, какие из этих параметров учитывать, игнорировать или переопределять.
Пример тела запроса:
{
  "common_name": "www.example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/cel/issue/my-role
Пример ответа:
{
  "request_id": "59292f4d-2618-40d2-99e6-35e53e44b623",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDezCCAmOlw99Cv6mdGrGpPllgRCCq7jx=...\n-----END CERTIFICATE-----",
    "expiration": 1749631491,
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDPjCCAiagAwIBAgIUVY5A99Cv6mdGrGpPl...\n-----END CERTIFICATE-----",
    "not_before": 1749627891,
    "private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEA3WZYHWCBkRixlPmO...\n-----END RSA PRIVATE KEY-----",
    "private_key_type": "rsa",
    "serial_number": "3d:2e:18:86:b8:15:29:2f:e9:24:c2:e6:ac:7f:5a:74:ba:88:a6:bc"
  },
  "wrap_info": null,
  "warnings": [],
  "auth": null
}

4.11. Подписать сертификат для роли CEL

Эта конечная точка подписывает новый сертификат на основе предоставленного CSR и указанных параметров, с учетом ограничений, содержащихся в роли, указанной в конечной точке. Сертификат CA и полная цепочка CA также возвращаются, так что только корневой CA должен быть в хранилище доверенных сертификатов клиента.

Метод Путь Издатель

POST

/pki/cel/sign/:name

Выбранная роль

4.11.1. Параметры

  • name (string: <обязательный>) - указывает имя роли, против которой будет создан сертификат. Это является частью URL запроса.

  • csr (string: <обязательный>) - указывает PEM-кодированный CSR.

  • Любое произвольное поле может быть предоставлено и будет использоваться, если будет признано в программе CEL.

Каждый ключ/значение в теле запроса передается объекту request в CEL. Программа CEL может решить, какие из этих параметров учитывать, игнорировать или переопределять.
Пример тела запроса:
{
  "csr": "...",
  "common_name": "example.com"
}
Пример ответа:
{
  "lease_id": "pki/sign/test/7ad6cfa5-f04f-c62a-d477-f33210475d05",
  "renewable": false,
  "lease_duration": 21600,
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n",
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIJAKM+z4MSfw2mMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\n...\nG/7g4koczXLoUM3OQXd5Aq2cs4SS1vODrYmgbioFsQ3eDHd1fg==\n-----END CERTIFICATE-----\n"
    ],
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58"
  },
  "auth": null
}

4.12. Отзыв сертификата

Эта конечная точка отзывает сертификат, используя его серийный номер. Это альтернативный вариант стандартного метода отзыва, используя идентификаторы аренды StarVault. Успешный отзыв приведет к ротации CRL.

Данная операция является привилегированной, так как позволяет отзывать произвольные сертификаты исключительно на основе их серийного номера. Она не проверяет, выдал ли запрашивающий пользователь сертификат или обладает ли он закрытым ключом.

Эта конечная точка не может отзывать издателей.
Метод Путь

POST

/pki/revoke

4.12.1. Параметры

Либо serial_number, либо certificate (но не оба) должны быть указаны в запросах к этой конечной точке.

  • serial_number (string: <необязательный>) - указывает серийный номер сертификата для отзыва в шестнадцатеричном формате с разделением на дефисы или двоеточия.

  • certificate (string: <необязательный>) - указывает сертификат для отзыва в формате PEM. Этот сертификат должен быть подписан одним из издателей в этом монтировании, чтобы его можно было принять для отзыва.

Пример тела запроса:
{
  "serial_number": "39:dd:2e..."
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/revoke
Пример ответа:
{
  "data": {
    "revocation_time": 1433269787
  }
}

4.13. Отозвать сертификат с закрытым ключом

Эта конечная точка отзывает сертификат, используя его закрытый ключ в качестве доказательства того, что запрос авторизован соответствующим лицом (доказательство владения).

Это альтернативный вариант стандартного метода отзыва, используя идентификаторы аренды StarVault или отзыв по серийному номеру. Успешный отзыв приведет к ротации CRL.

Отзыва́ть издателей с помощью этого пути нельзя.

Данная операция НЕ является привилегированной, поскольку она проверяет, что отзыв имеет закрытый ключ, соответствующий сертификату, подписанному StarVault. Тем не менее, с целью предотвращения отказа в обслуживании (DOS) со стороны третьих лиц по отношению к StarVault, мы сделали эту конечную точку аутентифицированной. Поэтому настоятельно рекомендуется всегда разрешать доступ к этому пути через ACL.
Метод Путь

POST

/pki/revoke-with-key

4.13.1. Параметры

Либо serial_number, либо certificate (но не оба) должны быть указаны в запросах к этой конечной точке.

  • serial_number (string: <необязательно>) - указывает серийный номер сертификата для отзыва, в шестнадцатеричном формате с разделением на дефисы или двоеточия.

  • certificate (string: <необязательно>) - указывает сертификат для отзыва, в формате PEM. Этот сертификат должен быть подписан одним из издателей в данном монтировании, чтобы его можно было принять для отзыва.

  • private_key (string: <обязательный>) - указывает закрытый ключ (в формате PEM), соответствующий сертификату, выданному StarVault, который требуется отозвать. Эта конечная точка должна вызываться несколько раз (с каждым уникальным сертификатом/серийным номером), если этот закрытый ключ используется в нескольких сертификатах, поскольку StarVault не поддерживает такое соответствие.

Пример тела запроса:
{
  "serial_number": "39:dd:2e...",
  "private_key": "-----BEGIN PRIVATE KEY-----\n..."
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/revoke-with-key
Пример ответа:
{
  "data": {
    "revocation_time": 1433269787
  }
}

4.14. Список отозванных сертификатов

Эта конечная точка возвращает список серийных номеров, которые были отозваны в локальном кластере.

Метод Путь

LIST

/certs/revoked

4.14.1. Параметры

  • after (string: "") - необязательная запись, с которой начать перечисление для постраничной навигации; не требуется существовать.

  • limit (int: 0) - необязательное количество записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/certs/revoked
Пример ответа:
{
  "data": {
    "keys": [
      "3d:80:91:c3:c2:34:3b:81:69:3d:92:a3:80:69:db:53:04:26:ab:b4"
    ]
  }
}

4.15. Список запросов на отзыв

Эта конечная точка возвращает список серийных номеров, которые были запрошены на отзыв в любом кластере, а также информацию о состоянии запроса и о том, на каком кластере он был инициирован.

Метод Путь

LIST

/certs/revocation-queue
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/certs/revocation-queue
Пример ответа:
{
  "data": {
    "key_info": {
      "3d:80:91:c3:c2:34:3b:81:69:3d:92:a3:80:69:db:53:04:26:ab:b4": {
        "requesting_cluster": "48327b28-8325-6d79-6a0b-4cbaa6f27b4a"
      }
    },
    "keys": [
      "3d:80:91:c3:c2:34:3b:81:69:3d:92:a3:80:69:db:53:04:26:ab:b4"
    ]
  }
}

5. Получение информации о владельце

Все потребители монтирования движка секретов PKI получат доступ к следующим неаутентифицированным API, полезным для чтения информации о центре сертификации в этом монтировании.

Это включает информацию о сертификатах CA, их цепочках и их подписанных CRL, содержащих закодированный список отозванных сертификатов, ранее выданных этим центром. Индивидуально выданные сертификаты тоже можно прочитать, при условии, что известен их серийный номер. Наконец, список выдающих сертификатов является публичной информацией в этом монтировании.

5.1. Список издателей

Эта конечная точка возвращает список издателей, в настоящее время предусмотренных в этом монтировании. Ответ включает как идентификатор издателя, так и имя, выбранное операторами; любое из них может быть использовано для обращения к издателю позже. Эта конечная точка не требует аутентификации.

Метод Путь

LIST

/pki/issuers

5.1.1. Параметры

  • after (string: "") - необязательная запись для начала перечисления после для постраничной навигации; не требуется существовать;

  • limit (int: 0) - необязательное число записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/issuers
Пример ответа:
{
  "data": {
    "key_info": {
      "1ae8ce9d-2f70-0761-a465-8c9840a247a2": {
        "issuer_name": "imported-root"
      },
      "3dc79a5a-7a6c-70e2-1123-94b88557ba12": {
        "issuer_name": "root-x1"
      }
    },
    "keys": [
      "1ae8ce9d-2f70-0761-a465-8c9840a247a2",
      "3dc79a5a-7a6c-70e2-1123-94b88557ba12"
    ]
  }
}

5.2. Чтение сертификата издателя

Эта конечная точка извлекает сертификат указанного издателя.

Обратите внимание, что ответ отличается между старым путем /pki/cert/ca и новым путем /pki/issuer/:issuer_ref/json; последняя включает полную цепочку ca_chain издателя, что устраняет необходимость в отдельной конечной точке.

Эти конечные точки не требуют аутентификации.

Данная конечная точка принимает заголовок If-Modified-Since, чтобы ответить кодом 304 Not Modified, если запрашиваемый ресурс не изменился. Этот заголовок должен быть разрешен на монтировании PKI путем настройки параметра passthrough_request_headers. Чтобы клиенты знали время последнего изменения, заголовок ответа Last-Modified должен быть добавлен к настраиваемому параметру allowed_response_headers монтирования.
Метод Путь Издатель Формат

GET

/pki/cert/ca

default

JSON

GET

/pki/ca

default

DER [1]

GET

/pki/ca/pem

default

PEM [1]

GET

/pki/issuer/:issuer_ref/json

Selected

JSON

GET

/pki/issuer/:issuer_ref/der

Selected

DER [1]

GET

/pki/issuer/:issuer_ref/pem

Selected

PEM [1]

5.2.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Данный параметр отсутствует в путях /pki/cert/ca и /pki/ca(/pem)? и получает явное значение default.
Пример запроса:
$ curl \
    http://127.0.0.1:8200/v1/pki/issuer/root-x1/json
Пример ответа:
{
  "data": {
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
      "-----BEGIN CERTIFICATE-----\nMIIDFTCCAf2gAwIBAgIUUo/qwLm5AyqUWqFHw1MlgwUtS/kwDQYJKoZIhvcNAQEL\n..."
    ],
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL...",
    "revocation_time": 0
  }
}

5.3. Чтение цепочки сертификатов по умолчанию

Эта конечная точка извлекает цепочку сертификатов CA по умолчанию, включая стандартный издатель.

Чтобы прочитать цепочки других издателей, используйте конечную точку /pki/issuer/:issuer_ref/json.

Эти конечные точки не требуют аутентификации.

Метод Путь Издатель Формат

GET

/pki/ca_chain

default

PEM [1]

GET

/pki/cert/ca_chain

default

JSON

Данные конечные точки возвращают полную цепочку (включая сертификат этого удостоверяющего центра и всех родительских издателей, известных StarVault) в ответах этих конечных точек.
Пример запроса:
$ curl \
    http://127.0.0.1:8200/v1/pki/ca_chain
Пример ответа:
<PEM-кодированная цепочка сертификатов>

5.4. Чтение CRL издателя

Эта конечная точка извлекает CRL указанного издателя.

Обратите внимание, что ответ отличается между старым путем /pki/cert/crl и новым путем /pki/issuer/:issuer_ref/crl; последний корректно размещает PEM-кодированную CRL в поле crl, в то время как первый неправильно размещает его в поле certificate.

Эти конечные точки не требуют аутентификации.

Метод Путь Издатель Формат Тип Источник

GET

/pki/cert/crl

default

JSON

Полный

Локальный

GET

/pki/crl

default

DER [1]

Полный

Локальный

GET

/pki/crl/pem

default

PEM [1]

Полный

Локальный

GET

/pki/cert/delta-crl

default

JSON

Дельта

Локальный

GET

/pki/crl/delta

default

DER [1]

Дельта

Локальный

GET

/pki/crl/delta/pem

default

PEM [1]

Дельта

Локальный

GET

/pki/issuer/:issuer_ref/crl

Selected

JSON

Полный

Локальный

GET

/pki/issuer/:issuer_ref/crl/der

Selected

DER [1]

Полный

Локальный

GET

/pki/issuer/:issuer_ref/crl/pem

Selected

PEM [1]

Полный

Локальный

GET

/pki/issuer/:issuer_ref/crl/delta

Selected

JSON

Дельта

Локальный

GET

/pki/issuer/:issuer_ref/crl/delta/der

Selected

DER [1]

Дельта

Локальный

GET

/pki/issuer/:issuer_ref/crl/delta/pem

Selected

PEM [1]

Дельта

Локальный

5.4.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Данный параметр отсутствует в путях /pki/cert/crl и /pki/crl(/pem)? и получает явное значение default.
Пример запроса:
$ curl \
    http://127.0.0.1:8200/v1/pki/issuer/root-x1/crl
Пример ответа:
{
  "data": {
    "crl": "-----BEGIN X509 CRL-----\nMIIBizB1AgEBMA0GCSqGSIb3DQEBCwUAMBIxEDAOBgNVBAMTB3Jvb3QgeDEXDTIy\n..."
  }
}

5.5. Запрос OCSP

Эта конечная точка извлекает ответ OCSP (статус отзыва) для данного серийного номера. Форматы запросов/ответов основываются на RFC 6960. Конечные точки с источником local включают только локальные отзыва сертификатов.

На данный момент существуют определенные ограничения реализации OCSP по этому пути:

  • В ответе отразится только один серийный номер из запроса;

  • Ни одно из расширений, определенных в RFC, не поддерживается для запросов или ответов;

  • Эмитенты, поддерживаемые Ed25519, не поддерживаются для OCSP-запросов;

  • Обратите внимание, что этот API не будет работать с клиентом StarVault, так как оба запроса и ответы закодированы в DER;

  • Обратите внимание, что эмитенты, основанные на KMS, которые требуют поддержки PSS, также не поддерживаются (такие как PKCS#11 HSM или GCP в определенных сценариях).

Эти конечные точки не требуют аутентификации.

Метод Путь Формат ответа Источник

GET

/pki/ocsp/<base 64+URL encoded ocsp DER request>

DER [1]

Локальный

POST

/pki/ocsp

DER [1]

Локальный

5.5.1. Параметры

  • Нет

Пример запроса:
openssl ocsp -no_nonce -issuer issuer.pem -CAfile ca_chain.pem -cert cert-to-revoke.pem -text -url $STARVAULT_ADDR/v1/pki/ocsp

5.6. Список сертификатов

Эта конечная точка возвращает список текущих сертификатов только по серийному номеру. Более подробная информация, такая как common_name, issuer, key_type, key_bits, not_after, not_before и до 5 dns_names, находится по адресу /pki/certs/detailed.

Ответ не включает специальные серийные номера (ca, ca_chain и crl), которые могут быть использованы с /pki/cert/:serial.

Эта конечная точка включает только сертификаты, выданные этой монтировкой с no_store=false. Хотя генерация корневого сертификата создает записи здесь, импорт сертификатов (включая как корни, так и промежуточные) не приведет к появлению серийного номера импортированного сертификата в этом списке.

Конечная точка для списка всех сертификатов является аутентифицированной. Это сделано для того, чтобы предотвратить автоматизированное перечисление выданных сертификатов для внутренних сервисов; однако эта информация должна считаться не чувствительной, и сами сертификаты открыты без аутентификации (при условии, что известен их серийный номер).

Многие публичные центры сертификации участвуют в инициативе Прозрачности сертификатов, где все выданные сертификаты публично раскрываются в интересах третьей стороны для проверки целостности CA.
Метод Путь

LIST

/pki/certs

LIST

/pki/certs/detailed?detailed=true

5.6.1. Параметры

  • after (string: "") - необязательная запись для начала перечисления после для постраничной навигации; не требуется существовать.

  • limit (int: 0) - необязательное число записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/certs
Пример ответа:
{
  "data": {
    "keys": [
      "17:67:16:b0:b9:45:58:c0:3a:29:e3:cb:d6:98:33:7a:a6:3b:66:c1",
      "26:0f:76:93:73:cb:3f:a0:7a:ff:97:85:42:48:3a:aa:e5:96:03:21"
    ]
  }
}

5.7. Чтение сертификата

Эта конечная точка извлекает сертификат, указанный по его серийному номеру, включая выданные сертификаты.

Эти конечные точки не требуют аутентификации.

Метод Путь Формат

GET

/pki/cert/:serial

JSON

GET

/pki/cert/:serial/raw

DER [1]

GET

/pki/cert/:serial/raw/pem

PEM [1]

5.7.1. Параметры

  • serial (string: <обязательный>) - указывает серийный номер ключа для чтения. Это является частью URL запроса. Допустимые значения для serial:

  • <serial> для сертификата с указанным серийным номером, в формате шестнадцатеричного кода с разделением на дефисы или двоеточия;

  • ca для сертификата CA по умолчанию;

  • crl для CRL по умолчанию;

  • ca_chain для цепочки доверительных отношений CA по умолчанию.

Данные конечные точки возвращают полную цепочку (включая этот сертификат и всех родительских издателей, известных StarVault) в ответах ca_chain, для полей certificate и ca_chain.
Пример запроса:
$ curl \
    http://127.0.0.1:8200/v1/pki/cert/67:b4:f7:2c:aa:ef:b9:30:f6:ae:f5:12:21:79:ac:08:8a:86:89:72
Пример ответа:
{
  "data": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIGmDCCBYCgAwIBAgIHBzEB3fTzhTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UE\n...",
    "revocation_time": 1667400107,
    "revocation_time_rfc3339": "2025-07-29T14:41:47.327515Z",
    "issuer_id": "e27bf456-51e1-d937-0001-4a609184fd9b"
  }
}

6. Управление ключами и издателями

Следующие конечные точки являются высокопривилегированными и позволяют операторам генерировать или импортировать новые сертификаты и ключи издателей, удалять существующие ключи и издателей, или читать внутреннюю информацию о ключах и издателях.

6.1. Список издателей

Смотрите предыдущий раздел для получения дополнительной информации о перечислении издателей.

6.2. Список ключей

Эта конечная точка возвращает список ключей, которые в настоящее время предусмотрены в этом монтировании. Ответ включает как идентификатор ключа, так и имя, выбранное операторами; любое из них может быть использовано для обращения к ключу позже.

Эта конечная точка требует аутентификации.

Метод Путь

LIST

/pki/keys

6.2.1. Параметры

  • after (string: "") - необязательная запись для начала перечисления после для постраничной навигации;

  • limit (int: 0) - необязательное количество записей для возврата; по умолчанию возвращаются все записи.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request LIST \
    http://127.0.0.1:8200/v1/pki/keys
Пример ответа:
{
  "data": {
    "key_info": {
      "f9244f54-adc7-4a5c-6b08-6ca3a3325620": {
        "key_name": "imported-root-key"
      }
    },
    "keys": [
      "f9244f54-adc7-4a5c-6b08-6ca3a3325620"
    ]
  }
}

6.3. Генерация ключа

Эта конечная точка генерирует новый закрытый ключ для использования в монтировании PKI. Этот ключ можно использовать как с помощью корневой, так и промежуточной конечных точек, используя вариант type=existing.

Если путь заканчивается на exported, закрытый ключ будет возвращен в ответе; если это internal, закрытый ключ не будет возвращен и не может быть получен позже.

Метод Путь

POST

/pki/keys/generate/:type

6.3.1. Параметры

  • type (string: <обязательный>) - указывает тип ключа для создания. Если exported, закрытый ключ будет возвращен в ответе; если internal, закрытый ключ не будет возвращен и не может быть получен позже.

  • key_name (string: "") - когда с помощью этого запроса создается новый ключ, опционально указывает имя для этого ключа. Глобальная ссылка default не может использоваться как имя.

  • key_type (string: "rsa") - указывает желаемый тип ключа; должен быть rsa, ed25519 или ec.

    В режиме FIPS 140-2 следующие алгоритмы не сертифицированы и поэтому не должны использоваться: ed25519.

  • key_bits (int: 0) - указывает количество бит для использования для сгенерированных ключей. Допустимые значения: 0 (универсальное значение по умолчанию); с key_type=rsa, допустимые значения: 2048 (по умолчанию), 3072 или 4096; с key_type=ec, допустимые значения: 224, 256 (по умолчанию), 384 или 521; игнорируется с key_type=ed25519.

Пример тела запроса:
{
  "key_type": "ec",
  "key_bits": "256",
  "key_name": "root-key-2025"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/keys/generate/internal
Пример ответа:
{
  "request_id": "8ad22b2f-7d14-f2cd-a10a-d1abc33676ab",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "key_id": "adda2443-a8aa-d181-9d07-07c7be6a76ab",
    "key_name": "root-key-2025",
    "key_type": "ec"
  },
  "warnings": null
}

6.4. Генерация корневого сертификата

Эта конечная точка генерирует новый самоподписанный сертификат CA и закрытый ключ.

  • Если путь заканчивается на exported, закрытый ключ будет возвращен в ответе;

  • Если это internal, закрытый ключ не будет возвращен и не может быть получен позже;

  • Если это existing, для этого корня будет повторно использован ключ, указанный в key_ref.

Этот сгенерированный корень подпишет свой собственный CRL. Пункты распространения доступа к авторитету используют значения, заданные через config/urls.

Движок секретов PKI поддерживает несколько издателей под одним монтированием. Используйте операции управления в этом разделе для перечисления и изменения издателей в пределах этого монтирования. Никакие издатели не будут переопределены при вызове этой операции. Удаление отдельных ключей и издателей должно быть предпочтительным вариантом к вызову DELETE /pki/root, который удаляет все.
Метод Путь

POST

/pki/root/generate/:type

POST

/pki/issuers/generate/root/:type

POST

/pki/root/rotate/:type

6.4.1. Параметры

  • type (string: <обязательный>) - указывает тип корня для создания. Если exported, закрытый ключ будет возвращен в ответе; если internal, закрытый ключ не будет возвращен и не может быть получен позже; если existing, используем значение параметра key_ref, чтобы найти существующий материал ключа для создания CSR. Этот параметр является частью URL запроса.

  • issuer_name (string: "") - указывает имя для указанного удостоверяющего центра. Имя должно быть уникальным для всех издателей и не может быть зарезервированным значением default. Когда значение не предоставлено и путь /pki/root/rotate/:type, используется значение по умолчанию "next".

  • key_name (string: "") - когда с помощью этого запроса создается новый ключ, опционально указывает имя для этого ключа. Глобальная ссылка default не может использоваться как имя.

  • key_ref (string: "default") - указывает ключ (либо default, по имени, либо по идентификатору), который будет использоваться для создания этого запроса. Подходит только для запросов типа existing.

  • common_name (string: <обязательный>) - указывает запрашиваемый CN для сертификата. Если требуется более одного common_name, укажите альтернативные имена в списке alt_names.

  • alt_names (string: "") - указывает запрашиваемые альтернативные имена субъектов, в виде списка, разделенного запятыми. Это могут быть имена хостов или адреса электронной почты; они будут разобраны в их соответствующие поля.

  • ip_sans (string: "") - указывает запрашиваемые IP альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • uri_sans (string: "") - указывает запрашиваемые URI альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • other_sans (string: "") - указывает пользовательские OID/UTF8-строковые SANs. Эти должны совпадать со значениями, указанными в роли в allowed_other_sans (см. создание роли для правил глоббинга allowed_other_sans). Формат аналогичен OpenSSL: <oid>;<type>:<value>, где единственный текущий допустимый тип - UTF8. Это может быть список, разделенный запятыми, или часть строки JSON.

  • ttl (string: "") - указывает запрашиваемое время жизни (после которого сертификат будет просрочен). Это не может превышать максимальное значение движка (или, если оно не установлено, системный максимум). См. not_after в качестве альтернативы для установки абсолютной даты завершения (вместо относительной).

  • format (string: "pem") - указывает формат для возвращаемых данных. Может быть pem, der или pem_bundle. Если der, вывод будет закодирован в base64. Если pem_bundle, поле certificate будет содержать закрытый ключ (если он экспортированный) и сертификат, объединенные; если выпускной сертификат CA не является корневым самоподписанным сертификатом StarVault, это также будет включено.

  • private_key_format (string: "der") - указывает формат для сериализации закрытого ключа в поле ответа private_key. Значение по умолчанию - der, что вернет либо base64-кодированный DER, либо PEM-кодированный DER в зависимости от значения format. Другой вариант - pkcs8, который вернет ключ, сериализованный как PEM-кодированный PKCS8.

    Это не относится к закрытому ключу внутри поля сертификата, если указан параметр format=pem_bundle.

  • key_type (string: "rsa") - Указывает желаемый тип ключа; должен быть rsa, ed25519 или ec.

В режиме FIPS 140-2 следующие алгоритмы не сертифицированы и поэтому не должны использоваться: ed25519.

  • key_bits (int: 0) - указывает количество бит для использования для сгенерированных ключей. Допустимые значения: 0 (универсальное значение по умолчанию); при key_type=rsa, допустимые значения: 2048 (по умолчанию), 3072 или 4096; при key_type=ec, допустимые значения: 224, 256 (по умолчанию), 384 или 521; игнорируются при key_type=ed25519.

  • max_path_length (int: -1) - указывает максимальную длину пути, которую нужно закодировать в сгенерированном сертификате. -1 означает отсутствие ограничений, если у подписанного сертификата нет установленной максимальной длины пути; в этом случае длина пути устанавливается на одно меньшее значение, чем у подписанного сертификата. Ограничение 0 означает буквальную длину пути ноль.

  • exclude_cn_from_sans (bool: false) - если установлено в true, указанный common_name не будет включен в альтернативные имена субъектов DNS или электронной почты (в зависимости от случаев). Полезно, если CN не является именем хоста или адресом электронной почты, а вместо этого представляет собой некоторый идентификатор, удобный для чтения.

  • permitted_dns_domains (string: "") - строка, разделенная запятыми (или строковый массив), содержащая DNS-домены, для которых сертификаты могут быть выданы или подписаны этим сертификатом CA. Обратите внимание, что поддомены разрешены, в соответствии с RFC 5280 Раздел 4.2.1.10 - Ограничения имен.

  • ou (string: "") - указывает значения OU (OrganizationalUnit) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • organization (string: "") - указывает значения O (Organization) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • country (string: "") - указывает значения C (Country) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • locality (string: "") - указывает значения L (Locality) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • province (string: "") - указывает значения ST (Province) в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • street_address (string: "") - указывает значения адреса улицы в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • postal_code (string: "") - указывает значения почтового кода в поле субъекта результирующего сертификата. Это строка, разделенная запятыми, или JSON-массив.

  • serial_number (string: "") - указывает запрашиваемые значения субъекта Серийный номер значение, если имеется. Если вы хотите больше одного, укажите альтернативные имена в карте alt_names, используя OID 2.5.4.5. Обратите внимание, что это не влияет на поле серийного номера сертификата, которое StarVault случайным образом генерирует.

  • not_before_duration (duration: "30s") - указывает продолжительность, на которую необходимо вернуть поле NotBefore. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl. Использует формат строк продолжительности.

  • not_before (string) - укажите поле "Not Before" сертификата с указанным значением даты. Формат значения должен быть в UTC формате YYYY-MM-ddTHH:MM:SSZ. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl.

  • not_after (string) - установите поле "Not After" сертификата с указанным значением даты. Формат значения должен быть в UTC формате YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z.

  • key_usage (list: ["KeyAgreement", "KeyEncipherment"]) - указывает стандартное ограничение на использование ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#KeyUsage - просто опустите часть KeyUsage из значения. Значения не чувствительны к регистру.

  • ext_key_usage (list: []) - указывает стандартное ограничение на использование расширенного ключа на выданный сертификат. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#ExtKeyUsage - просто опустите часть ExtKeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие стандартных ограничений на использование ключа, установите это в пустой список.

  • ext_key_usage_oids (string: "") - Строка, разделенная запятыми, или список OID расширенного использования ключа.

    Это значение используется только как стандартное, когда расширение ExtendedKeyUsage отсутствует в CSR.

    Ключи типа rsa в настоящее время поддерживают только подписи PKCS#1 v1.5.
Пример тела запроса:
{
  "common_name": "example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/root/generate/internal
Пример ответа:
{
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "expiration": "1654105687",
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "issuing_ca": "-----BEGIN CERTIFICATE-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE-----\n",
    "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58",
    "issuer_id": "7b493f17-6c08-ff73-cf1a-99bfcc448a73",
    "issuer_name": "",
    "key_id": "22b82e37-529d-7251-7d78-3862bfd069ac",
    "key_name": ""
  },
  "auth": null
}

6.5. Генерация промежуточного CSR

Эта конечная точка возвращает новый CSR для подписания, возможно, генерируя новый закрытый ключ. Если StarVault используется как корень (как и многие другие CA), различные параметры в конечном подписанном сертификате устанавливаются в момент подписания и могут или не могут учитывать параметры, установленные здесь (и переданные в возвращаемом CSR).

Ниже перечисленные параметры в основном являются вспомогательной функцией; не все возможные параметры, которые могут быть установлены в CSR, поддерживаются в этом запросе.

На данный момент ни один новый удостоверяющий центр не создается с помощью этого вызова; заметьте, что новый ключ может быть сгенерирован в зависимости от параметра запроса type.

Для окончания генерации промежуточного сертификата CSR должен быть подписан, и полученный сертификат должен быть импортирован. Это может включать работу с внешними системами (такими как внешний или оффлайн корневой CA), чтобы передать CSR и завершить подписывание до того, как подписанный промежуточный сертификат будет импортирован в это монтирование.
Метод Путь Источник закрытого ключа (type)

POST

/pki/intermediate/generate/:type

указан в запросе

POST

/pki/issuers/generate/intermediate/:type

указан в запросе

POST

/pki/intermediate/cross-sign

existing

6.5.1. Параметры

  • type (string: <обязательный>) - указывает тип промежуточного сертификата для создания. Если exported, закрытый ключ будет возвращен в ответе; если internal, закрытый ключ не будет возвращен и не может быть получен позже; если existing, мы ожидаем параметра key_ref для использования существующих ключей для создания CSR. Этот параметр является частью URL запроса.

  • common_name (string: <обязательный>) - указывает запрашиваемый CN для сертификата. Если требуется более одного common_name, укажите альтернативные имена в списке alt_names.

  • alt_names (string: "") - указывает запрашиваемые альтернативные имена субъектов, в виде списка, разделенного запятыми. Это могут быть имена хостов или адреса электронной почты; они будут разобраны в их соответствующие поля.

  • ip_sans (string: "") - указывает запрашиваемые IP альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • uri_sans (string: "") - указывает запрашиваемые URI альтернативные имена субъектов, в виде списка, разделенного запятыми.

  • other_sans (string: "") - указывает пользовательские OID/UTF8-строковые SANs. Эти должны соответствовать значениям, указанным в роли в allowed_other_sans (см. создание роли для правил глоббинга allowed_other_sans). Формат аналогичен OpenSSL: <oid>;<type>:<value>, где единственный текущий допустимый тип - UTF8. Это может быть список, разделенный запятыми, или часть строки JSON.

  • format (string: "pem") - указывает формат для возвращаемых данных. Это может быть pem, der или pem_bundle; по умолчанию - pem. Если der, вывод будет закодирован в base64. Если pem_bundle, поле csr будет содержать закрытый ключ (если экспортированный) и CSR, объединенные.

  • private_key_format (string: "der") - указывает формат для сериализации закрытого ключа в поле запроса private_key. Значение по умолчанию - der, что вернет либо base64-кодированный DER, либо PEM-кодированный DER в зависимости от значения format. Другой вариант - pkcs8, который вернет ключ, сериализованный как PEM-кодированный PKCS8.

    Это не относится к закрытому ключу внутри поля сертификата, если указан параметр format=pem_bundle.

  • key_type (string: "rsa") - указывает желаемый тип ключа; должен быть rsa, ed25519 или ec. Не подходит для запросов типа existing.

    В режиме FIPS 140-2 следующие алгоритмы не сертифицированы и поэтому не должны использоваться: ed25519.

    Ключи типа rsa в настоящее время поддерживают только подписи PKCS#1 v1.5.

  • key_bits (int: 0) - указывает количество бит, которые следует использовать для сгенерированных ключей. Допустимые значения: 0 (универсальное значение по умолчанию); с key_type=rsa, допустимые значения: 2048 (по умолчанию), 3072 или 4096; с key_type=ec, допустимые значения: 224, 256 (по умолчанию), 384 или 521; игнорируются с key_type=ed25519. Не подходит для запросов типа existing.

  • key_name (string: "") - когда с помощью этого запроса создается новый ключ, опционально указывает имя для этого ключа. Глобальная ссылка default не может использоваться как имя.

  • key_ref (string: "default") - указывает ключ (либо default, по имени, либо по идентификатору), который будет использоваться для создания этого запроса. Подходит только для запросов типа existing.

  • signature_bits (int: 0) - указывает количество бит для использования в алгоритме подписи; принимает 256 для SHA-2-256, 384 для SHA-2-384, и 512 для SHA-2-512. По умолчанию 0 для автоматического определения на основе длины ключа издателя (SHA-2-256 для RSA-ключей и соответствующего размера кривой для NIST P-Кривых).

    Издатели ECDSA и Ed25519 не следуют конфигурации значения signature_bits; только издатели RSA будут изменять типы подписей в зависимости от этого параметра.

  • exclude_cn_from_sans (bool: false) - если установлено в true, указанный common_name не будет включен в альтернативные имена субъектов DNS или электронной почты (в зависимости от случаев). Полезно, если CN не является именем хоста или адресом электронной почты, а вместо этого является некоторым идентификатором, удобным для чтения.

  • ou (string: "") - указывает значения OU (OrganizationalUnit) в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • organization (string: "") - указывает значения O (Organization) в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • country (string: "") - указывает значения C (Country) в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • locality (string: "") - указывает значения L (Locality) в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • province (string: "") - указывает значения ST (Province) в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • street_address (string: "") - указывает значения улицы в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • postal_code (string: "") - указывает значения почтового кода в поле субъекта результирующего CSR. Это строка, разделенная запятыми, или JSON-массив.

  • serial_number (string: "") - указывает запрашиваемые значения субъекта Серийный номер значение, если имеется. Если вы хотите больше одного, укажите альтернативные имена в карте alt_names, используя OID 2.5.4.5. Обратите внимание, что это не влияет на поле серийного номера сертификата, которое StarVault случайным образом генерирует.

  • add_basic_constraints (bool: false) - указывает, добавлять ли расширение основных ограничений с CA: true. Необходимо только как обходной путь в некоторых сценариях совместимости с службой сертификатов Active Directory.

Пример тела запроса:
{
  "common_name": "www.example.com"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/intermediate/generate/exported
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIDzDCCAragAwIBAgIUOd0ukLcjH43TfTHFG9qE0FtlMVgwCwYJKoZIhvcNAQEL\n...\numkqeYeO30g1uYvDuWLXVA==\n-----END CERTIFICATE REQUEST-----\n",
    "private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAKCAQEAwsANtGz9gS3o5SwTSlOG1l-----END RSA PRIVATE KEY-----",
    "private_key_type": "rsa"
  },
  "warnings": null,
  "auth": null
}

6.6. Импорт сертификатов CA и ключей

Эта конечная точка позволяет подать (импортировать) информацию CA для бэкенда через PEM файл, содержащий сертификат CA и любые закрытые ключи, конкатенированные вместе в любом порядке.

Каждый сертификат будет проверяться, чтобы удостовериться, что это действующий CA (имеет установленный основной ограничитель isCA); некорректные CA сертификаты выдадут ошибку. Любые предоставленные CRL будут игнорироваться. Каждый уникальный сертификат и закрытый ключ будут импортированы как свой собственный вход для издателя или ключа; дубликаты (включая существующие ключи) будут игнорироваться.

Ответ будет указывать, какие издатели и ключи были созданы в рамках этого запроса (в полях imported_issuers и imported_keys), а также поле mapping, указывающее, какие ключи принадлежат каким издателям (включая уже импортированные записи, присутствующие в том же пакете). Ответ также содержит поля existing_issuers и existing_keys, которые указывают на идентификаторы издателей и ключей любых записей, которые уже существуют в этом монтировании.

Метод Путь Разрешает закрытые ключи Параметр запроса

POST

/pki/config/ca

да

pem_bundle

POST

/pki/issuers/import/bundle

да

pem_bundle

POST

/pki/issuers/import/cert

нет

pem_bundle

POST

/pki/intermediate/set-signed

нет

certificate

Конечные точки, которые разрешают импортировать закрытые ключи, должны считаться высоко привилегированными и соответствующим образом ограниченными. Конечные точки, которые позволяют импортировать издателей, также должны быть ограничены, но обратите внимание, что издатели без ключей не могут выдавать сертификаты или CRL.

StarVault будет устранять дубликаты ключей и издателей, закодированных в различных форматах. Это означает, что возвращенный сертификат может отличаться по кодировке от того, который был предложен при последующих повторных импортированиях одного и того же издателя или ключа.

Этот импорт может не удаться из-за проблем с перестройкой CRL или других потенциальных проблем; это может повлиять на долгосрочное использование этих издателей, но некоторые издатели или ключи все равно могут быть импортированы в результате этого процесса.

6.6.1. Параметры

  • pem_bundle (string: <обязательный>) - eказывает незашифрованный закрытый ключ и сертификат, конкатенированные в формате PEM.

    Этот параметр присутствует на путях /pki/config/ca и /pki/issuers/import/*; он отсутствует на пути /pki/intermediate/set-signed.

  • certificate (string: <обязательный>) - Указывает сертификаты для импорта, конкатенированные в формате PEM.

    Этот параметр только на пути /pki/intermediate/set-signed.
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data "@payload.json" \
    http://127.0.0.1:8200/v1/pki/config/ca

Обратите внимание, что если вы предоставляете данные через HTTP API, они должны быть отформатированы в JSON, и новые строки должны быть заменены на \n, как показано ниже:

{
  "pem_bundle": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END CERTIFICATE-----"
}
Пример ответа:
{
  "data": {
    "imported_issuers": ["1ae8ce9d-2f70-0761-a465-8c9840a247a2"],
    "imported_keys": ["97be2525-717a-e2f7-88da-0a20e11aad88"],
    "mapping": {
      "1ae8ce9d-2f70-0761-a465-8c9840a247a2": "97be2525-717a-e2f7-88da-0a20e11aad88"
    },
    "existing_issuers": [],
    "existing_keys": []
  }
}

6.7. Чтение издателя

Эта конечная точка позволяет оператору получить один сертификат издателя и его цепочку, включая внутреннюю информацию, которая не раскрыта на неаутентифицированной конечной точке /pki/issuer/:issuer_ref/json. Это включает информацию о имени, материале ключа, если была установлена явно конструированная цепочка, поведение для подписания сертификатов с более длительным временем действия, и какие режимы использования установлены для этого издателя.

Метод Путь

GET

/pki/issuer/:issuer_ref

6.7.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/issuer/default
Пример ответа:
{
  "data": {
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
      "-----BEGIN CERTIFICATE-----\nMIIDFTCCAf2gAwIBAgIUUo/qwLm5AyqUWqFHw1MlgwUtS/kwDQYJKoZIhvcNAQEL\n..."
    ],
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
    "issuer_id": "7545992c-1910-0898-9e64-d575549fbe9c",
    "issuer_name": "root-x1",
    "key_id": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf",
    "leaf_not_after_behavior": "truncate",
    "manual_chain": null,
    "usage": "read-only,issuing-certificates,crl-signing,ocsp-signing"
  }
}

6.8. Обновление издателя

Эта конечная точка позволяет оператору управлять одним издателем, обновляя различные свойства о нем, включая его имя, явно сконструированную цепочку, поведение подписания более длительных сертификатов с временем действия, и какие режимы использования установлены для этого издателя.

Имейте в виду, что изменить сертификат этого издателя нельзя; для этого необходимо импортировать нового издателя, и будет назначен новый issuer_id.

Метод Путь

POST

/pki/issuer/:issuer_ref

PATCH

/pki/issuer/:issuer_ref

Отправка запроса POST на эту конечную точку приводит к тому, что StarVault перезаписывает предыдущие содержимое издателя, используя предоставленные данные запроса (и любые значения по умолчанию для упущенных параметров). Это не обновляет только предоставленные поля.

StarVault поддерживает операцию PATCH на этой конечной точке, используя формат патча JSON поддерживаемый KVv2, позволяя обновление определенных полей. Учтите, что bao write использует POST.

6.8.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий издатель, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный издатель, или по имени, присвоенному издателю. Этот параметр является частью URL запроса.

  • issuer_name (string: "") - указывает имя для указанного издателя. Имя должно быть уникальным среди всех издателей и не может быть значением, зарезервированным для default.

  • leaf_not_after_behavior (string: "err") - поведение поля NotAfterleaf во время выдачи. Допустимые варианты:

    • err, чтобы выдача завершилась ошибкой, если вычисленное значение NotAfter превышает это значение для данного издателя;

    • truncate, чтобы втихую усечь запрашиваемое значение NotAfter до значения этого удостоверяющего центра; или

    • permit, чтобы позволить этому выпуску завершиться с `NotAfter`значением, превышающим значение этого удостоверяющего центра.

Не все значения приводят к тому, что сертификаты leaf могут быть действительными на протяжении всего срока действия. Рекомендуется использовать truncate для промежуточных ЦА и permit только для корневых ЦА. Это связано с тем, что (корневые) сертификаты в хранилищах доверенных браузеров, как правило, не проверяются на действительность, в то время как промежуточные сертификаты CA, отправляемые в TLS-соединениях, проверяются на действительность в момент использования. Это означает, что сертификат leaf может быть разрешен на выпуск на более длительный срок, чем промежуточный, что, вероятно, не будет продолжать действовать после истечения промежуточного сертификата.

  • manual_chain ([]string: nil) - цепочка ссылок на издателей, чтобы построить поле CAChain этого издателя, когда не пусто.

    Поле manual_chain является продвинутым полем, полезным, когда автоматическая сборка цепочки не желательна. Первый элемент должен быть ссылкой на текущий издатель. Последующие ссылки должны подтверждать предыдущие записи, завершаясь корневым сертификатом. Идеально должна быть одна линейная цепочка, которая идет сначала (от этого издателя до единственного корневого сертификата), перед тем, как появятся любые параллельные, альтернативные цепочки.

    Это поле особенно полезно для кросс-подписанных промежуточных сертификатов в StarVault. Поскольку каждый кросс-подписанный промежуточный сертификат будет знать только о единственном корне, но выпуск должен обслуживать оба, обновите записи издателя с желаемым значением manual_chain.

    Цепочка CA, возвращаемая при получении конфигурации издателя, такая же, как та, которая представляется во время подписания и (если это удостоверяющий центр по умолчанию) на пути /ca_chain. Установка manual_chain таким образом позволяет контролировать предоставляемую цепочку так, как это необходимо.

  • usage ([]string: read-only,issuing-certificates,crl-signing,ocsp-signing) - разрешенные использования для этого издателя. Допустимые варианты: read-only, чтобы позволить читать этот издатель; неявно; всегда разрешено; issuing-certificates, чтобы разрешить использование этого издателя для выпуска других сертификатов;

    • crl-signing, чтобы разрешить использование этого издателя для подписания CRL. Это отдельно от ограничения CRLSign на сертификате x509, но это использование не может быть установлено, если это ограничение разрешено на сертификате x509.

    • ocsp-signing, чтобы разрешить использование этого издателя для подписания OCSP-ответов.

      Примечание: поле usage позволяет осуществлять мягкое удаление на данном издателе или предотвращает использование издателя до его активации. Например, поскольку выпуск переведен на нового издателя, старый издатель может быть отмечен как usage=read-only,crl-signing,ocsp-signing, позволяя отзыву существующих сертификатов (и обновлению CRL), но предотвращая выпуск новых сертификатов. После того как все сертификаты, выданные по этому сертификату, истекут, этот сертификат может быть помечен как usage=read-only, замораживая CRL. Наконец, после периода льготы издатель может быть удален.

  • revocation_signature_algorithm (string: "") - указывает, какой алгоритм подписи использовать при построении CRL. См. постоянную x509.SignatureAlgorithm для возможных значений. Этот флаг позволяет контролировать хеш-функцию и схему подписи (PKCS#1v1.5 против PSS). По умолчанию (пустая строка) используется автоматический выбор алгоритма подписи OpenGo, что может не всегда работать.

    Это может завершиться неудачей, если основной ключ не поддерживает запрашиваемый алгоритм подписи; это может быть не всегда известно во время изменения.

  • issuing_certificates (array<string>: nil) - указывает значения URL для поля Issuing Certificate. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.2.1 для информации о поле доступа к информации о удостоверяющем центре.

  • crl_distribution_points (array<string>: nil) - указывает значения URL для поля точек распределения CRL. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.1.13 для информации о поле распределения CRL.

    Когда используется несколько издателей в одном монтировании, каждый издатель будет иметь свою собственную точку распределения CRL. Эти отдельные CRL должны либо быть агрегированными в единый CRL (внешне; так как StarVault не поддерживает данную функциональность), либо несколько значений для crl_distribution_points и delta_crl_distribution_points должны быть указаны здесь, указывая на каждый кластер и издателя.

  • delta_crl_distribution_points (array<string>: nil) - указывает значения URL для поля Delta CRL Distribution Points. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.1.15 и Раздел 5.2.6 для информации о поле точек распределения Delta CRL.

  • ocsp_servers (array<string>: nil) - указывает значения URL для поля OCSP Servers. Это может быть массив или строка, разделенная запятыми. См. RFC 5280 Раздел 4.2.2.1 для информации о поле доступа к информации о удостоверяющем центре.

  • enable_aia_url_templating (bool: false) - указывает, что значения URL AIA выше (issuing_certificates, crl_distribution_points, delta_crl_distribution_points и ocsp_servers) должны быть обработаны с помощью шаблонизации. Это заменяет литеральное значение {{issuer_id}} идентификатором издателя, выполняющего выпуск, литеральное значение {{cluster_path}} значением path из локальной конфигурации кластера config/cluster, и литеральное значение {{cluster_aia_path}} значением aia_path из локальной конфигурации кластера config/cluster.

    Если никакого адреса локального кластера нет и используется обработка шаблонов, выдача завершится неудачей.
Пример тела запроса:
{
  "issuer_name": "root-x1"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/issuer/default
Пример ответа:
{
  "data": {
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
      "-----BEGIN CERTIFICATE-----\nMIIDFTCCAf2gAwIBAgIUUo/qwLm5AyqUWqFHw1MlgwUtS/kwDQYJKoZIhvcNAQEL\n..."
    ],
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
    "issuer_id": "7545992c-1910-0898-9e64-d575549fbe9c",
    "issuer_name": "root-x1",
    "key_id": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf",
    "leaf_not_after_behavior": "truncate",
    "manual_chain": null,
    "usage": "read-only,issuing-certificates,crl-signing,ocsp-signing",
    "revocation_signature_algorithm": "",
    "issuing_certificates": ["<url1>", "<url2>"],
    "crl_distribution_points": ["<url1>", "<url2>"],
    "delta_crl_distribution_points": ["<url1>", "<url2>"],
    "ocsp_servers": ["<url1>", "<url2>"]
  }
}

6.9. Отзыв издателя

Эта конечная точка позволяет оператору отозвать сертификат удостоверяющего центра, тем самым помечая его как неспособный выдавать новые сертификаты и добавляя его в CRL других удостоверяющих центров, если они подписали сертификат этого удостоверяющего центра. Это приведет ко всем восстановленным CRL.

Это в основном предоставляется для ведения учета и как функция мягкого удаления, чтобы убедиться, что этот удостоверяющий центр не будет случайно повторно использован в будущем.

Эта операция не может быть отменена!

Эта операция не имеет никакого влияния на другие кластеры или монтирования и может не повлиять на то, будут ли клиенты считать эти удостоверяющие центры отозванными. Отозванные удостоверяющие центры не будут появляться в своих собственных CRL. Отозванные удостоверяющие центры могут не появиться в других CRL, если подходящий родитель не присутствует в том же монтировании. Отозванные удостоверяющие центры все равно нужно будет отзывать в любых других монтированиях, в которых они появляются, как в случае с удостоверяющими центрами, в случае повторного использования удостоверяющего центра, и как выданные сертификаты, в случае внешнего родительского монтирования.
Метод Путь

POST

/pki/issuer/:issuer_ref/revoke

6.9.1. Параметры

Нет параметров.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    http://127.0.0.1:8200/v1/pki/issuer/old-intermediate/revoke
Пример ответа:
{
  "data": {
    "ca_chain": [
      "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
      "-----BEGIN CERTIFICATE-----\nMIIDFTCCAf2gAwIBAgIUUo/qwLm5AyqUWqFHw1MlgwUtS/kwDQYJKoZIhvcNAQEL\n..."
    ],
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDFDCCAfygAwIBAgIUXgxy54mKooz5soqQoRINazH/3pQwDQYJKoZIhvcNAQEL\n...",
    "issuer_id": "7545992c-1910-0898-9e64-d575549fbe9c",
    "issuer_name": "old-intermediate",
    "key_id": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf",
    "leaf_not_after_behavior": "truncate",
    "manual_chain": null,
    "usage": "read-only,issuing-certificates,crl-signing"
    "revocation_time": 1433269787
  }
}

6.10. Удаление издателя

Эта конечная точка удаляет указанный удостоверяющий центр. При этом выдается предупреждение, и умолчание очищается, если этот удостоверяющий центр является стандартным.

Если удостоверяющий центр был ошибочно удален, но его ключевой материал остается, его можно повторно импортировать только как сертификат удостоверяющего центра. issuer_id изменится, но имя может быть переназначено новому удостоверяющему центру.
Метод Путь

DELETE

/pki/issuer/:issuer_ref
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/pki/issuer/root-x1

6.11. Импорт ключа

Эта конечная точка позволяет оператору импортировать один ключ, закодированный в pem, rsa, ec или ed25519.

Этот API не защищает от импорта ключей с использованием небезопасных комбинаций алгоритмов и длины ключей.
Метод Путь

POST

/pki/keys/import

6.11.1. Параметры

  • pem_bundle (string: <обязательный>) - указывает незашифрованный закрытый ключ в формате PEM. * key_name (string: "") - указывает имя для заданного ключа. Имя должно быть уникальным для всех ключей и не может быть зарезервированным значением default.

Пример тела запроса:
{
  "key_name": "my-imported-key",
  "pem_bundle": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END CERTIFICATE-----"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/keys/import
Пример ответа:
{
  "data": {
    "key_id": "2cf03991-b052-1dc3-393e-374b41f8dcd8",
    "key_name": "my-imported-key",
    "key_type": "rsa"
  }
}

6.12. Чтение ключа

Эта конечная точка позволяет оператору получить информацию о существующем ключе.

Примечание: StarVault не позволяет чтение значения закрытого ключа после его создания.
Метод Путь

GET

/pki/key/:key_ref

6.12.1. Параметры

  • key_ref (string: <обязательный>) - Ссылка на существующий ключ, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный ключ, или по имени, присвоенному ключу. Этот параметр является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/key/default
Пример ответа:
{
  "data": {
    "key_id": "8c4046f8-52a8-0974-29d2-745d8a0dd848",
    "key_name": "key-root-x1",
    "key_type": "rsa"
  }
}

6.13. Обновление ключа

Эта конечная точка позволяет оператору управлять одним ключом. В настоящее время только параметр, который можно настроить, - это имя ключа.

Имейте в виду, что изменить закрытый ключ этого ключа нельзя; для этого необходимо импортировать новый ключ, и будет назначен новый key_id.

Метод Путь

POST

/pki/key/:key_ref

Отправка POST-запроса на эту конечную точку приводит к тому, что StarVault перезаписывает предыдущее содержимое ключа, используя предоставленные данные запроса (и любые значения по умолчанию для упущенных параметров). Это не обновляет только предоставленные поля.

6.13.1. Параметры

  • key_ref (string: <обязательный>) - ссылка на существующий ключ, либо по идентификатору, сгенерированному StarVault, либо по строке default, чтобы сослаться на текущий настроенный стандартный ключ, или по имени, присвоенному ключу. Этот параметр является частью URL запроса.

  • key_name (string: "") - указывает имя для указанного ключа. Имя должно быть уникальным среди всех ключей и не может быть зарезервированным значением default.

Пример тела запроса:
{
  "key_name": "key-root-x1"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/key/default
Пример ответа:
{
  "data": {
    "key_id": "8c4046f8-52a8-0974-29d2-745d8a0dd848",
    "key_name": "key-root-x1",
    "key_type": "rsa"
  }
}

6.14. Удаление ключа

Эта конечная точка удаляет указанный ключ. Выдается предупреждение и значение по умолчанию очищается, если этот ключ является стандартным ключом.

Поскольку StarVault не позволяет экспортировать закрытый ключ после его первоначального создания, удаление ключей является чувствительной операцией. Кроме того, один ключ может использоваться более чем одним удостоверяющим центром. В результате StarVault запрещает удаление ключей, пока все удостоверяющие центры, использующие этот ключ, также не были удалены. Если эти удостоверяющие центры все еще необходимы для построения цепочки, их можно повторно импортировать без соответствующих ключей после того, как ключ будет удален, или воспользоваться функцией мягкого удаления удостоверяющих центров.
Метод Путь

DELETE

/pki/key/:key_ref
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/pki/key/key-root-x1

6.15. Удаление всех издателей и ключей

Эта конечная точка удаляет всех удостоверяющих центров и ключи в пределах монтирования. Настоятельно рекомендуется использовать отдельные операции удаления. Это монтирование станет unusable до тех пор, пока не будут предусмотрены новые удостоверяющие центры и ключи.

Эта конечная точка требует привилегий sudo/root.

Метод Путь

DELETE

/pki/root
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/pki/root

7. Управление информацией о владельце

Следующие привилегированные конечные точки позволяют оператору контролировать информацию о основных содержимом сертификатов и выполнять привилегированные операции, такие как ротация CRL или выполнение очистительных операций.

7.1. Список ролей

Смотрите предыдущий раздел для получения дополнительной информации о перечислении ролей CEL.

7.2. Создание/Обновление роли

Эта конечная точка создает или обновляет определение роли CEL.

Метод Путь

POST

/pki/cel/roles/:name

PATCH

/pki/cel/roles/:name

7.2.1. Параметры

  • name (string: <обязательный>) - указывает имя роли CEL для создания. Это является частью URL запроса.

  • cel_program (CelProgram: <обязательный>) - указывает список переменных CEL и основное выражение CEL. Смотрите https://openbao.org/docs/secrets/pki/cel для получения дополнительной информации о том, как правильно создать программу CEL.

Пример тела запроса:
{
  "cel_program": {
    "variables": [
      {
        "name": "validate_cn",
        "expression": "has(request.common_name) && request.common_name == \"example.com\""
      },
      {
        "name": "small_ttl",
        "expression": "has(request.ttl) && duration(request.ttl) < duration(\"4h\")"
      },
      {
        "name": "cn_value",
        "expression": "request.common_name"
      },
      {
        "name": "not_after",
        "expression": "now + duration(request.ttl)"
      },
      {
        "name": "cert",
        "expression": "CertTemplate{ Subject: PKIX.Name{ CommonName: cn_value, Country: [\"ZW\", \"US\"] }, NotBefore: now, NotAfter: not_after, IsCA: true, MaxPathLen: 10, PolicyIdentifiers: [ ObjectIdentifier{ arc: [1u,2u,3u] }, ObjectIdentifier{ arc: [2u,59u,1u] } ], IPAddresses: [ net.IP{ IP: b\"\\x0A\\x00\\x00\\x00\" } ] }"
      },
      {
        "name": "output",
        "expression": "ValidationOutput{ template: cert, generate_lease: small_ttl, no_store: !small_ttl, issuer_ref: \"default\", key_type: request.key_type, key_bits: uint(request.key_bits) }"
      },
      {
        "name": "err",
        "expression": "'Request should have Common name.'"
      }
    ],
    "expression": "validate_cn ? output : err"
  }
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/cel/roles/my-role

7.3. Чтение роли

Смотрите предыдущий раздел для получения дополнительной информации о чтении ролей.

7.4. Удаление роли

Эта конечная точка удаляет определение роли CEL. Удаление роли не аннулирует сертификаты, ранее выданные по этой роли.

Метод Путь

DELETE

/pki/cel/roles/:name

7.4.1. Параметры

  • name (string: <обязательный>) - указывает имя роли для удаления. Это является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/pki/cel/roles/my-role

7.5. Список ролей

Смотрите предыдущий раздел для получения дополнительной информации о перечислении ролей.

7.6. Создать/Обновить роль

Эта конечная точка создает или обновляет определение роли. Обратите внимание, что атрибуты allowed_domains, allow_subdomains, allow_glob_domains и allow_any_name являются добавочными; между ними практически и через несколько ролей может быть учтена почти любая политика выдачи.

Обработка ExtKeyUsage в выданном сертификате leaf сложна: если любой из них server_flag, client_flag, code_signing_flag или email_protection_flag установлен, они добавляются к сгенерированному значению ExtKeyUsage. Затем к значениям в поле ext_key_usage добавляются имена, и после этого OID из ext_key_usage_oids. Это может привести к выдаче сертификатов с неожиданными значениями ExtKeyUsage, так как, например, server_flag и client_flag по умолчанию равны true и требуют ручного отключения, прежде чем будут учтены ext_key_usage и ext_key_usage_oids.

Если клиент запрашивает сертификат, который не разрешен политикой CN в роли, запрос будет отклонен.

Метод Путь

POST

/pki/roles/:name

PATCH

/pki/roles/:name

Отправка запроса POST на эту конечную точку, когда роль уже существует, приводит к тому, что StarVault перезаписывает содержимое роли, используя предоставленные данные запроса (и любые значения по умолчанию для упущенных параметров). Это не обновляет только предоставленные поля.

StarVault поддерживает операцию PATCH на этой конечной точке, используя формат патча JSON поддерживаемый KVv2, позволяя обновление конкретных полей. Учтите, что bao write использует POST.

7.6.1. Параметры

  • name (string: <обязательный>) - указывает имя роли для создания. Это является частью URL запроса.

  • issuer_ref (string: "default") - указывает стандартного удостоверяющего центра для этого запроса. Могут быть указаны значения default, имя или идентификатор удостоверяющего центра. Используйте ACL, чтобы предотвратить доступ к путям /pki/issuer/:issuer_ref/{issue,sign}/:name, чтобы избежать переопределения значения issuer_ref роли.

    Этот параметр сохраняется как есть; если ссылка указывает на имя, она не разрешается в идентификатор. Удаление удостоверяющих центров (или обновление их имен) может привести к отказу в выдаче разрешений или использованию неожиданного удостоверяющего центра.

  • ttl (string: "") - указывает значение времени жизни, которое будет использоваться для срока действия запрашиваемого сертификата, предоставленного в виде строковой длительности с суффиксом времени. Часы - наибольший суффикс. Указанное значение строго используется для будущей действительности. Если не установлено, используется системное значение по умолчанию или значение max_ttl, в зависимости от того, что короче. См. not_after как альтернативу для установки абсолютной даты завершения (вместо относительной).

  • max_ttl (string: "") - указывает максимальное значение времени жизни, предоставленное в виде строковой длительности с суффиксом времени. Часы - наибольший суффикс. Если не установлено, по умолчанию используется максимальное значение системной аренды TTL.

  • allow_localhost (bool: true) - указывает, могут ли клиенты запрашивать сертификаты для localhost в качестве одного из запрашиваемых общих имен. Это полезно для тестирования и позволяет клиентам на одном хосте безопасно общаться.

    Это строго относится к localhost и localdomain, когда эта опция включена. Кроме того, даже если эта опция отключена, если любое имя включено в allowed_domains, правила сопоставления для этой опции могут разрешить выдачу сертификата для localhost.

  • allowed_domains (list: []) - указывает домены, для которых этой роли разрешено выдавать сертификаты. Это используется вместе с опциями allow_bare_domains, allow_subdomains и allow_glob_domains, чтобы определить тип соответствия между этими доменами и значениями общего имени, DNS-типизированными SAN-записями и записями EMAIL-типизированными SAN. Когда используется allow_any_name, этот атрибут не оказывает влияния.

    Три опции allow_bare_domains, allow_subdomains и allow_glob_domains независимы друг от друга. То есть, как минимум один тип допустимого соответствия должен описывать взаимосвязь между списком allowed_domains и именами на выданном сертификате. Например, при наличии allowed_domain=foo..example.com и allow_subdomains=true и allow_glob_domains=true, запрос на bar.foo.baz.example.com не будет разрешен, даже если он foo.baz.example.com соответствует глобу foo..example.com.

  • allowed_domains_template (bool: false) - если установлено, allowed_domains могут содержать шаблоны, как и шаблонизация путей ACL. Нешаблонированные домены также все еще разрешены.

  • allow_bare_domains (bool: false) - указывает, могут ли клиенты запрашивать сертификаты, соответствующие значению самих доменов; например, если настроенный домен с allowed_domains - example.com, это позволяет клиентам на самом деле запрашивать сертификат с именем example.com в качестве одного из DNS значений на конечном сертификате. В некоторых сценариях это может рассматриваться как риск безопасности. Обратите внимание, что когда поле allowed_domain содержит потенциальный символ подстановки (например, allowed_domains=.example.com), и обе опции allow_bare_domains и allow_wildcard_certificates включены, то будет разрешено выдача сертификата для подстановки .foo.example.com.

  • allow_subdomains (bool: false) - указывает, могут ли клиенты запрашивать сертификаты с CN, которые являются поддоменами CN, разрешенными другими параметрами роли. Это включает поддомены с подстановочными знаками. Например, значение allowed_domains example.com с этой опцией, установленной на true, позволит foo.example.com и bar.example.com, а также *.example.com. Чтобы ограничить выдачу подстановок с помощью этой опции, смотрите allow_wildcard_certificates ниже. Эта опция является избыточной при использовании опции allow_any_name.

  • allow_glob_domains (bool: false) - позволяет именам, указанным в allowed_domains, содержать шаблоны (например, ftp*.example.com). Клиенты будут иметь возможность запрашивать сертификаты с именами, соответствующими шаблонам.

    Эти шаблоны ведут себя как шаблоны в стиле оболочки и могут соответствовать через несколько частей домена. Например, allowed_domains=*.example.com с включенной allow_glob_domains будет соответствовать не только foo.example.com, но и baz.bar.foo.example.com.

    Шаблоны будут совпадать с подстановочными доменами и разрешать их выдачу, если иное не ограничено allow_wildcard_certificates. Например, с allowed_domains=..example.com и включенными обоими allow_glob_domains и allow_wildcard_certificates мы разрешим выдачу подстановочного сертификата для *.foo.example.com.

  • allow_wildcard_certificates (bool: true) - разрешает выдачу сертификатов с подстановками в ведущем поле CN в соответствии с RFC 6125. Если установлено в false, это предотвращает выдачу подстановок, даже если они были бы разрешены другими опциями. Мы поддерживаем следующие четыре типа подстановок:

    • *.example.com, одна подстановка в самой левой метке;

    • foo*.example.com, одна подстановка с суффиксом в самой левой метке;

    • *foo.example.com, одна подстановка с префиксом в самой левой метке;

    • foo.example.com, одна подстановка во внутренней метке в самой левой метке.

  • allow_any_name (bool: false) - указывает, могут ли клиенты запрашивать любое CN. Полезно в некоторых обстоятельствах, но убедитесь, что вы понимаете, подходит ли это для вашей установки, прежде чем активировать его. Обратите внимание, что оба enforce_hostnames и allow_wildcard_certificates все еще проверяются, что может внести ограничения на выдачу с этой опцией.

  • enforce_hostnames (bool: true) - указывает, разрешены ли только допустимые имена хостов для CN, DNS SAN и части электронной почты.

  • allow_ip_sans (bool: true) - указывает, могут ли клиенты запрашивать IP альтернативные имена субъектов. Не выполняется проверка разрешения, кроме как для проверки того, что указанные значения являются допустимыми IP-адресами.

  • allowed_uri_sans (string: "") - определяет разрешенные URI альтернативные имена субъектов. Это может быть строка, разделенная запятыми, или массив строк JSON. Значения могут содержать шаблоны (например, spiffe://hostname/*).

  • allowed_uri_sans_template (bool: false) - когда установлено, allowed_uri_sans может содержать шаблоны, как и шаблонизация путей ACL. Нешаблонированные домены также все еще разрешены.

  • allowed_other_sans (string: "") - определяет разрешенные пользовательские OID/UTF8-строковые SANs. Это может быть строка, разделенная запятыми, или массив строк JSON, где каждый элемент имеет такой же формат, как OpenSSL: <oid>;<type>:<value>, но единственный действительный тип - это UTF8 или UTF-8. Полезная часть элемента может быть *, чтобы разрешить любое значение с этим OID.

    В качестве альтернативы, указание единственного * разрешит любое значение для other_sans.

  • allowed_serial_numbers (string: "") - если установлено, массив разрешенных серийных номеров, запрашиваемых во время выпуска сертификата. Эти значения поддерживают шаблоны в стиле оболочки. Когда пусто, настраиваемые серийные номера запрещены. Настоятельно рекомендуется позволить StarVault генерировать случайные серийные номера вместо этого.

  • server_flag (bool: true) - указывает, отмечены ли сертификаты для использования в аутентификации сервера. См. RFC 5280 Раздел 4.2.1.12 для информации о поле расширенного использования ключей.

  • client_flag (bool: true) - указывает, отмечены ли сертификаты для использования в аутентификации клиента. См. RFC 5280 Раздел 4.2.1.12 для информации о поле расширенного использования ключей.

  • code_signing_flag (bool: false) - указывает, отмечены ли сертификаты для использования в подписании кода. См. RFC 5280 Раздел 4.2.1.12 для информации о поле расширенного использования ключей.

  • email_protection_flag (bool: false) - указывает, отмечены ли сертификаты для использования в защите электронной почты. См. RFC 5280 Раздел 4.2.1.12 для информации о поле расширенного использования ключей.

  • key_type (string: "rsa") - указывает тип ключа для генерируемых закрытых ключей и тип ключа, ожидаемый для предоставленных CSRs. В настоящее время поддерживаются rsa, ec, и ed25519, или при подписывании существующих CSRs можно указать any, чтобы позволить ключи любого типа и с любой длиной бит (при условии >=2048 бит для RSA ключей или >= 224 для EC ключей). Когда используется any, эта роль не может генерировать сертификаты и может только подписывать сертификаты.

    В режиме FIPS 140-2 следующие алгоритмы не сертифицированы и поэтому не должны использоваться: ed25519.

  • key_bits (int: 0) - указывает количество бит, которые следует использовать для сгенерированных ключей. Допустимые значения: 0 (универсальное значение по умолчанию); с key_type=rsa, допустимые значения: 2048 (по умолчанию), 3072, или 4096; с key_type=ec, допустимые значения: 224, 256 (по умолчанию), 384, или 521; игнорируются при key_type=ed25519 или при подписании операций, когда key_type=any.

  • signature_bits (int: 0) - указывает количество бит для использования в алгоритме подписи; принимает 256 для SHA-2-256, 384 для SHA-2-384, и 512 для SHA-2-512. По умолчанию 0 для автоматического определения на основе длины ключа издателя (SHA-2-256 для RSA-ключей и соответствующего размера кривой для NIST P-Кривых).

Издатели ECDSA и Ed25519 не следуют конфигурации значения signature_bits; только издатели RSA будут изменять типы подписей в зависимости от этого параметра.

  • use_pss (bool: false) - указывает, следует ли использовать PSS подписи вместо PKCS#1v1.5 подписей, когда используется эмитент типа RSA. Игнорируется для Эмитентов ECDSA/Ed25519.

  • key_usage (list: ["DigitalSignature", "KeyAgreement", "KeyEncipherment"]) - указывает разрешенные ограничения на использование ключа для выданных сертификатов. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#KeyUsage - просто опустите часть KeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие ограничений на использование ключа, установите это в пустой список. См. RFC 5280 Раздел 4.2.1.3 для получения дополнительной информации о поле использования ключа.

  • ext_key_usage (list: []) - указывает разрешенные ограничения на использование расширенного ключа для выданных сертификатов. Допустимые значения можно найти на https://golang.org/pkg/crypto/x509/#ExtKeyUsage - просто опустите часть ExtKeyUsage из значения. Значения не чувствительны к регистру. Чтобы указать отсутствие ограничений на использование ключа, установите это в пустой список. См. RFC 5280 Раздел 4.2.1.12 для информации о поле расширенного использования ключей.

  • ext_key_usage_oids (string: "") - кома-разделенная строка или список OID расширенного использования ключей. Полезно для добавления EKU, не поддерживаемых стандартной библиотекой Go.

  • use_csr_common_name (bool: true) - когда используется с конечной точкой подписания CSR, общее имя в CSR будет использоваться вместо того, чтобы браться из данных JSON. Это не включает любые запрашиваемые SAN в CSR; используйте use_csr_sans для этого.

  • use_csr_sans (bool: true) - когда используется с конечной точкой подписания CSR, альтернативные имена субъектов в CSR будут использоваться вместо того, чтобы брались из JSON. Это не включает общее имя в CSR; используйте use_csr_common_name для этого.

  • ou (string: "") - указывает значения OU (OrganizationalUnit) в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • organization (string: "") - указывает значения O (Organization) в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • country (string: "") - указывает значения C (Country) в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • locality (string: "") - указывает значения L (Locality) в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • province (string: "") - указывает значения ST (Province) в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • street_address (string: "") - указывает значения улицы в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • postal_code (string: "") - указывает значения почтового кода в поле субъекта выданных сертификатов. Это строка, разделенная запятыми, или JSON-массив.

  • generate_lease (bool: false) - указывает, будут ли сертификаты, выданные/подписанные против этой роли, иметь присоединенные аренды StarVault. Сертификаты могут быть добавлены в CRL с помощью starvault revoke <lease_id>, когда сертификаты связаны с арендами. Это также можно сделать с помощью конечной точки pki/revoke. Однако, когда организация аренды отключена, вызов pki/revoke будет единственным способом добавить сертификаты в CRL. Когда выдаются большие количества сертификатов с длительными сроками действия, рекомендуется отключить генерацию аренды, поскольку большое количество аренды негативно влияет на время запуска StarVault.

  • no_store (bool: false) - если установлено, сертификаты, выданные/подписанные против этой роли, не будут храниться в хранилище. Это может улучшить производительность при выдаче большого количества сертификатов. Однако сертификаты, выданные таким образом, не могут быть перечислены или отозваны по серийному номеру. Сертификаты могут все еще быть отозваны через отзыв BYOC. Эта опция рекомендуется только для сертификатов, которые не являются чувствительными, имеют очень короткий срок действия или имеют высокий объем, чтобы избежать хранения. Эта опция подразумевает значение false для generate_lease.

  • require_cn (bool: true) - если установлено в false, делает поле common_name необязательным при создании сертификата.

  • policy_identifiers (list: []) - запятая-разделенная строка или список OID политики.

  • basic_constraints_valid_for_non_ca (bool: false) - Указывает, что основные ограничения действительны при выпуске сертификатов, не являющихся CA.

  • not_before_duration (duration: "30s") - указывает продолжительность, на которую необходимо вернуть поле NotBefore. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl.

  • not_before_bound (string: "permit") - указывает, может ли и как может быть предоставлено значение not_before при запросе сертификата. По умолчанию установлено в permit. Допустимые варианты:

    • permit, чтобы разрешить предоставление not_before.

    • duration, чтобы разрешить предоставление not_before в пределах ограничений not_before_duration.

    • forbid, чтобы запретить предоставление not_before.

    • или явный максимальный временной штамп в формате UTC YYYY-MM-ddTHH:MM:SSZ.

  • not_before (string) - установите поле "Not Before" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Это значение не влияет на срок действия запрашиваемого сертификата, указанного в поле ttl.

  • not_after_bound (string: "permit") - указывает, может ли и как может быть предоставлено значение not_after при запросе сертификата. По умолчанию установлено в permit. Допустимые варианты:

    • permit, чтобы разрешить предоставление not_after.

    • ttl-limited, чтобы разрешить предоставление not_after в пределах ограничений роли TTL.

    • forbid, чтобы запретить предоставление not_after.

    • или явный максимальный временной штамп в формате UTC YYYY-MM-ddTHH:MM:SSZ.

  • not_after (string) - установите поле "Not After" сертификата с указанным значением даты. Формат значения должен быть в формате UTC YYYY-MM-ddTHH:MM:SSZ. Поддерживает конечную дату Y10K для стандартных устройств IEEE 802.1AR-2018, 9999-12-31T23:59:59Z.

  • cn_validations (list: ["email", "hostname"]) - проверки для выполнения на поле общего имени сертификата. Допустимые значения включают:

    • email, чтобы убедиться, что общее имя является адресом электронной почты (содержит знак @),

    • hostname, чтобы убедиться, что общее имя является именем хоста (в противном случае).

      Несколько значений могут быть разделены запятыми или указаны как список и использовать семантику OR (разрешить либо адрес электронной почты, либо имя хоста в CN). Когда используется специальное значение "disabled" (может быть указано только одно), никакие обычные проверки не производятся (включительно, но не ограничиваясь allowed_domains и основной правильностью проверки вокруг адресов электронной почты и имен доменов). Это позволяет без особого стандарта использовать базовые CN как есть из запроса.

  • allowed_user_ids (string: "") - список идентификаторов пользователей, разделенный запятыми, с использованием подстановочного знака, который разрешает запросы. По умолчанию нет разрешенных идентификаторов пользователей. Используйте открытый подстановочный знак *, чтобы разрешить любое значение. Смотрите также параметр запроса user_ids.

Пример тела запроса:
{
  "allowed_domains": ["example.com"],
  "allow_subdomains": true
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/roles/my-role

7.7. Чтение роли

Смотрите предыдущий раздел для получения дополнительной информации о чтении ролей.

7.8. Удаление роли

Эта конечная точка удаляет определение роли. Удаление роли не отзывает сертификаты, ранее выданные по этой роли.

Метод Путь

DELETE

/pki/roles/:name

7.8.1. Параметры

  • name (string: <обязательный>) - указывает имя роли для удаления. Это является частью URL запроса.

Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request DELETE \
    http://127.0.0.1:8200/v1/pki/roles/my-role

7.9. Чтение URL

Эта конечная точка получает URL, которые должны быть закодированы в сгенерированных сертификатах. Никакая конфигурация URL не будет возвращена, пока конфигурация не будет установлена.

Метод Путь

GET

/pki/config/urls
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/urls
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "issuing_certificates": ["<url1>", "<url2>"],
    "crl_distribution_points": ["<url1>", "<url2>"],
    "delta_crl_distribution_points": ["<url1>", "<url2>"],
    "ocsp_servers": ["<url1>", "<url2>"]
  },
  "auth": null
}

7.10. Установка URL

Эта конечная точка позволяет установить конечные точки сертификатов удостоверяющего центра, точки распределения CRL и конечные точки серверов OCSP, которые будут закодированы в выданных сертификатах. Вы можете обновить любое из значений в любое время, не влияя на другие существующие значения. Чтобы удалить значения, просто используйте пустую строку в качестве параметра.

Метод Путь

POST

/pki/config/urls

При использовании нескольких удостоверяющих центров в одном монтировании настоятельно рекомендуется использовать информацию AIA для каждого удостоверяющего центра вместо глобальной информации AIA. Если какое-либо из полей AIA для отдельных удостоверяющих центров установлено, предпочтения всего удостоверяющего центра будут использоваться вместо этого. В противном случае эти поля используются в качестве резервных.

Это можно сделать с помощью шаблонных глобальных значений AIA, но установив локальный адрес кластера в конфигурации.

7.10.1. Параметры

  • issuing_certificates (array<string>: nil) - указывает URL для поля Issuing Certificate. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.2.1 для информации о поле доступа к информации о удостоверяющем центре.

  • crl_distribution_points (array<string>: nil) - указывает URL для поля точек распределения CRL. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.1.13 для информации о поле распределения CRL.

Когда используется несколько удостоверяющих центров в одном монтировании, у каждого удостоверяющего центра будет своя собственная точка распределения CRL. Эти отдельные CRL должны либо агрегироваться в один CRL (внешне; так как StarVault не поддерживает эту функциональность), либо несколько значений для crl_distribution_points и delta_crl_distribution_points должны быть указаны здесь, указывая на каждый кластер и удостоверяющий центр.

  • delta_crl_distribution_points (array<string>: nil) - указывает URL для поля точек распределения Delta CRL. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.1.15 и Раздел 5.2.6 для информации о поле точек распределения Delta CRL.

  • ocsp_servers (array<string>: nil) - указывает URL для поля OCSP Servers. Это может быть массив или строка, разделенная запятыми. См. также RFC 5280 Раздел 4.2.2.1 для информации о поле доступа к информации о удостоверяющем центре.

  • enable_templating (bool: false) - указывает, что значения URL AIA выше (issuing_certificates, crl_distribution_points, delta_crl_distribution_points и ocsp_servers) должны быть обработаны с помощью шаблонизации. Это заменяет литеральное значение {{issuer_id}} идентификатором удостоверяющего центра, выполняющего выпуск, литеральное значение {{cluster_path}} значением path из локальной конфигурации кластера /config/cluster, и литеральное значение {{cluster_aia_path}} значением aia_path из локальной конфигурации кластера /config/cluster.

    Например, следующие значения могут использоваться глобально, чтобы гарантировать, что все AIA URL используют локальный, канонический на уровне удостоверяющего центра, но с сертификатом удостоверяющего центра и точками распределения CRL, которые могут использовать внешний, не StarVault CDN.

    • issuing_certificates={{cluster_aia_path}}/issuer/{{issuer_id}}/der

    • crl_distribution_points={{cluster_aia_path}}/issuer/{{issuer_id}}/crl/der

    • delta_crl_distribution_points={{cluster_aia_path}}/issuer/{{issuer_id}}/crl/delta/der

    • ocsp_servers={{cluster_aia_path}}/ocsp

Если никакого адреса локального кластера нет и используется обработка шаблонов, выдача завершится неудачей.
Пример тела запроса:
{
  "issuing_certificates": ["{{cluster_aia_path}}/issuer/{{issuer_id}}/der"],
  "crl_distribution_points": ["{{cluster_aia_path}}/issuer/{{issuer_id}}/crl/der"],
  "delta_crl_distribution_points": ["{{cluster_aia_path}}/issuer/{{issuer_id}}/crl/delta/der"],
  "ocsp_servers": ["{{cluster_aia_path}}/ocsp"]
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/urls

7.11. Чтение конфигурации издателя

Эта конечная точка позволяет получить значение стандартного удостоверяющего центра.

Метод Путь

GET

/pki/config/issuers
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/issuers
Пример ответа:
{
  "data": {
    "default": "3dc79a5a-7a6c-70e2-1123-94b88557ba12",
    "default_follows_latest_issuer": "false"
  }
}

7.12. Установка конфигурации издателя

Эта конечная точка позволяет установить значение стандартного удостоверяющего центра.

Метод Путь

POST

/pki/config/issuers

POST

/pki/root/replace

7.12.1. Параметры

  • default (string: "") - указывает стандартный удостоверяющий центр (по ссылке; либо имя, либо идентификатор). Когда значение не указано, а путь - /pki/root/replace, используется стандартное значение "next".

  • default_follows_latest_issuer (bool: false) - Указывает, обновляет ли операция создания корня или импорта удостоверяющего центра стандартный удостоверяющий центр на вновь добавленный удостоверяющий центр.

    Хотя новая функциональность с несколькими удостоверяющими центрами в 1.11 была обратно совместима по API, некоторые приложения полагались явно на небезопасное поведение между несколькими API, что мы исправили. Например, вызов /intermediate/generate/:type втихую удаляет любые (возможно, используемые!) ключевые материалы и генерирует новые закрытые ключи. Хотя наш ответ на эту конечную точку является обратно совместимым (возвращая новый ключ и безопасно сохраняя старые ключи), некоторые приложения неявно полагались на это поведение. Эта новая опция предназначена для обеспечения совместимости между вызовами API для этих вызывающих: вновь созданный удостоверяющий центр (после импорта — не на генерации промежуточного сертификата) станет стандартным, и, как (для всех, кто строго использует старые API) это будет выглядеть как единственный удостоверяющий центр в монтировании. Тем не менее, рекомендуется, чтобы приложения перешли к новым, более безопасным семантикам, связанным с ротацией с несколькими удостоверяющими центрами.

    Когда импорт создает более одного нового удостоверяющего центра с ключевым материалом известным этому монтированию, обновление по умолчанию не произойдет.
Пример тела запроса:
{
  "default": "root-x1"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/issuers
Пример ответа:
{
  "data": {
    "default": "3dc79a5a-7a6c-70e2-1123-94b88557ba12"
  }
}

7.13. Чтение конфигурации ключей

Эта конечная точка позволяет получить значение стандартного ключа.

Метод Путь

GET

/pki/config/keys
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/keys
Пример ответа:
{
  "data": {
    "default": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf"
  }
}

7.14. Установка конфигурации ключей

Эта конечная точка позволяет установить значение стандартного ключа.

Метод Путь

POST

/pki/config/keys

7.14.1. Параметры

  • default (string: "") - указывает стандартный ключ (по ссылке; либо имя, либо идентификатор).

Пример тела запроса:
{
  "default": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/keys
Пример ответа:
{
  "data": {
    "default": "baadd98d-ec5a-66ac-06b7-dfc91c02c9cf"
  }
}

7.15. Чтение конфигурации кластера

Эта конечная точка получает локальную конфигурацию кластера.

Локальная конфигурация кластера имеет path, который устанавливает URL для этого монтирования на определенном кластере. Это полезно для заполнения значения {{cluster_path}} во время шаблонирования URL AIA, но также может быть использовано для других значений в будущем.

Также есть aia_path, который позволяет использовать внешний, не StarVault, ответчик, устанавливая значение {{cluster_aia_path}} для шаблонирования URL AIA. Это полезно для распространения информации CA и CRL по незашифрованному, не TLS каналу.

Метод Путь

GET

/pki/config/cluster
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/cluster
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "path": "<url>",
    "aia_path": "<url>"
  },
  "auth": null
}

7.16. Установка конфигурации кластера

Эта конечная точка устанавливает локальную конфигурацию кластера.

Локальная конфигурация кластера имеет path, который устанавливает URL для этого монтирования на определенном кластере. Это полезно для заполнения значения {{cluster_path}} во время шаблонирования URL AIA, но также может быть использовано для других значений в будущем.

Также есть aia_path, который позволяет использовать внешний, не StarVault, ответчик, устанавливая значение {{cluster_aia_path}} для шаблонирования URL AIA. Это полезно для распространения информации CA и CRL по незашифрованному, не TLS каналу.

Метод Путь

POST

/pki/config/cluster

7.16.1. Параметры

  • path (string: "") - указывает путь к API монтирования этого кластера, включая любые пространства имен как компоненты пути. Например, https://a.starvault.example.com/v1/ns1/pki-root.

  • aia_path (string: "") - указывает путь к распределительной точке AIA этого кластера; может ссылаться на внешний, не StarVault, ответчик. Это для разрешения URL AIA и предоставления параметра шаблона {{cluster_aia_path}}, и не будет использоваться для других целей. Таким образом, в отличие от path выше, это может безопасно быть механизмом ненадежной передачи (например, HTTP без TLS).

Пример тела запроса:
{
  "path": "https://...",
  "aia_path": "http://..."
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/cluster

7.17. Чтение конфигурации CRL

Эта конечная точка позволяет получитьduration, в течение которого сгенерированный CRL должен быть отмечен как действительный. Никакая конфигурация CRL не будет возвращена, пока конфигурация не будет установлена, но CRL по-прежнему будет по умолчанию включен с истечением через 72 часа.

Метод Путь

GET

/pki/config/crl
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/crl
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "disable": false,
    "expiry": "72h",
    "ocsp_disable": false,
    "ocsp_expiry": "12h",
    "auto_rebuild": false,
    "auto_rebuild_grace_period": "12h",
    "enable_delta": false,
    "delta_rebuild_interval": "15m",
    "cross_cluster_revocation": true,
    "unified_crl": true,
    "unified_crl_on_existing_paths": true
  },
  "auth": null
}

7.18. Установка конфигурации CRL

Эта конечная точка позволяет установитьduration, в течение которого сгенерированный CRL должен быть отмечен как действительный. Если CRL отключен, он вернет подписанный, но нулевой длины CRL для любого запроса. Если включен, он перестроит CRL.

Если ключ ocsp_disable установлен в true, ответчик OCSP всегда будет отвечать с несанкционированным ответом OCSP на любой запрос.

Этот параметр глобален, для всех кластеров и удостоверяющих центров. Используйте полевое usage для каждого удостоверяющего центра, чтобы отключить построение CRL для конкретного удостоверяющего центра, оставляя при этом глобальное построение CRL включенным.

Отключение CRL не влияет на то, хранятся ли отозванные сертификаты внутри. Сертификаты, которые были отозваны, когда хранилище сертификатов роли включено, будут продолжать отмечаться и храниться как отозванные, пока не будет выполнена команда tidy с желаемым буфером безопасности. Повторное включение генерации CRL, таким образом, приведет к тому, что все такие сертификаты станут частью CRL.

Временная функция, контролирующая автоматическое перестраивание CRL и delta CRL, выполняется только раз в минуту; это предотвращает высокую нагрузку на систему, но ограничивает детальность временных опций ниже.
Метод Путь

POST

/pki/config/crl

7.18.1. Параметры

  • expiry (string: "72h") - сколько времени сгенерированный CRL должен действовать.

  • disable (bool: false) - отключает или включает построение CRL.

  • ocsp_disable (bool: false) - отключает или включает ответчик OCSP в StarVault.

  • ocsp_expiry (string: "12h") - количество времени, на которое может кэшироваться ответ OCSP, (управляет полем NextUpdate), полезно для сроков обновления OCSP stapling. Если установлено в 0 поле NextUpdate не устанавливается, указывая на то, что новая информация об отзыве доступна все время.

  • auto_rebuild (bool: false) - включает или отключает периодическое перестраивание CRL после истечения срока действия.

  • auto_rebuild_grace_period (string: "12h") - период льготы перед истечением CRL для попытки перестроить CRL. Должен быть короче срока действия CRL.

  • enable_delta (bool: false) - включает или отключает построение delta CRL с актуальной информацией о отзыве, дополняя последний полный CRL. Эта опция требует, чтобы auto_rebuild также была включена.

  • delta_rebuild_interval (string: "15m") - интервал для проверки новых отзывов, чтобы регенерировать delta CRL. Должен быть короче срока действия CRL.

Пример тела запроса:
{
  "expiry": "48h",
  "disable": false,
  "ocsp_disable": false,
  "ocsp_expiry": "12h",
  "auto_rebuild": true,
  "auto_rebuild_grace_period": "8h",
  "enable_delta": true,
  "delta_rebuild_interval": "10m",
  "cross_cluster_revocation": true,
  "unified_crl": true,
  "unified_crl_on_existing_paths": true
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/crl

7.19. Ротация CRL

Эта конечная точка запускает принудительную ротацию CRL всех эмитентов. Это может быть использовано администраторами для уменьшения размера CRL, если он содержит ряд сертификатов, которые теперь истекли, но не были ротированы из-за отсутствия отзывов. Если отозванных сертификатов не было, но CRL истек или близок к истечению, администраторы должны обратиться к этой конечной точке, чтобы сделать ротацию CRL вручную

Рекомендуется включить функциональность автоматического восстановления CRL, чтобы избежать необходимости вручную вызывать конечную точку Rotation, когда CRL истечет. Это гарантирует, что действительный CRL всегда поддерживается, хотя это может означать, что он может быть не самым актуальным. Если произойдет отзыв, который необходимо немедленно распространить, эту конечную точку можно использовать для регенерации CRL, хотя распространение все равно должно происходить вне StarVault (либо вручную, либо через AIA, где это поддерживается).
Метод Путь

GET

/pki/crl/rotate
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/crl/rotate
Пример ответа:
{
  "data": {
    "success": true
  }
}

7.20. Ротация delta CRL

Эта конечная точка принудительно ротирует delta CRL всех эмитентов, когда он включен. Это может быть использовано администраторами для принудительного восстановления delta CRL, если произошли высокопрофильные отзыва и существует длительный интервал между обновлением delta CRL (delta_rebuild_interval).

Заметки о ротации обычных CRL, приведенные выше, также применимы здесь.

Метод Путь

GET

/pki/crl/rotate-delta
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/crl/rotate-delta
Пример ответа:
{
  "data": {
    "success": true
  }
}

7.21. Объединение CRL от одного эмитента

Эта конечная точка позволяет объединять несколько различных CRL, которые были подписаны одним и тем же эмитентом, в один подписанный CRL. Это полезно для создания единого авторитетного CRL отзыва по различным кластерам StarVault.

Метод Путь

POST

/pki/issuer/:issuer_ref/resign-crls

7.21.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий эмитент, либо по идентификатору, сгенерированному StarVault, буквальная строка default для ссылки на текущий стандартный эмитент, или имя, присвоенное эмитенту. Этот параметр является частью URL запроса.

  • crls (список строк: <обязательный>) - список PEM кодированных CRL, которые были подписаны назначенным эмитентом.

  • crl_number (int: <обязательный>) - номер последовательности, который будет записан в расширение номера CRL.

  • delta_crl_base_number (int: -1) - использование значения 0 или больше указывает номер базовой ревизии CRL, который нужно закодировать в индикаторной расширенной CRL, иначе расширение не будет добавлено; по умолчанию -1.

  • format (string: pem) - формат объединенного CRL; может быть "pem" или "der". Если "der", значение будет кодировано в base64; по умолчанию "pem".

  • next_update (string: 72h) - количество времени, на которое полученный CRL должен быть действительным; по умолчанию 72 часа.

Пример тела запроса:
{
  "crl_number": "10",
  "next_update": "24h",
  "crls": ["<PEM crl 1>", "<PEM crl 2>"],
  "format": "pem"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    -request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/issuer/default/resign-crls
Пример ответа:
{
  "data": {
    "crl": "<PEM кодированный crl>"
  }
}

7.22. Подписание списка отзыва

Эта конечная точка позволяет сгенерировать CRL на основе предоставленных параметров данных из любого внешнего источника и подписанного назначенным эмитентом. Значения берутся дословно из предоставленных параметров.

Эта конечная точка потенциально опасна, и доступ должны иметь только высоконадежные пользователи.
Метод Путь

POST

/pki/issuer/:issuer_ref/sign-revocation-list

7.22.1. Параметры

  • issuer_ref (string: <обязательный>) - ссылка на существующий эмитент, либо по идентификатору, сгенерированному StarVault, строке default для ссылки на текущий стандартный эмитент, или имя, присвоенное эмитенту. Этот параметр является частью URL запроса.

  • crl_number (int: <обязательный>) - номер, который будет записан в расширение номера CRL.

  • delta_crl_base_number (int: -1) - использование значения 0 или больше указывает номер базовой ревизии CRL, который нужно закодировать в индикаторной расширенной CRL, иначе расширение не будет добавлено; по умолчанию -1.

  • format (string: pem) - формат объединенного CRL; может быть "pem" или "der". Если "der", значение будет кодировано в base64; по умолчанию "pem".

  • next_update (string: 72h) - количество времени, на которое полученный CRL должен быть действительным; по умолчанию 72 часа.

  • revoked_certs (тип: список карт) - каждый элемент содержит информацию о отзыве для одного серийного номера вместе с временем отзыва и расширениями, если они существуют. Каждый элемент может иметь следующие ключи/значения:

    • serial_number (тип: строка) - серийный номер отозванного сертификата

    • revocation_time (тип: строка) - время отзыва, поддерживаются форматы unix int или RFC3339

    • extensions (тип: список карт) - срез всех расширений, которые должны быть добавлены к отозванному сертификату. Каждый элемент содержит карту с следующими записями:

      • id (тип: строка) - объектный идентификатор ASN1 в формате точек

      • critical (тип: bool) - должен ли быть отмечен расширение как критическое

      • value (тип: строка) - bytes для значения расширения, закодированных в base64

  • extensions (тип: список карт) - Срез всех расширений, которые должны быть добавлены к созданному CRL, каждое значение будет содержать карту с следующими записями:

    • id (тип: строка) - объектный идентификатор ASN1 в формате точек

    • critical (тип: bool) - должен ли быть отмечен расширение как критическое

    • value (тип: строка) - bytes для значения расширения, закодированных в base64

Следующие идентификаторы расширения не могут быть предоставлены и могут быть влиять на другие параметры:

  • 2.5.29.20: Номер CRL

  • 2.5.29.27: Дельта CRL

  • 2.5.29.35: Идентификатор ключа авторитета
Пример тела запроса:
{
  "crl_number": "10",
  "next_update": "24h",
  "format": "pem",
  "revoked_certs": [
    {
      "serial_number": "39:dd:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58",
      "revocation_time": "2009-11-10T23:00:00Z"
    },
    {
      "serial_number": "40:33:2e:90:b7:23:1f:8d:d3:7d:31:c5:1b:da:84:d0:5b:65:31:58",
      "revocation_time": "1257894000"
    }
  ]
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    -request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/issuer/default/sign-revocation-list
Пример ответа:
{
  "data": {
    "crl": "<PEM закодированный crl>"
  }
}

7.23. Упорядочение

Эта конечная точка позволяет очистить схему хранения и/или CRL, удалив сертификаты, которые истекли и находились за пределами определённого запаса времени, прошедшего с момента их окончания.

Метод Путь

POST

/pki/tidy

Рекомендуется использовать возможности автоматической очистки, чтобы гарантировать, что это выполняется периодически.

7.23.1. Параметры

  • tidy_cert_store (bool: false) - указывает, следует ли удалить сертификаты из схемы хранения.

  • tidy_revoked_certs (bool: false) - установите в true, чтобы удалить все отозванные и истекшие сертификаты из хранения. Запись хранения отозванного сертификата считается недействительной, если запись пуста или значение внутри записи пустое. Если сертификат был удален из-за истечения, запись также будет удалена из CRL, и CRL будет повернут.

  • tidy_invalid_certs (bool: false) - установите в true, чтобы удалить все недействительные сертификаты из схемы хранения. Сертификат считается недействительным, если он не может быть распознан парсером X.509 из Go.

  • tidy_revoked_cert_issuer_associations (bool: false) - установите в true, чтобы связать отозванные сертификаты с их соответствующими эмитентами; это улучшает производительность OCSP и построение CRL, перенаправляя работу на операцию очистки.

При наличии нескольких эмитентов, CA, который выдал конкретное отозванное свидетельство, может быть удален и добавлен заново, что приведет к различию идентификатора эмитента. При построении CRL эти ссылки автоматически обновляются для любых отсутствующих или добавленных эмитентов, но во время OCSP это значение вычисляется и затем отбрасывается, что может привести к снижению производительности на каждом запросе. В ходе обычных операций CA нет необходимости запускать эту операцию.

Рекомендуется протестировать данный процесс при удалении или импорте новых эмитентов, но воздержитесь от запуска автоматического удаления в ходе регулярной очистки.

  • tidy_expired_issuers (bool: false) - установите в true, чтобы автоматически удалить истекшие эмитентов после того, как истечет срок issuer_safety_buffer. Мы фиксируем сертификат эмитента при удалении, чтобы обеспечить возможность восстановления; ключи не удаляются в ходе этого процесса.

Стандартный эмитент не будет удален, даже если он истек и находится в заявке на истечение issuer_safety_buffer.

  • tidy_move_legacy_ca_bundle (bool: false) - установите в true, чтобы сделать резервную копию любых устаревших CA/наборов эмитентов изображения в config/ca_bundle.bak. Это может быть восстановлено в sys/raw обратно в config/ca_bundle, если таковая необходимость возникнет, но не повлияет на запуск монтирования (так как монтирования будут пытаться прочитать последней и выполнить миграцию эмитентов CA, если они присутствуют). Миграция произойдет только после завершения срока issuer_safety_buffer с момента последней успешной миграции.

  • safety_buffer (строка: "") - определяет срок, используя строки формата продолжительности используемый в качестве запасного периода времени, чтобы гарантировать, что сертификаты не будут удалены преждевременно; как пример, это позволяет избежать удаления сертификатов из CRL, которые, из-за смещения часов, все еще могут считаться действительными на других хостах. Чтобы сертификат был удален, время должно быть после времени окончания срока сертификата (в соответствии с местными часами) плюс продолжительность времени safety_buffer. По умолчанию 72h. Это значение применяется к истекшим и отозванным сертификатам, если revoked_safety_buffer не выставлен, в обратном случае safety_buffer применим только к истекшим, неотозванным сертификатам.

  • revoked_safety_buffer (строка: "") - определяет срок, используя строки формата продолжительности, используемый в качестве запасного периода срока давности для отозванных, истекших сертификатов, чтобы гарантировать, что они не будут удалены преждевременно. Это значение применяется только к отозванным сертификатам, если по умолчанию выставлен в safety_buffer; в другом случае применяется ко всем отозванным сертификатам, когда unset.

  • issuer_safety_buffer (строка: "") - указывает срок, в течение которого эмитенты должны храниться после истечения их срока действия NotAfter. По умолчанию 365 дней в часах (8760h).

  • pause_duration (строка: "0s") - указывает продолжительность приостановки между очисткой отдельных сертификатов. Это освобождает блокировку отзыва и позволяет другим операциям продолжаться, пока очищение приостановлено. Это позволяет оператору контролировать использование ресурсов очистки в течение временного интервала: операция LIST останется в памяти, но пространство между чтением, разбором и обновлениями хранится за записями сертификатов на диске, увеличивается, снижая использование ресурсов.

    Не влияет на tidy_expired_issuers.

    Использование слишком долгого pause_duration может привести к тому, что операции по очистке не закончатся в течение этого времени! Использование слишком короткой паузы (но отличной от нуля) может привести к конфликту блокировок. Используйте отмену очистки для остановки запущенной операции после завершения очередной паузы.

  • page_size (int: 1000) - количество сертификатов, обрабатываемых на странице во время постраничной навигации при очистке. Эта установка позволяет очистке обрабатывать сертификаты меньшими частями, а не загружать весь набор сразу в память. По умолчанию 1000 сертификатов, минимум 5 сертификатов на страницу. Чтобы вернуться к старому поведению, установите размер страницы в любое значение меньше нуля.

  • revocation_queue_safety_buffer (строка: "") - задает срок по истечении которого кросс-кластерные запросы отзыва будут удалены как истекшие. Это должно быть установлено достаточно высоко, чтобы, если кластер исчезнет на некоторое время, но затем вернется, любые запросы отзыва, которые он должен обработать, все еще будут там, но не слишком долго, чтобы заполнить хранилище слишком большим количеством недействительных запросов. По умолчанию 48h. * tidy_acme (bool: false) - установите в true, чтобы очистить устаревшие аккаунты ACME, заказы, авторизации, EAB и вызовы. Заказы ACME очищаются (удаляются) safety_buffer после того, как сертификат, связанный с ними, истечет, или после того, как заказ и соответствующие авторизации истекут, если сертификат не был выдан. Авторизации очищаются вместе с соответствующим заказом.

    Когда действительный аккаунт ACME старше, чем acme_account_safety_buffer и не имеет связанных заказов, этот аккаунт будет помечен как отозванный. После завершения еще одного периода acme_account_safety_buffer с момента даты отзыва или деактивации, отозванный или деактивированный аккаунт ACME будет удален.

  • acme_account_safety_buffer (строка: "720h") - время, которое должно пройти после создания аккаунта, пока он не будет помечен как отозванный, и период времени после того, как аккаунт будет помечен как отозванный или деактивированный. По умолчанию 30 дней в часах.

Пример тела запроса:
{
  "safety_buffer": "24h"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/tidy

7.24. Чтение конфигурации автоматического удаления лишнего

Эта конечная точка извлекает текущую конфигурацию автоматического удаления лишнего.

Это сочетание периодических параметров вызова, описанных в нижеследующей обработке записи и параметров очистки описанных выше в конечной точке очистки.

Метод Путь

GET

/pki/config/auto-tidy
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/pki/config/auto-tidy
Пример ответа:
{
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "enabled": false,
    "interval_duration": 43200,
    "issuer_safety_buffer": 31536000,
    "maintain_stored_certificate_counts": false,
    "pause_duration": "0s",
    "page_size": 50,
    "publish_stored_certificate_count_metrics": false,
    "revocation_queue_safety_buffer": 172800,
    "safety_buffer": 259200,
    "tidy_cert_store": false,
    "tidy_cross_cluster_revoked_certs": false,
    "tidy_expired_issuers": false,
    "tidy_move_legacy_ca_bundle": false,
    "tidy_revocation_queue": false,
    "tidy_revoked_cert_issuer_associations": false,
    "tidy_revoked_certs": false,
    "tidy_invalid_certs": false
  },
  "auth": null
}

7.25. Установить конфигурацию автоматического удаления лишнего

Эта конечная точка позволяет конфигурировать периодические операции удаления лишнего, используя механизм удаления выше. Статус автоматически выполненных удалений по-прежнему сообщается на конечной точке статуса, описанной ниже.

Метод Путь

POST

/pki/config/auto-tidy

7.25.1. Параметры

Нижеуказанные параметры добавляются к основным параметрам, принятым конечной точкой /pki/tidy, описанными выше.

  • enabled (bool: false) - указывает, включено ли автоматическое очищение.

  • interval_duration (строка: "") - указывает продолжительность между автоматическими удалениями; Обратите внимание, что это время от конца одной операции до начала следующей, поэтому время самой операции не нужно учитывать. По умолчанию 12 часов.

  • maintain_stored_certificate_counts (bool: false) - когда включен, поддерживает дорогие подсчёты сертификатов. Во время инициализации монтирования выполняется LIST всех сертификатов для получения базовой величины и в ходе операций, таких как выдача, отзыв и последующие очищения, величина обновляется.

Настоятельно рекомендуется не включать это значение при хранении 50 тыс. или более сертификатов в монтировании или если в этом кластере используется много монтирований PKI. Вместо этого используйте логи аудита и собирайте эти данные внешне для StarVault, чтобы не повлиять на производительность StarVault.

  • publish_stored_certificate_count_metrics (bool: false) - когда включено, публикует значение, рассчитанное по maintain_stored_certificate_counts в метриках монтирования. Это требует, чтобы первое было включено.

Пример тела запроса:
{
  "enabled": true,
  "tidy_revoked_cert_issuer_associations": true,
  "safety_buffer": "24h"
}
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data @payload.json \
    http://127.0.0.1:8200/v1/pki/config/auto-tidy

7.26. Статус упорядочивания

Это конечная точка только для чтения, которая возвращает информацию о текущей операции уборки или о последней, если в данный момент нет запущенных операций.

Результат включает в себя следующие поля:

  • safety_buffer: значение этого параметра при инициировании операции уборки;

  • revoked_safety_buffer: рассчитанное значение этого параметра при инициировании операции уборки;

  • tidy_cert_store: значение этого параметра при инициировании операции уборки;

  • tidy_revoked_certs: значение этого параметра при инициировании операции уборки;

  • tidy_invalid_certs: значение этого параметра при инициировании операции уборки;

  • state: одно из Inactive, Running, Finished, Error, Cancelling, или Cancelled;

  • error: сообщение об ошибке, если возникла ошибка во время операции;

  • time_started: время начала операции;

  • time_finished: время окончания операции;

  • message: Одно из Tidying certificate store: checking entry N of TOTAL или Tidying revoked certificates: checking certificate N of TOTAL;

  • cert_store_deleted_count: количество удалённых записей в хранилище сертификатов;

  • revoked_cert_deleted_count: количество удалённых отозванных сертификатов;

  • missing_issuer_cert_count: количество отозванных сертификатов, которые не имели действительной ссылки на эмитента;

  • tidy_expired_issuers: значение этого параметра при инициировании операции уборки;

  • issuer_safety_buffer: значение этого параметра при инициировании операции уборки;

  • tidy_move_legacy_ca_bundle: значение этого параметра при инициировании операции уборки;

  • tidy_revocation_queue: значение этого параметра при инициировании операции уборки;

  • revocation_queue_deleted_count: количество удалённых записей в очереди отзыва;

  • tidy_cross_cluster_revoked_certs: значение этого параметра при инициировании операции уборки;

  • cross_revoked_cert_deleted_count: количество удалённых отозванных сертификатов из других кластеров;

  • revocation_queue_safety_buffer: значение этого параметра при инициировании операции уборки;

  • pause_duration: значение этого параметра при инициировании операции уборки;

  • page_size: значение этого параметра при инициировании операции уборки;

  • last_auto_tidy_finished: время, когда завершилась последняя авто-уборка; может отличаться от time_finished, особенно если последней операцией была вручную выполненная операция уборки.

Метод Путь

GET

/pki/tidy-status
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request GET \
    http://127.0.0.1:8200/v1/pki/tidy-status
Пример ответа:
  "data": {
    "safety_buffer": 60,
    "tidy_cert_store": true,
    "tidy_revoked_certs": true,
    "error": null,
    "message": "Tidying certificate store: checking entry 234 of 488",
    "revoked_cert_deleted_count": 0,
    "cert_store_deleted_count": 2,
    "state": "Running",
    "time_started": "2025-08-03T14:52:13.510161-04:00",
    "time_finished": null
  },

7.27. Отмена упорядочивания

Эта конечная точка позволяет отменить текущую операцию уборки. Она не принимает параметров и отменяет уборку на следующей доступной контрольной точке, что может обрабатывать дополнительные сертификаты между временем, когда операция была отмечена как отмененная, и временем, когда операция остановилась.

Ответ на эту конечную точку аналогичен статусу.

Метод Путь

POST

/pki/tidy-cancel
Пример запроса:
$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    http://127.0.0.1:8200/v1/pki/tidy-cancel
Пример ответа:
  "data": {
    "safety_buffer": 60,
    "tidy_cert_store": true,
    "tidy_revoked_certs": true,
    "error": null,
    "message": "Tidying certificate store: checking entry 234 of 488",
    "revoked_cert_deleted_count": 0,
    "cert_store_deleted_count": 2,
    "state": "Cancelling",
    "time_started": "2025-08-03T14:52:13.510161-04:00",
    "time_finished": null
  },

8. Масштабируемость кластера

Смотрите масштабируемость кластера PKI на странице со соображениями.

9. StarVault CLI с ответами DER/PEM

CLI StarVault может отображать только ответы JSON. Для API, которые возвращают данные в формате, отличном от JSON, такие как DER и PEM, starvault read завершится неудачей без параметра -format=raw. Следует использовать другой клиент, такой как curl