#### **Certificate Generation Reworked for Multi-Instance Deployments (Common Vault)**
The certificate generation and storage flow has been updated to support **multiple CAPIF instances sharing the same Vault**.
Previously, the startup and certificate provisioning logic assumed a single CAPIF instance and stored certificates from fixed Vault paths, which caused collisions when deploying more than one instance using a common Vault.
With this change:
- Certificates and keys are now **generated at the service level** (e.g., NGINX generates it's own key and CSR locally).
- Vault is now used only as a **signing authority (CA)** to sign incoming CSRs and to store the resulting artifacts, avoiding Vault-specific instance coupling and enabling the same Vault to serve other CAPIF deployments.
- A **unique CCF identifier (ccf_id)** is used as the namespace key to store and retrieve CAPIF certificates.
- CAPIF-related certificates are stored under instance-scoped Vault paths (e.g. `secret/capif/<ccf_id>/...`) to prevent overwriting assets across deployments.
- Startup scripts and tooling were updated to obtain and use the correct `ccf_id` dynamically, ensuring each instance loads the correct certificate material.
#### **NGINX Configuration improved**
The NGINX configuration included in the OpenCAPIF deployment has been improved.
