Certificate Mechanics

1. Introduction

This document defines the domain and SSL/TLS certificate requirements needed to deploy the Anjana Data platform in different deployment models (Full SaaS, Hybrid SaaS, On-Premise or IaaS/PaaS), including:

• Accepted certificate types.

• Required domains according to the deployment model.

• Client responsibilities.

• Minimum technical standards (CA, keys, formats).

• Secure delivery and installation procedure.

2. Key concepts

• CA (Certificate Authority): Entity that issues and signs digital certificates by verifying the identity of the requester.

• CSR (Certificate Signing Request): Signing request containing the public key and domain information to be certified.

• Self-signed certificate: Certificate signed by its own issuer, not verified by a public CA.

• Wildcard certificate: Certificate that covers a set of subdomains under the same main domain (for example, *.entorno.anjanadata.net).

• Truststore / Keystore: Trust store where trusted CAs are kept. Certificate issuers are validated against this list of CAs.

• Fullchain: certificate of the final domain(s) + intermediate certificates. The entire certificate chain from the certificate belonging to the issued domain up to the root certificate of the certification authority.

3. Deployment models

3.1. On-Premise, IaaS, PaaS

The client has the entire Anjana Data platform installed in their infrastructure, including:

• Core

• Microservices

• Plugins Machine

3.2. Hybrid SaaS

The Core and microservices run in Anjana Data SL's SaaS, which is responsible for fully managing the certificates and domains (as well as their lifecycle) exclusively for its infrastructure.
The client has installed in their infrastructure only the Plugins Machine. The client is responsible for fully managing the certificates and domains associated with the machine (as well as their lifecycle).

3.3. Full SaaS

Anjana Data Platform is entirely installed in Anjana Data SL's infrastructure, and it is Anjana Data SL that fully manages the certificates, domains, and lifecycle.
Certificates are signed under the corporate domain anjanadata.net.

4. Domain and certificate requirements per model

4.1. On-Premise, IaaS and PaaS

For this type of deployment, one (1) wildcard certificate is required per enabled environment for the unified base domain.

Example:

4.2. Hybrid SaaS

The client is solely responsible for the Plugins Machine On-Premise, IaaS or PaaS. One (1) wildcard certificate is required per enabled environment for this component.

Example:

5. Wildcard certificate limitation and requirement

5.1. Clarification: Wildcard certificate requirement

Anjana Data SL does not manage by default certificates signed by unrecognized entities; wildcard (*.dominio.cliente.com) type certificates are used, but not a certificate for the root domain (*.cliente.com). We are based on the following policy.

• Anjana Data Platform Architecture: The platform is based on microservices, where each service is exposed in its own subdomain (e.g. kerno1server.anjana.cliente.com, horus1server.anjana.cliente.com, …).

• Root Certificate Limitation: A wildcard certificate issued only for the root domain (e.g. *.cliente.com) does not cover the subdomains mounted on the Anjana Data Platform domain.

• Wildcard Function: A standard wildcard certificate (e.g. *.anjana.cliente.com) is designed to cover a single level of subdomains, which is exactly the architecture used by Anjana Data Platform.

5.2. Risk of private key exposure

Delivering the pair (.crt + .key) of a root wildcard such as *.cliente.com implies that anyone with access to the private key could:

• Impersonate any subdomain of the client.

• Set up rogue servers (login.cliente.com, api.cliente.com…) without detection.

• Carry out Man-in-the-Middle attacks and phishing indistinguishable from the originals.

5.3. Violation of separation of responsibilities principles

Handing root corporate certificates to a provider:

• Cedes part of the organization's digital identity.

• Breaks the principle of role separation and security by design.

• Would technically allow intercepting, decrypting, or altering traffic outside the scope of the project.

Therefore, Anjana Data SL only accepts certificates whose scope is exclusively the environment intended for deployment.

5.4. Compliance and audit

Transferring root domain wildcards typically constitutes:

• A serious security non-conformity in audits such as ISO 27001 or SOC2 unless there is a specific contractual agreement justifying it.

• A breach of key management controls.

• A violation of the Least Privilege and Controlled Key Material principles.

6. Acceptance criteria

6.1. Recommended Public CAs

Certificates must be issued by a recognized public certification authority; otherwise, trust and interconnection issues may occur. Some examples of public CAs are:

• Let's Encrypt

• Microsoft

• Google

• Amazon

• DigiCert

• GlobalSign

• Others…

6.2. Specifications and Naming Convention

To standardize deployment and avoid confusion, the client must generate and provide the two certificate files (per environment) with the exact names specified below:

• anjana-fullchain.pem

  • Content: The Full Chain Certificate (Fullchain). This file must contain the server certificate (for *.dominio.com) concatenated with all intermediate certificates of the Certification Authority (CA).

• anjana-privkey.pem

  • Content: The Private Key.

  • Format: Must be PEM (RSA 2048-bit or higher) and must not be password-protected.

6.3. Client responsibilities

In modalities where the client has deployed any Anjana Data Platform service in their infrastructure (OnPremise, IaaS, PaaS, or Hybrid SaaS), it will be the client's responsibility to:

• Manage the lifecycle of the certificates associated with the components deployed in their infrastructure.

• Securely store the certificates associated with the components deployed in their infrastructure.

• Integrate the certificates into the various platform components deployed in their infrastructure in accordance with the official documentation.

6.4. Additional considerations

• Certificates must have a robust encryption level (minimum RSA 2048 or equivalent ECC).

• It is recommended to configure alerts or automation that allows anticipating certificate expiration.

• If a reverse proxy is used (such as NGINX or Apache), it must be ensured that it is correctly configured to serve the certificate and allow proper TLS validation.

• In the OPrem/IaaS/PaaS/Hybrid SaaS model, Anjana Data SL does not provide support for specific certificate lifecycle management tools, but can offer recommendations.

7. Recommendations and considerations for certificate management by the client

The correct management of digital certificates is a key element to ensure the security, integrity, and reliability of communications between the various components of the Anjana Data platform and the client's systems. The choice of certificate type, as well as its lifecycle and the way it is distributed and maintained, has a direct impact on the integration experience, risk exposure, and compliance with security regulations.

This section presents a series of recommendations and best practices aimed at facilitating decision-making regarding the use of self-signed certificates or certificates issued by public Certification Authorities (CA). Additionally, the scenarios in which each option may be appropriate are detailed, along with the requirements associated with their deployment and maintenance, and the operational, technical, and security implications that must be considered by the client.

The objective is to provide a clear guide that allows selecting the most appropriate certificate type for each environment (development, testing, pre-production, or production), minimizing the operational burden for both the client and the provider, and increasing the robustness and reliability of connections.

7.1. Comparison

7.2. Use cases

In some cases, in more specific use cases, self-signed certificates will be allowed or their use will not be discouraged.

✅ When to use self-signed certificates:

• Corporate internal network: when all environments share a corporate certificate or trust the same CA. These environments are normally NOT externally accessible nor connected to external infrastructure.

• Environments covered by an application load balancer that manages certificates (e.g.: AWS ALB). The machine's internal certificate does not establish communication at any point, since the load balancer, which acts at the application layer (7 of the OSI model), is responsible for responding using its own certificate, normally from a recognized public CA.

• Environments covered by a proxy where certificates are being managed in some way.

❌ When NOT to use self-signed certificates:

• Pre-production or production environments publicly accessible.

• Third-party integrations.

• Environments covered by a network load balancer (e.g.: AWS NLB). Network load balancers operate at the transport layer (4 of the OSI model), which means they work with TCP and UDP protocols, and therefore do not manage certificates.

8. Delivery and Security Procedure (On-Premise, IaaS, PaaS and Hybrid SaaS)

For all modalities that include infrastructure owned by the client and, therefore, managed by the client:

• Responsibility: The client is responsible for generating and placing the two files (anjana-fullchain.pem and anjana-privkey.pem) at the following designated path within the corresponding servers:

  Destination path: /opt/common/anjana-certs/

• Security Policy: The Anjana Data SL Operations team must not receive, handle, or transport certificates (especially private keys) through insecure channels such as email, chat, or ticket management systems.