TLS certificate concepts and operations
Information about internal API Connect certificates, renewing expired certificates, exporting certificates, and other certificate maintenance operations.
This topic covers advanced certificate configuration procedures that are not required in day-to-day API Connect operations. For best practices relating to API Connect certificates, see API Connect TLS certificate best practices.
API Connect certificate types
All TLS certificates that are generated and used by API Connect fall into one of the
following categories:
- CA certificates - API Connect creates self-signed CA
certificates to sign all the API Connect end-entity
certificates. The CA certificates are:
ingress-ca
- used by the ingress-issuer. The ingress-ca signs all user-facing and inter-subsystem certificates.root-ca
- a self-signed root certificate that signs theingress-ca
certificate.management-ca
- signs all the management intra-subsystem certificates.portal-ca
- signs all the portal intra-subsystem certificates.analytics-ca
- signs all the analytics intra-subsystem certificates.
Do not customize CA certificates. The only scenarios when CA certificates require updating are:- Expiry, after 10 years.
- Synchronizing the
ingress-ca
certificate between data centers in multiple data center deployments.
- Ingress certificates - Ingress certificates are end-entity certificates that
are signed by the
ingress-ca
certificate and secure the API Connect endpoints. Ingress certificates are divided into two types:- Inter-subsystem certificates - certificates that are used to secure the communication between
API Connect subsystems, for
example between the management subsystem and gateway. By default, communication between most
subsystems uses mTLS. It is possible to use JWT instead of mTLS: Using JWT
instead of mTLS on OVA.
Do not customize inter-subsystem certificates.
- User-facing certificates - certificates that API Connect users see when they
interact with the API Connect UIs and REST API.
You can customize your user-facing certificates: Customizing your user-facing certificates
- Inter-subsystem certificates - certificates that are used to secure the communication between
API Connect subsystems, for
example between the management subsystem and gateway. By default, communication between most
subsystems uses mTLS. It is possible to use JWT instead of mTLS: Using JWT
instead of mTLS on OVA.
- Intra-subsystem certificates - certificates that are used between software
components in the same subsystem. Intra-subsystem certificates are signed by a subsystem specific CA
certificate:
management-ca
,portal-ca
,analytics-ca
. The gateway subsystem is a single pod, and has no intra-subsystem certificates.Do not customize intra-subsystem certificates.
Note: The inter and intra-subsystem certificates use of a self-signed root CA presents no security
risk. For internal communications with a limited number of predefined endpoints, use of locally
generated self-signed CA certificates can be more secure than external CA certificates, as
certificates are only ever issued for the known components and the domain of trust is kept as small
as possible.