Service Identity Provider TLS

Interwork Description
• Introduction
• Migration From Server and Client Certificate API
• Certificate renewal details and examples
◦ Calculating the TTL
◦ Calculating the renewaltime
• Internal Certificate API (new, recommended)
◦ API Description
◦ Custom Resource Definition
• Server and Client Certificate APIs (old, to be deprecated and removed)
◦ Server Certificate API Description (old, soon-to-be-deprecated)
◦ Client Certificate API Description (old, soon-to-be-deprecated)
• Note about Dependencies
• The CRD and SIP-TLS API Versioning
• Version History
◦ Version 1.0.0
◦ Version 0.3.0-alpha
◦ Version 0.2.0-alpha
◦ Version 0.1.0-alpha
• References

1. Introduction
The Service Identity Provider TLS (SIP-TLS) API is used for requesting and distributing
the certificates and keys that are needed for establishing a cluster internal TLS
connection between a Service Provider and a Service Consumer in a namespace.
Service Providers and Service Consumers act as SIP-TLS clients, whereas SIP-TLS
creates the certificate requests towards the CA on behalf of the clients.

The Key Management Service PKI Secret Engine is used for providing the actual
certificates and keys.

The SIP-TLS API information is conveyed by using the Kubernetes resource attributes,
namely Custom Resource Definition (CRD), Custom Resource (CR), Kubernetes Secrets
and volume mounts to the Kubernetes Secrets from Pod templates. SIP-TLS can only
provide certificates within the same namespace.

This document is divided into two main parts:

• The Internal Certificate API, which defines InternalCertificate and InternalUserCA

CRs.
• The Server and Client Certificate APIs (soon-to-be deprecated), that define
ServerCertificate, ClientCertificate and CertificateAuthority CRs.

The Internal Certificate API allows broader use cases that are not tied to the
traditional roles of "server" or "client". It is possible to request a certificate more
precisely according to the use case of the service. Any use case that is possible
by using the Server and Client Certificate API can also be realized by using
the Internal Certificate API. There are also no hard coupling between API users
and API versions, in other words, a service provider can use the Internal
Certificate API, while a service consumer uses the Server and Client
Certificate API (or vice versa). It is therefore strongly advised to take the new API
into use.
2. Migration From Server and Client Certificate
API
Services that have implemented the Server and/or Client Certificate API can
seamlessly convert to the Internal Certificate API since it is backwards compatible.
The transformation can be seen from the below tables. All parameters reside within
the YAML 'spec' object in the relevant Custom Resource template:

ServerCertificate & ClientCertificate

InternalCertificate (new)
(old)

generated-secret-name kubernetes.generatedSecretName

common-name certificate.subject.cn

additional-sans certificate.subjectAlternativeName.dns

override-ttl certificate.validity.overrideTtl

issuer-ref certificate.issuer.reference

CertificateAuthority (old) InternalUserCA (new)

generated-secret-name kubernetes.generatedSecretName

common-name certificate.subject.cn

Following values must be set to new API CRs in order to the transition to be seamless:

InternalCertificate (new) value(s)

for client side: clicert.pem

kubernetes.certificateName
for server side: srvcert.pem

for client side: cliprivkey.pem

kubernetes.privateKeyName
for server side: srvprivkey.pem

InternalUserCA (new) value

kubernetes.certificateName client-cacertbundle.pem

The other parameters that exist in InternalCertificate CR and InternalUserCA CR are

extra functionality that was not available in the old API.

Note: the default values for some of these parameters may be different than the
default values that were used in Server and Client Certificate API. For example, the
private key format has changed from 'pkcs1' to 'pkcs8'. Therefore, in order to get the
exact same certificate properties, check all the CR parameters carefully.

3. Certificate renewal details and examples

Note: in this renewaltime calculation description we use the overrideTtl and
overrideLeadtime CR-level parameters but those can only be used for
InternalCertificate type custom resources. For ClientCertificate and
Servercertificate type custom resources the overrideTtl parameter is called
override-ttl, while overrideLeadtime has no counterpart and should be taken
as "not set". Aside of this difference the renewal calculation algorithm is the
same.

The certificate renewal is done automatically by SIP-TLS using both system-wide

default parameters set by the operator during SIP-TLS installation (ending with
validLifetimeSeconds and renewalThresholdRatio), and also using optional custom-
resource (CR) level parameters (ending with overrideTtl and overrideLeadTime) set in
the CR that requests the certificate.

For renewal calculations SIP-TLS divides the certificate lifetime (TTL) into two
complementer parts, renewaltime and leadtime:

TTL = renewaltime + leadtime

When a certificate is being created by SIP-TLS, the TTL and renewaltime values for the
certificate are calculated. The calculated TTL value will be the lifetime of the
certificate. The calculated renewaltime will be used to start a timer to trigger the next
renewal of the certificate.

3.1. Calculating the TTL

The TTL of a certificate will be validLifetimeSeconds if overrideTtl is not set, and will
be overrideTtl if that is set in the CR. (See examples in the next table.)

3.2. Calculating the renewaltime

• if overrideTtl is not set and overrideLeadtime is not set (base case):

renewaltime = renewalThresholdRatio * validLifetimeSeconds

• if overrideTtl is set and overrideLeadtime is not set:

renewaltime = renewalThresholdRatio *
minimum(validLifetimeSeconds, overrideTtl)

Please note that even if overrideTtl is set in a CR to a higher value than

validLifetimeSeconds, for renewaltime calculations the minimum of the two values will
be used for the such configured certificates. The rationale behind this is to
continuously provision the certificates with the longer remaining lifetime and refresh
them at the same pace as the rest of the system.

• if overrideLeadtime is set (InternalCertificate only):

renewaltime = TTL - overrideLeadtime

Please note that both the calculated TTL and the overrideLeadtime are absolute
values.

The below table shows some example configurations and their effect on TTL and
renewaltime. (For easier comparison the internalCertificate.renewalThresholdRatio is
the default 0.9 for all examples.)

validLifeti renewalTh calculated

overrideTt overrideLe certificate
meSecond resholdRat renewal
l adtime TTL
s io time

604800 *
604800 0.9 - - 604800 0.9 =
544320

604800 *
604800 0.9 700000 - 700000 0.9 =
544320

700000 *
800000 0.9 700000 - 700000 0.9 =
630000

604800 -
604800 0.9 - 4800 604800 4800 =
600000
 validLifeti renewalTh calculated
overrideTt overrideLe certificate
meSecond resholdRat renewal
l adtime TTL
s io time

4800 - 800
604800 0.9 4800 800 4800
= 4000

4. Internal Certificate API (new, recommended)

This API combines and replaces Server and Client Certificate API.

The API can be used to enable certificate-based authentication and TLS encryption
between services within the same namespace in the cluster. Among the supported
use cases are server authentication, client authentication, mutual authentication and
peer-to-peer authentication.

Services that require identity by using certificates and private keys shall use the
InternalCertificate Custom Resource (CR).

Services that want to verify certificate identities can use either the common trusted
CA, or an exclusive CA via InternalUserCA CR. The decision between CAs depends on
the specific use case of the service.

4.1. API Description

The siptls.sec.ericsson.com InternalCertificate CR API provides means for service

providers and service consumers to request creation of a certificate and private key.
SIP-TLS provides the certificate material to the user-specified Kubernetes secret that
can be read by the service from a volume mount in a Pod or directly from the secret
via Kubernetes REST call. The files that are stored to the secret are always PEM
encoded.

Certificates are almost always issued per interface. The type of interface defines the
type of certificate needed. For example, a service provider that exposes an end point
via REST will (probably) need a certificate with SERVER_AUTH extended key usage
flag set for server authentication. Similarly, a service consumer that consumes a REST
end point will (probably) need a certificate with CLIENT_AUTH extended key usage
flag set for client authentication.

Certificates are issued by a CA (certificate authority). The type of CA that is used

when issuing and verifying certificates is decided by the requirements and capabilities
of the service. The CA can either be shared by services, or be exclusively created and
tied to a service provider's own API. SIP-TLS provides one shared CA, eric-sec-sip-tls
Internal Root CA, which can be used by anyone. By using siptls.sec.ericsson.com
InternalUserCA a service provider can also request the creation of their own, exclusive
CA. SIP-TLS stores the CA certificate to Kubernetes secret, similarly as end-user
certificates.

In general, there are two levels of certificate validation steps that can be made (that
will be mentioned here):

1. CA chain verification, i.e. checking that the certificate is signed by one of the CAs
in the PKI chain leading up to a trusted CA. Commonly, the trusted CA is a self-
signed CA.
2. Common name (CN), subject alt name (SAN), or custom validation, i.e. checking
that some attribute in the certificate matches some expected value.

For example, when doing server authentication the service consumer can validate
that the hostname that is used in the connection string matches with one of the SANs
in the certificate that the service provider supplies. In this case it would be adequate
that the certificate is signed by a sub-CA of the eric-sec-sip-tls Internal Root CA.

On the other hand, when doing client authentication there is also often the desire to
do some kind of authorization. For example, the service provider wants to restrict one
of its APIs so that only a service consumer that presents a certificate with a certain CN
can access it. In order to uniquely identify that identity, both CA chain verification and
CN validation must be used, together with an exclusive CA. If many service providers
would share a CA for this purpose, then the CNs may overlap and inadvertently give
access to service consumers that it did not originally intend to. Of course, this may
also be the desired outcome, i.e. giving all service consumers in the cluster
(namespace) the same level of permissions to that service provider.

4.2. Custom Resource Definition

Custom Resource Definition (CRD) is defined as a feature which enables users to

add their own/custom objects to the Kubernetes cluster and use it like any other
native Kubernetes objects. Definition, configuration and usage of the CRDs can be
found on Kubernetes site KubernetesCRD.

4.2.1. InternalCertificate Custom Resource

The InternalCertificate CR is used to communicate the certificate-related parameters

and the Kubernetes Secret name.

API Group/Version Kind

siptls.sec.ericsson.com/v1 InternalCertificate

The following parameters are supported (under YAML 'spec' section):

Parameter Type Explanation

The name of the secret

where the certificate and
key are stored. Note: the
same secret must not be
used for multiple
purposes. If the same
generatedSecretName is
kubernetes.generatedSecr
Mandatory; string. used more times, then the
etName
following printout will
appear in the log:
"Warning! Duplicated
generatedSecretName
was found!: <NAME-OF-
THE-DUPLICATED-
SECRET>"

The YAML key name of the

certificate in the secret. If
kubernetes.certificateNam not given, 'cert.pem' is
Optional; string.
e used in case of secretType
'generic'. For secretType
'tls', 'tls.crt' will be used.

The YAML key name of the

private key in the secret.
kubernetes.privateKeyNa If not given, 'key.pem' is
Optional; string.
me used in case of secretType
'generic'. For secretType
'tls', 'tls.key' will be used.
Parameter Type Explanation

The type of the

Kubernetes secret, either
'generic' or 'tls'. Note that
privateKeyName and
certificateName will be
overwritten in case of 'tls',
if specified. Default is
generic.

It is not supported to
change the value of
secretType for an existing
CR. In case the secretType
kubernetes.secretType Optional; string.
is changed, the
corresponding certificate
will not be renewed
anymore and the following
printout will appear in the
log: "<NAME-OF-THE-
CHANGED-SECRET> secret
could not be updated.
Reason: Unprocessable
Entity. Please check the
corresponding certificate
for appropriate
secretType!"

The format of the private

kubernetes.privateKeyFor key in the secret. One of
Optional; string.
mat 'pkcs1' or 'pkcs8'. If not
given, 'pkcs8' is used.

The Subject Common

Name (CN) of the
certificate. This typically
certificate.subject.cn Mandatory; string.
corresponds to the
hostname of the service
or a client identifier.
Parameter
certificate.validity.override
Ttl
certificate.validity.override
LeadTime
certificate.issuer.reference
Type Explanation
The duration (seconds)
that the certificate is
valid. This is an absolute
value. If not specified, the
default time to live
configured in SIP-TLS is
used.
Warning: Although the
lifetime of the generated
certicate can be increased
significantly by the
appropriate setting of cert
Optional; integer.
ificate.validity.overrideTtl,
generating long-lived
certificates is not
recommended in general.
Requiring SSL/TLS
certificates to be renewed
after a shorter period is a
good practice and the
built-in default values for
validLifetimeSeconds are
considered to be secure.
See also Dependencies
The absolute time
(seconds) of how much
before the certificate
expiration the renewal is
wanted to be done. If not
given, the lead time is
calculated from the
default renewal threshold
ratio configured in SIP-TLS
and the lower one of the
Optional; integer.
default time to live and
certificate.validity.override
Ttl. (For renewal details
and examples see the Use
rGuide)
Lead time must be smaller
than the certificate
validity time.
See also Dependencies.
The identifier for the
Issuer CA. Decides from
which CA to request the
certificate. It must be the
same as the
InternalUserCA Custom
Optional; string. Resource metadata.name
field. If left empty, the
certificate
is issued by SIP-TLS
intermediate CA which is
part of the SIP-TLS trusted
root CA chain.
 Parameter Type Explanation

Whether to populate the

certificate.subjectAlternati
veName.populateKuberne
tesDns
Subject Alt Name with
fully qualified DNS names
of the cluster, based on
the common name value
from
'certificate.subject.cn'. If
true, the following DNS
names are populated
Optional; boolean.
automatically: '<common-
name>, '<common-
name>.<namespace>', '<co
mmon-
name>.<namespace>.svc',
'<common-
name>.<namespace>.svc.
<cluster-domain>'. If not
given, defaults to True.

List of additional DNS

certificate.subjectAlternati
veName.dns
names to populate into
Subject Alt Name field.
Optional; sequence
The DNS names are given
consisting of strings.
as is, without the 'DNS:'-
prefix. For example:
'localhost'

Whether Extended Key

certificate.extendedKeyUs Usage flag 'TLS Web
Mandatory; boolean.
age.tlsClientAuth Client Authentication' is
set or not.

Whether Extended Key

certificate.extendedKeyUs Usage flag 'TLS Web
Mandatory; boolean.
age.tlsServerAuth Server Authentication' is
set or not.

Note: Fully Qualified Domain Names (FQDN) are recommended to be used in the
Custom Resource parameters for domain names. Using short names can cause issues
with the name resolution.

The default time-to-live (TTL) for the certificates is one week (604800 seconds), but it
can be extended by replacing it with the override-ttl attribute value. Extending TTL
should be done with extreme care and only for the most critical certificates. This
should not be used for creating unnecessary long-lived certificates, since using short-
lived certificates for internal communication is an architectural decision. See SIP-TLS
Service User Guide UserGuide for further information on certificate renewal.

4.2.1.1. The Kubernetes Secret

• Server Authentication

The following certificates and keys are stored for the server side in the Kubernetes
Secrets by SIP-TLS. The mount names are defined in the Custom Resource declaration
file, but the names of the actual certificates and keys as they appear in the container
file system are as given in the table below.

Secret Name File Name Content Description

eric-sec-sip-tls-trusted- The trusted CA

cacertbundle.pem
root-cert certificate(s)
 Secret Name File Name Content Description

The trusted CA
eric-sec-sip-tls-trusted- certificate(s). It has the
ca.crt
root-cert same content as
cacertbundle.pem.

<the-service-defined-
server-cert-secret-
name>
A certificate chain
containing the server
srvcert.pem certificate concatenated
with the intermediate CA
certificate

<the-service-defined-
server-cert-secret- srvprivkey.pem The server private key
name>

• Client Authentication

The following certificate and private key are stored for the client side in the
Kubernetes Secrets by SIP-TLS. The mount names are defined in the Custom Resource
declaration file, but the names of the actual certificates and keys as they appear in
the container file system are as given in the table below.

Secret Name File Name Content Description

<the-service-defined-
client-cert-secret- clicert.pem The client certificate
name>

<the-service-defined-
client-cert-secret- cliprivkey.pem The client private key
name>

4.2.2. InternalUserCA Custom Resource

The InternalUserCA CR is used to communicate the CA certificate-related parameters

and the Kubernetes Secret name.

API Group/Version Kind

siptls.sec.ericsson.com/v1 InternalUserCA

In the InternalUserCA, 'metadata.name' field is also part of the public API. It serves as
the reference that clients use when choosing the CA which will sign the certificate.
The InternalCertificate parameter 'certificate.issuer.reference' refers to this field.

The following parameters are supported (under YAML 'spec' section):

Parameter Type Explanation

The name of the secret

where the CA certificate is
kubernetes.generatedSecr
Mandatory; string. stored. Note: the same
etName
secret must not be used
for multiple purposes.

The YAML key name of the

kubernetes.certificateNam CA certificate in the
Optional; string.
e secret. If not given,
'ca.pem' is used.
 Parameter Type Explanation

The Subject Common

certificate.subject.cn Mandatory; string. Name (CN) of the CA
certificate.

Note: Fully Qualified Domain Names (FQDN) are recommended to be used in the
Custom Resource parameters for domain names. Using short names can cause issues
with the name resolution.

4.2.2.1. The Kubernetes Secret

The following certificate is stored for the InternalUserCA in the Kubernetes Secrets by
SIP-TLS.

Secret Name File Name Content Description

<the-service-defined-
client-cacertbundle.pem The client CA certificate
client-ca-secret-name>

5. Server and Client Certificate APIs (old, to be

deprecated and removed)
Note: These APIs have been replaced by Internal Certificate API.

The Server Certificate API can be used to enable server authentication and peer to
peer authentication.

The Client Certificate API can be used to enable client authentication.

Server Certificate API and Client Certificate API can be combined to enable mutual
authentication between the service provider and the service consumer.

In circumstances when the service does not allow configuring both server certificate
and client certificate, mutual authentication can be achieved by using Server
Certificate API and following the use case for peer to peer authentication.

5.1. Server Certificate API Description (old, soon-to-be-

deprecated)

The com.ericsson.sec.tls API (SIP-TLS API) provides means for a service provider to
request creation of a server certificate and a private key. The SIP-TLS stores the
created certificate material to a Kubernetes secret resource for the service provider to
use. For service consumers, the SIP-TLS API provides Kubernetes secret containing a
bundle of trusted root CA certificates.

The service providers define server certificate content in ServerCertificate and access
certificate material through the volume mount in the pod template to the Kubernetes
Secret containing the requested server certificate.

The service consumers gain access to the root CA certificates through the volume
mount in the pod template to the Kubernetes Secret containing them.

The certificates and keys are automatically renewed before they expire according to
the certificate time to live. The service providers and consumers are responsible for
monitoring the mounted volumes in order to be able to detect the certificate
renewals.

5.1.1. Custom Resource Definition

Custom Resource Definition (CRD) is defined as a feature which enables users to

add their own/custom objects to the Kubernetes cluster and use it like any other
native Kubernetes objects. Definition, configuration and usage of the CRDs can be
found on Kubernetes site KubernetesCRD.

The following Custom Resources specification file is used to provide the content of the
certificate and the Kubernetes Secret name for the certificate. The certificate is
configured by the ServerCertificate Custom Resource declaration file.

apiVersion: com.ericsson.sec.tls/v1alpha1
kind: ServerCertificate
metadata:
name: {{ template "example-service-provider.name" . }}
spec:
## Mandatory; string
## The Kubernetes Secret where the server certificate and key are
stored.
## Must be unique.
generated-secret-name: <the-service-defined-server-cert-secret-name>

## Mandatory; string
## The Subject CN within the server certificate.
common-name: <the-service-name>

## Optional; array of strings

## List of additional DNS names to populate into subject alt name
field.
#additional-sans:
# - DNS:<my.custom.dns.name>

## Optional; integer, given in seconds

## The time-to-live of the certificate. Uses SIP-TLS default if not
provided.
#override-ttl:

The names (written with <..>) in the Custom Resource declaration files must be
defined by the service provider.

Service provider receives the TLS server certificate with Subject Common Name and
Subject Alternative Name according to the common-name and additional-sans
fields.

By default the Subject Alternative Name of the certificate will include the following.

DNS:<the-service-name>
DNS:<the-service-name>.<namespace>
DNS:<the-service-name>.<namespace>.svc
DNS:<the-service-name>.<namespace>.svc.cluster
DNS:<the-service-name>.<namespace>.svc.cluster.local

The default time-to-live (TTL) for the certificates is one week (604800 seconds), but it
can be extended by replacing it with the override-ttl attribute value. Extending TTL
should be done with extreme care and only for the most critical certificates. This
should not be used for creating unnecessary long-lived certificates, since using short-
lived certificates for internal communication is an architectural decision. See SIP-TLS
Service User Guide UserGuide for further information on certificate renewal.

5.1.2. The Kubernetes Secret

The following certificates and keys related to the server certificate feature are stored
in the Kubernetes Secrets by SIP-TLS. The mount names are defined in the Custom
Resource declaration file, but the names of the actual certificates and keys as they
appear in the container file system are as given in the table below.
 Secret Name File Name Content Description

eric-sec-sip-tls-trusted- The trusted CA

cacertbundle.pem
root-cert certificate(s)

The trusted CA
eric-sec-sip-tls-trusted- certificate(s). It has the
ca.crt
root-cert same content as
cacertbundle.pem.

A certificate chain
<the-service-defined- containing the server
server-cert-secret- srvcert.pem certificate concatenated
name> with the intermediate CA
certificate

<the-service-defined-
server-cert-secret- srvprivkey.pem The server private key
name>

Mount points for the secrets are given by the service provider and service consumer
Resource declaration files.

5.2. Client Certificate API Description (old, soon-to-be-

deprecated)

The SIP-TLS API (com.ericsson.sec.tls) is used for requesting and providing Client CA
Certificate for the service provider and client certificates and associated private keys
for the service consumer. The certificate content and the distribution storage volume
in the pod template can be configured in Resource declaration files.

The client certificates and private keys are automatically renewed before expiration.
The service consumers are responsible for monitoring the mounted volumes in order
to be able to detect the certificate renewals.

The Client CA Certificate is a root CA certificate and as such, it has a fixed long
expiration period. The long expiration period helps to avoid a situation where the CA
certificates expire e.g. due to clock skew or system clock resetting to Epoch. This also
helps to avoid scenarios where the Client Certificates and Client CA Certificates expire
simultaneously causing potentially a long break in service.

The SIP-TLS provided Client CA Certificate has a time-to-live period of 100 years.

5.2.1. Custom Resource Definition

Custom Resource Definition (CRD) is defined as a feature which enables users to

add their own/custom objects to the Kubernetes cluster and use it like any other
native Kubernetes objects. Definition, configuration and usage of the CRDs can be
found on Kubernetes site KubernetesCRD.

The following Custom Resources specification files are used to provide the content of
the certificates and the Kubernetes Secret names for the certificates.

5.2.1.1. CertificateAuthority Custom Resource

This Custom Resource is defined in the service provider's helm package.

apiVersion: com.ericsson.sec.tls/v1alpha1
kind: CertificateAuthority
metadata:
name: {{ template "example-service-provider.name" . }}-ca
spec:
## Mandatory; string
## The Kubernetes Secret where the CA certificate is stored.
 ## Must be unique.
generated-secret-name: <the-service-defined-client-ca-secret-name>

## Mandatory; string
## CA certificate Issuer/Subject CN. E.g. "<service-name> Internal
Client CA".
common-name: <the-ca-common-name>

The names (written with <..>) in the Custom Resource declaration file must be
defined by the service provider.

The service provider receives the Client Certificate CA with Subject Common Name.

The Client Certificate CA has 100 years time to live duration.

5.2.1.2. ClientCertificate Custom Resource

This Custom Resource is defined in the service consumer's helm package.

apiVersion: com.ericsson.sec.tls/v1alpha1
kind: ClientCertificate
metadata:
name: {{ template "example-service-consumer.name" . }}-consumer-
certificate
spec:
## Mandatory; string
## The Kubernetes Secret where the client certificate and key are
stored.
## Must be unique.
generated-secret-name: <the-service-defined-client-cert-secret-name>

## Mandatory; string
## The Subject CN within the client certificate
common-name: <the-service-name>

## Mandatory; string
## The identifier for the service provider client CA. Decides from
which CA to request the client certificate.
## This refers to field 'CertificateAuthority.metadata.name' in the
'CertificateAuthority'.
issuer-ref: <ca-certificate-resource-name>

## Optional; integer, given in seconds

## The time-to-live of the certificate. Uses SIP-TLS default if not
provided.
#override-ttl:

The names (written with <..>) in the Custom Resource declaration file must be
defined by the service consumer.

The default time-to-live (TTL) for the certificates is one week (604800 seconds), but it
can be extended by replacing it with the override-ttl attribute value. Extending TTL
should be done with extreme care and only for the most critical certificates. This
should not be used for creating unnecessary long-lived certificates, since using short-
lived certificates for internal communication is an architectural decision. See SIP-TLS
Service User Guide UserGuide for further information on certificate renewal.

5.2.2. The Kubernetes Secret

The following certificates and private keys related to the client certificate feature are
stored in the Kubernetes Secrets by SIP-TLS. The mount names are defined in the
Custom Resource declaration file, but the names of the actual certificates and keys as
they appear in the container file system are as given in the table below.
 Secret Name File Name Content Description

<the-service-defined-
client-cacertbundle.pem The client CA certificate
client-ca-secret-name>

<the-service-defined-
client-cert-secret- clicert.pem The client certificate
name>

<the-service-defined-
client-cert-secret- cliprivkey.pem The client private key
name>

6. Note about Dependencies

This service depends on the Key Management Service (KMS). If KMS backend for
persistent data is configured to be Distributed Coordinator ED (DCED), SIP-TLS service
indirectly depends also on DCED. This applies also to the connections between those
services. Since TLS connections are used between the SIP-TLS, KMS and DCED, the
expiration of KMS or DCED certificates (due to SIP-TLS outage) may prevent the
restoration of the SIP-TLS.

In case of older version of KMS or DCED not defining the high certificate renewal
frequency with the Internal Certificate API CR attribute
certificate.validity.overrideLeadTime, the set of optional SIP-TLS deployment attributes
.renewalThresholdRatio can be used, see UserGuide.

7. The CRD and SIP-TLS API Versioning

The following table describes the relation between the Custom Resource Definition
(CRD) and SIP-TLS API versioning. Only the latest version of the applicable
documentation is included.

CRD Group/Version CRD Kind SIP-TLS API Version

siptls.sec.ericsson.com/v1 InternalCertificate 1.0.0

siptls.sec.ericsson.com/v1 InternalUserCA 1.0.0

siptls.sec.ericsson.com/
InternalCertificate 0.3.0-alpha
v1alpha1

siptls.sec.ericsson.com/
InternalUserCA 0.3.0-alpha
v1alpha1

com.ericsson.sec.tls/
ServerCertificate 0.2.0-alpha
v1alpha1

com.ericsson.sec.tls/
CertificateAuthority 0.2.0-alpha
v1alpha1

com.ericsson.sec.tls/
ClientCertificate 0.2.0-alpha
v1alpha1

8. Version History
8.1. Version 1.0.0

• The following CRDs were promoted from v1alpha1 to stable version. The actual
API content remain the same. Stable version shall be used whenever possible.

• internalcertificates.siptls.sec.ericsson.com/v1
 • internalusercas.siptls.sec.ericsson.com/v1

8.2. Version 0.3.0-alpha

• New API introduced with the following CRDs:

• internalcertificates.siptls.sec.ericsson.com/v1alpha1

• internalusercas.siptls.sec.ericsson.com/v1alpha1

8.3. Version 0.2.0-alpha

Backwards compatible changes which contains the following additions, along with
minor editorial fixes:

• The Kubernetes secret eric-sec-sip-tls-trusted-root-cert now contains another file

named ca.crt, which has the same content as cacertbundle.pem.
• Added peer to peer use case under the Server Certificate API subsection.

8.4. Version 0.1.0-alpha

Initial version

• Server Certificate API introduced with the following CRD:

• servercertificates.com.ericsson.sec.tls/v1alpha1

• Client Certificate API introduced with the following CRDs:

• clientcertificates.com.ericsson.sec.tls/v1alpha1

• certificateauthorities.com.ericsson.sec.tls/v1alpha1

9. References
Service Identity Provider TLS User Guide doc-no:[1/1553-APR 201 36/2]
Service Identity Provider TLS Application Developers Guide doc-no:[1/198 17-APR 201
36/2]
Kubernetes / Custom Resources doc-no