Service serving certificate secrets are intended to support complex middleware
applications that need out-of-the-box certificates. It has the same settings as
the server certificates generated by the administrator tooling for nodes and
To secure communication to your service, have the cluster generate a signed
serving certificate/key pair into a secret in your namespace. To do this, set
service.alpha.openshift.io/serving-cert-secret-name annotation on your
service with the value set to the name you want to use for your secret. Then,
your PodSpec can mount that secret. When it is available, your pod will run.
The certificate will be good for the internal service DNS name,
The certificate and key are in PEM format, stored in
respectively. The certificate/key pair is automatically replaced when it gets
close to expiration. View the expiration date in the
service.alpha.openshift.io/expiry annotation on the secret, which is in
In most cases, the service DNS name
<service.name>.<service.namespace>.svc is not externally routable. The
primary use of
<service.name>.<service.namespace>.svc is for intracluster or
intraservice communication, and with re-encrypt routes.
Other pods can trust cluster-created certificates (which are only signed for
internal DNS names), by using the CA bundle in the
/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt file that is
automatically mounted in their pod.
The signature algorithm for this feature is
x509.SHA256WithRSA. To manually
rotate, delete the generated secret. A new certificate is created.