AAI Glossary — Terms Used in the 26.0.0 Upgrade Documentation

Products

• Automation Analytics & Intelligence

Issue/Introduction

This glossary defines security, certificate, and deployment terms that appear repeatedly across the AAI 26.0.0 upgrade documentation, for readers without a security/PKI or Kubernetes background.
Each related article links here and gives a short inline explanation the first time it uses one of these terms — use this page for the fuller picture, or if you've landed here mid-article without the earlier context.

Environment

• Applies to AAI 26.0.0, across both VM/traditional-installer and Kubernetes/OpenShift deployments
  — most terms below are used in both environments;
  a few (Pod, StatefulSet, Route/Ingress, Helm chart, PVC, Helm hook) are Kubernetes/OpenShift-specific and are noted as such.

Cause

Not applicable. This is a reference glossary, not a resolution to a specific reported problem.

Resolution

Security and certificate terms

TLS (Transport Layer Security) — the standard technology that encrypts a network connection so nobody in between can read or tamper with the traffic. "HTTPS" is TLS applied to a web connection. When these documents say "TLS," they mean this encryption layer.

mTLS (mutual TLS) — regular TLS only proves the server's identity to the client (this is how your browser knows a website is really who it claims to be). Mutual TLS goes one step further: both sides present a certificate, so the server also proves who the client is before accepting the connection. AAI uses mTLS internally so its own services can prove their identity to each other, not just to external users.

Certificate — a digital file that proves an identity (a server, a service, a person) and is used to set up an encrypted, verified connection. Every certificate is signed by something — either another certificate (see Certificate Authority, below) or, at the top of the chain, by itself.

PKI (Public Key Infrastructure) — the overall system of certificates, keys, and the authority that issues them, used to establish trust between two things talking to each other over a network. When these documents refer to "a PKI," they mean one complete, self-contained set of these pieces (as opposed to a completely separate one used for something else — AAI 26.0.0 actually has three independent PKIs).

CA (Certificate Authority) — a certificate that's allowed to sign other certificates, vouching for their identity. A "Root CA" is the top of the chain — it isn't signed by anything else; everything else in that PKI ultimately traces back to it. A certificate that is not a CA (see "Leaf certificate," below) cannot be used to sign anything else, even if it's otherwise perfectly valid.

Leaf certificate (also called "end-entity certificate") — an ordinary certificate that identifies one specific thing (a server, a service) and is not allowed to sign other certificates. Most commercially-purchased HTTPS certificates are leaf certificates. This distinction still matters in AAI 26.0.0: some certificate-related procedures require a genuine CA certificate specifically, and substituting a leaf certificate can appear to work at first before failing later — see the ports/HTTPS/certificates and connector-impact topics for where this applies.

Keystore — a file that holds a certificate and its matching private key, used by something to prove its own identity. AAI's keystores are .p12 (PKCS12) files.

Truststore — a file that holds only public certificates (no private keys), used by something to verify other parties' identities. If a keystore is "who I am," a truststore is "who I trust."

PKCS12 (.p12) — the standard file format AAI uses for both keystores and truststores. It's always password-protected, even when it only contains public certificates and no private key.

Private key / public key — every certificate has a matching pair: a private key (kept secret, never shared) that proves ownership, and a public key (shared freely, embedded in the certificate itself) that lets others verify things signed with the private key. If a file described as a "keystore" or "CA" doesn't contain the private key, it can't be used to prove identity or sign anything — it's only useful for verification.

EC P-256 (elliptic curve, "P-256" curve) — the specific type and strength of cryptographic key AAI's internal certificates use. You don't need the math — the practical point of naming it in these documents is just to confirm which key type is in use, since a mismatched key type is a real (if less common) source of certificate errors.

SAN (Subject Alternative Name) — the list of hostnames and/or IP addresses a certificate is valid for. Modern software (browsers, Java) requires the exact address you're connecting to be listed in the certificate's SANs, or the connection is rejected — even if the certificate is otherwise perfectly valid and correctly signed.

CN (Common Name) — the primary name field on a certificate, identifying who or what it belongs to. In AAI's internal mTLS logs, the CN in a rejected-handshake message tells you which service was trying (or was expected) to connect.

JWT (JSON Web Token) — a signed, compact text token used to prove "I already authenticated, here's proof" without re-checking credentials on every request. AAI's Frontend Gateway issues JWTs internally after a user logs in once.

ES256 — the specific signing algorithm AAI uses for its internal JWTs (JSON Web Tokens) — an EC P-256 key, used to sign rather than encrypt.

Deployment and architecture terms

JBoss — the underlying Java application server AAI's main application runs inside, on a VM/traditional-installer deployment. Older AAI configuration lived inside JBoss's own configuration format.

WAR (Web Application Archive) — a packaged Java web application. Several AAI services (Reports, Simulation, Subscription, Collector, Alert, Telemetry, the Custom Condition Generator) run as WARs inside the same JBoss process as the main AAI Server, rather than as their own separate services — which is why they don't show up as their own pods on Kubernetes/OpenShift.

Pod — the basic running unit in Kubernetes/OpenShift — roughly, one instance of one service, with its own container(s), network address, and log stream.

StatefulSet — a Kubernetes/OpenShift mechanism for running a component (like AAI's search/indexing engine, OpenSearch) that needs stable identity and storage across restarts, unlike a typical stateless pod.

Route / Ingress — the Kubernetes/OpenShift mechanisms that let traffic from outside the cluster reach a service running inside it. "Route" is OpenShift's term; "Ingress" is the equivalent for plain Kubernetes. Whether these terminate (decrypt) HTTPS traffic themselves, or simply forward it on, is a major factor in several AAI 26.0.0 certificate behaviors.

Helm chart — the packaged set of Kubernetes/OpenShift deployment instructions AAI ships, installed and upgraded with the helm command-line tool.

PVC (Persistent Volume Claim) — a Kubernetes/OpenShift request for a piece of storage that survives pod restarts, independent of any single pod's lifecycle. Several AAI components share a PVC-backed storage volume for logs or configuration, which is why files there can persist across a pod restart even though the pod itself is a fresh instance.

Helm hook (pre-install/pre-upgrade Job) — a one-off task Helm runs automatically as part of an install or upgrade, before the main components start — AAI uses one of these to generate internal certificates on Kubernetes/OpenShift.

ServerParameter — AAI's own internal mechanism for a configurable setting stored in its database and readable/settable over its own API, as opposed to an environment variable or a line in a configuration file. Several behavior changes in 26.0.0 are controlled this way.

Frontend Gateway (FEG) — the new component in 26.0.0 that sits in front of AAI and is what browsers, integrations, and connectors actually talk to.

DTO (Data Transfer Object) — an object that already holds a chunk of data in memory, used to pass that data around without an extra database round-trip. When these documents say something is "read from the DTO," it means the value was already available in memory rather than requiring a fresh lookup.

OOMKilled — a Kubernetes/OpenShift term for a pod that was forcibly terminated by the underlying system for using more memory than its configured limit allows ("OOM" = out of memory). This kill happens from outside the application, so the application's own log usually shows nothing unusual — the process didn't get a chance to log anything before it was stopped.

Appender — a logging-framework term for the piece of configuration that decides where a logger's output actually goes (which file, or the console). When these documents say a logger "isn't routed to an appender," it means nothing is configured to write that logger's output anywhere — so no file for it will ever appear, regardless of system health.

CSRF (Cross-Site Request Forgery) — a web-security attack where a malicious site tricks a user's browser into making an unwanted request to a different site the user is logged into. "CSRF protection" is a defense against this. When these documents note that a component has CSRF protection disabled, it means that specific defense isn't active on that component — relevant context when reasoning about what a component's security configuration does and doesn't cover.

Additional Information

To speak with a customer representative or a Support Engineer see Contact Support. Scroll to the bottom of the page and click on the respective region.