Certificate mechanics

1. Introduction

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

• Accepted certificate types.

• Required domains according to the deployment model.

• Customer responsibilities.

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

• Secure delivery and installation procedures.

2. Key concepts

• CA (Certificate Authority): An entity that issues and signs digital certificates by verifying the applicant's identity.

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

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

• Wildcard certificate: A certificate covering a set of subdomains under the same main domain (for example, *.environment.anjanadata.net).

• Truststore / Keystore: A trust store containing trusted CAs. Certificate issuers are validated against this list of CAs.

• Full chain: The certificate for the final domain(s) plus intermediate certificates. The complete certificate chain from the certificate issued for the domain to the certificate authority's root certificate.

3. Deployment models

3.1. On-Premises, IaaS, PaaS

The customer has the entire Anjana Data Platform installed in its infrastructure, including:

• Core

• Microservices

• Plugin Machine

3.2. Hybrid SaaS

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

3.3. Full SaaS

The Anjana Data Platform is fully installed in Anjana Data SL's infrastructure, and Anjana Data SL manages all certificates, domains, and their lifecycle.
The certificates are signed under the corporate domain anjanadata.net.

4. Domain and certificate requirements by model

4.1. On-Premises, IaaS and PaaS

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

Example:

4.2. Hybrid SaaS

The customer is solely responsible for the Plugin Machine deployed on-premises, in IaaS, or in PaaS. One (1) wildcard certificate is required for each environment enabled for this component.

Example:

5. Wildcard certificate limitations and requirements

5.1. Clarification: wildcard certificate requirement

Anjana Data SL does not manage certificates signed by unrecognised entities by default. It uses wildcard certificates (*.customer-domain.com), but not a certificate for the root domain (*.customer.com). We follow this policy.

• Anjana Data Platform architecture: The platform is based on microservices, with each service exposed through its own subdomain (e.g. kerno1server.anjana.customer.com, horus1server.anjana.customer.com, …).

• Root certificate limitation: A wildcard certificate issued only for the root domain (e.g. *.customer.com) does not cover subdomains hosted under the Anjana Data Platform domain.

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

5.2. Private-key exposure risk

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

• Impersonate any customer subdomain.

• Set up fake servers (login.customer.com, api.customer.com…) without detection.

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

5.3. Violation of separation-of-duties principles

Providing root corporate certificates to a provider:

• Transfers part of the organisation's digital identity.

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

• Would technically allow traffic outside the project scope to be intercepted, decrypted, or altered.

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

5.4. Compliance and auditing

Issuing root-domain wildcards typically constitutes:

• A serious security non-conformity in audits such as ISO 27001 or SOC 2, unless a specific contractual agreement justifies 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 recognised public certificate authority; otherwise, trust and interconnection problems may occur. Examples of public CAs include:

• Let's Encrypt

• Microsoft

• Google

• Amazon

• DigiCert

• GlobalSign

• Others…

6.2. Specifications and naming

To standardise deployment and avoid confusion, the customer must generate and provide the two certificate files (for each environment) using the exact names specified below:

• anjana-fullchain.pem

  • Contents: The full-chain certificate. This file must contain the server certificate (for *.domain.com) concatenated with all intermediate certificates from the Certificate Authority (CA).

• anjana-privkey.pem

  • Contents: The private key.

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

6.3. Customer responsibilities

For deployment models in which the customer has an Anjana Data Platform service deployed in its infrastructure (On-Premises, IaaS, PaaS, or Hybrid SaaS), the customer is responsible for:

• Managing the lifecycle of certificates associated with components deployed in its infrastructure.

• Securely storing certificates associated with components deployed in its infrastructure.

• Integrating certificates into the different platform components deployed in its infrastructure in accordance with the official documentation.

6.4. Additional considerations

• Certificates must use strong encryption (at least RSA 2048 or equivalent ECC).

• It is recommended to configure alerts or automations to anticipate certificate expiry.

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

• For the On-Premises/IaaS/PaaS/Hybrid SaaS model, Anjana Data SL does not provide support for specific certificate-lifecycle-management tools, but may provide recommendations.

7. Recommendations and considerations for customer certificate management

Proper digital certificate management is essential to ensure the security, integrity, and reliability of communications between the different Anjana Data Platform components and the customer's systems. The choice of certificate type, together with its lifecycle and the way it is distributed and maintained, directly affects the integration experience, risk exposure, and compliance with security regulations.

This section presents recommendations and good practices to support decisions regarding the use of self-signed certificates or certificates issued by public Certificate Authorities (CAs). It also describes the scenarios in which each option may be appropriate, the requirements associated with deployment and maintenance, and the operational, technical, and security implications the customer must consider.

The objective is to provide clear guidance for selecting the most appropriate certificate type for each environment (development, testing, pre-production, or production), reducing the operational burden for both customer and provider while increasing connection robustness and reliability.

7.1. Comparison

7.2. Use cases

In some specific use cases, self-signed certificates may be permitted or their use may 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 or connected to external infrastructure.

• Environments covered by an application load balancer that manages certificates (e.g. AWS ALB). The machine's internal certificate never establishes communication because the load balancer, operating at the application layer (layer 7 of the OSI model), responds using its own certificate, normally from a recognised public CA.

• Environments covered by a proxy that manages certificates in some way.

❌ When NOT to use self-signed certificates:

• Publicly accessible pre-production or production environments.

• Third-party integrations.

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

8. Delivery and security procedure (On-Premises, IaaS, PaaS, and Hybrid SaaS)

For all models that include infrastructure owned and therefore managed by the customer:

• Responsibility: The customer is responsible for generating and placing the two files (anjana-fullchain.pem and anjana-privkey.pem) in the following designated path on the relevant servers:
  Destination path: /opt/common/anjana-certs/

• Security policy: Anjana Data SL's Operations team must not receive, handle, or transport certificates (especially private keys) through insecure channels such as email, chat, or ticketing systems.