Отлично, тогда делаем новый **stage CSR** так, чтобы приватный ключ остался в Vault.

```bash
export VAULT_ADDR="https://pki.lmru.tech"
export VAULT_TOKEN="<токен с правами на pki-stage/intermediate/generate/internal>"

vault write -format=json pki-stage/intermediate/generate/internal \
  common_name="LMRU PKI Stage Intermediate CA" \
  key_type="rsa" \
  key_bits=4096 \
  ou="DevSecOps" \
  organization="LE MONLID LLC" \
  country="RU" \
  locality="Mytishchi" \
  province="Moscow Oblast" \
  | jq -r '.data.csr' > stage-new.csr
```

Проверка CSR:

```bash
openssl req -in stage-new.csr -noout -text | rg "Subject:|CA:TRUE|Key Usage|Public-Key"
```

Это и отправляешь ITOP на подпись.

---

Если им **обязательно нужен SAN** (как раньше говорили), сгенерируй еще раз с `alt_names`:

```bash
vault write -format=json pki-stage/intermediate/generate/internal \
  common_name="LMRU PKI Stage Intermediate CA" \
  alt_names="pki.lmru.tech" \
  key_type="rsa" \
  key_bits=4096 \
  | jq -r '.data.csr' > stage-new.csr
```

---

Текст для Александра/Антона можно дать такой:

> Новый CSR для stage сформирован на нашей стороне в Vault, приватный ключ остаётся в Vault.
> Направляю `stage-new.csr` для подписи intermediate CA на вашей стороне.

Если хочешь, дам сразу и команды импорта подписанного cert обратно в `pki-stage` после того как они вернут `crt/chain`.

**Generating CSR steps**

I need to respond with actionable steps to generate a CSR for the Vault stage while ensuring the key is preserved in Vault. The user wants to generate a new CSR, so I should provide commands, possibly running a tool or checking documentation for existing commands.

I can offer exact command sets and message texts, noting any SAN requirements for ADCS. When generating a CSR, important fields include common_name, organization, and possibly subject alt names, depending on requirements.
**Clarifying CSR generation details**

I’m considering whether SAN is required for CA. It seems alt_names might be allowed when generating CSR internal parameters. I remember that the parameters for pki/intermediate/generate/internal include common_name, key_type, and more. If they need alt_names, I can include them.

I'll provide both CLI and API instructions and possibly create a script file; they likely just want to generate it. I should offer concise instructions, including commands for "regenerate and save," and clarify the optional SAN. Let’s proactively prepare ready commands!
**Crafting commands for CSR generation**

I’m thinking about using shell commands if the Vault CLI is available, but that could be risky without credentials. Instead, it’s probably safer to provide a clear command for generating the CSR. I want to keep it minimal to avoid confusion. Let’s ensure that the users have straightforward instructions to follow. It’s essential to make this easy and manageable for them to execute without any hitches!


<timestamp>Wednesday, May 27, 2026, 2:20 PM (UTC+3)</timestamp>
<user_query>
@/home/ruslanpi/.cursor/projects/home-ruslanpi-Documents-repos-lmru-devops-core-ansible-vault-oss/terminals/1.txt:239-253
</user_query>


Отлично, всё получилось корректно.

По выводу видно:
- CSR создан;
- `Subject` заполнен как нужно;
- ключ `4096 bit`;
- приватный ключ остался в Vault (ты его не выгружал).

Дальше отправляй `stage-new.csr` в ITOP на подпись.

Короткий текст им:
> Сформировали новый CSR для stage.
> Просьба подписать intermediate по этому CSR (private key остаётся у нас в Vault).
> Верните, пожалуйста, `crt + chain` (без private key).

После получения от них могу сразу дать точные команды импорта в `pki-stage` и проверки issuer/chain.

**Acknowledging CSR validation**

I need to respond to the user, who seems to be asking for confirmation of the output snippet. I should acknowledge that the generated CSR is good and outline the next steps. I might want to mention sending the CSR, possibly referring to the SAN/template OID, and check that everything is in order. No tool is needed for this; I just want to keep my response concise and clear.


<timestamp>Wednesday, May 27, 2026, 2:23 PM (UTC+3)</timestamp>
<user_query>
https://pki.lmru.tech/ а посмотри какие у самого поля
ou, organization, country, etc
</user_query>


Сейчас посмотрю сертификат самого `pki.lmru.tech` и вытащу поля `C/O/OU/CN` и SAN.

Shell

openssl s_client -connect pki.lmru.tech:443 -servername pki.lmru.tech </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates

Read TLS cert subject issuer and validity

openssl s_client -connect pki.lmru.tech:443 -servername pki.lmru.tech </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Read TLS cert SAN extension


У `https://pki.lmru.tech` сейчас в TLS-сертификате такие поля:

- `C = RU`
- `ST = Moscow Oblast`
- `L = Mytishchi`
- `O = LE MONLID LLC`
- `OU` — **нет**
- `CN = *.lmru.tech`
- `SAN = *.lmru.tech, lmru.tech`

Дополнительно:
- `Issuer = GlobalSign RSA OV SSL CA 2018` (GlobalSign)
- Срок: `2025-09-08` → `2026-10-10`

Это именно внешний TLS-сертификат хоста/балансировщика, не intermediate из `pki-stage`.

**Clarifying certification details**

I need to respond concisely, mentioning that this is an LB cert and not a Vault intermediate. I should clarify that the Organizational Unit (OU) is absent. The user asked specifically about fields, so I want to address that directly. Also, I'll ensure to respond in Russian as requested. It’s important to keep everything clear and straightforward for the user!