$ oc create secret tls <certificate> \(1)
--cert=</path/to/cert.crt> \(2)
--key=</path/to/cert.key> \(3)
-n openshift-ingress
- Documentation
- OpenShift Container Platform
- Authentication
- Configuring certificates
- Replacing the default ingress certificate history
OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
- About
- Release notes
- Architecture
- Installing
- Updating clusters
- Support
- Web console
- Authentication
- Understanding authentication
- Configuring the internal OAuth server
- Understanding identity provider configuration
- Configuring identity providers
- Configuring an HTPasswd identity provider
- Configuring a Keystone identity provider
- Configuring an LDAP identity provider
- Configuring a basic authentication identity provider
- Configuring a request header identity provider
- Configuring a GitHub or GitHub Enterprise identity provider
- Configuring a GitLab identity provider
- Configuring a Google identity provider
- Configuring an OpenID Connect identity provider
- Configuring certificates
- Using RBAC to define and apply permissions
- Removing the kubeadmin user
- Configuring the user agent
- Understanding and creating service accounts
- Using service accounts in applications
- Using a service account as an OAuth client
- Scoping tokens
- Managing Security Context Constraints
- Impersonating the system:admin user
- Syncing LDAP groups
- Networking
- Storage
- Understanding persistent storage
- Configuring persistent storage
- Persistent storage using AWS Elastic Block Store
- Persistent storage using Fibre Channel
- Persistent storage using NFS
- Persistent storage using hostPath
- Persistent Storage using iSCSI
- Persistent storage using Container Storage Interface (CSI)
- Persistent storage using VMware vSphere
- Persistent storage using volume snapshots
- Expanding persistent volumes
- Dynamic provisioning
- Registry
- Builds
- Understanding image builds
- Understanding build configurations
- Creating build inputs
- Managing build output
- Using build strategies
- Custom image builds with Buildah
- Performing basic builds
- Triggering and modifying builds
- Performing advanced builds
- Using Red Hat subscriptions in builds
- Securing builds by strategy
- Build configuration resources
- Troubleshooting builds
- Setting up additional trusted certificate authorities for builds
- Images
- Applications
- Machine management
- Nodes
- Working with pods
- Controlling pod placement onto nodes (scheduling)
- About pod placement using the scheduler
- Configuring the default scheduler to control pod placement
- Placing pods relative to other pods using pod affinity and anti-affinity rules
- Controlling pod placement on nodes using node affinity rules
- Placing pods onto overcommited nodes
- Controlling pod placement using node taints
- Placing pods on specific nodes using node selectors
- Using Jobs and DaemonSets
- Working with nodes
- Working with containers
- Using containers
- Using Init Containers to perform tasks before a pod is deployed
- Using volumes to persist container data
- Mapping volumes using projected volumes
- Allowing containers to consume API objects
- Copying files to or from a container
- Executing remote commands in a container
- Using port forwarding to access applications in a container
- Working with clusters
- Logging
- About cluster logging
- About deploying cluster logging
- Deploying cluster logging
- Viewing the Kibana interface
- Deploying and Configuring the Event Router
- Configuring your cluster logging deployment
- Viewing Elasticsearch status
- Moving the cluster logging resources with node selectors
- Manually rolling out Elasticsearch
- Troubleshooting Kibana
- Exported fields
- Uninstalling cluster logging
- Monitoring
- Telemetry
- Scalability and performance
- Backup and restore
- CLI reference
- Service Mesh
- Serverless applications
- Getting started with OpenShift Serverless
- OpenShift Serverless product architecture
- Installing OpenShift Serverless
- Getting started with Knative services
- Monitoring OpenShift Serverless components
- Cluster logging with OpenShift Serverless
- Configuring Knative Serving autoscaling
- Using Knative Client
- Release Notes
×
Replacing the default ingress certificate
Understanding the default ingress certificate
By default OpenShift Container Platform uses the Ingress Operator to
create an internal CA and issue a wildcard certificate that is valid for
applications under the .apps sub-domain. Both the web console and CLI
use this certificate as well.
The internal infrastructure CA certificates are self-signed.
While this process might be perceived as bad practice by some security or
PKI teams, any risk here is minimal. The only clients that implicitly
trust these certificates are other components within the cluster.
Replacing the default wildcard certificate with one that is issued by a
public CA already included in the CA bundle as provided by the container userspace
allows external clients to connect securely to applications running under the .apps sub-domain.
Replacing the default ingress certificate
You can replace the default ingress certificate for all
applications under the .apps subdomain. After you replace
the certificate, all applications, including the web console
and CLI, will have encryption provided by specified certificate.
Prerequisites
-
You must have a wildcard certificate and its private key, both in the PEM format, for use.
-
The certificate must have a
subjectAltNameextension of*.apps.<clustername>.<domain>.
Procedure
-
Create a secret that contains the wildcard certificate and key:
1 <certificate>is the name of the secret that will contain the certificate and private key.2 </path/to/cert.crt>is the path to the certificate on your local file system.3 </path/to/cert.key>is the path to the private key associated with this certificate. -
Update the Ingress Controller configuration with the newly created secret:
$ oc patch ingresscontroller.operator default \ --type=merge -p \ '{"spec":{"defaultCertificate": {"name": "<certificate>"}}}' \(1) -n openshift-ingress-operator1 Replace <certificate>with the name used for the secret in the previous step.