mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
46 lines
3.0 KiB
Plaintext
46 lines
3.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * microshift_security_compliance/microshift-custom-ca.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="microshift-custom-cas_{context}"]
|
|
= How custom certificate authorities work in {microshift-short}
|
|
|
|
The default API server certificate is issued by an internal {microshift-short} cluster certificate authority (CA). Clients outside of the cluster cannot verify the API server certificate by default. This certificate can be replaced by a custom server certificate that is issued externally by a custom CA that clients trust. The following steps illustrate the workflow in {microshift-short}:
|
|
|
|
. Copy the certificates and keys to the preferred directory in the host operating system. Ensure that the files are accessible by root only.
|
|
|
|
. Update the {microshift-short} configuration for each custom CA by specifying the certificate names and new fully qualified domain name (FQDN) in the {microshift-short} `/etc/microshift/config.yaml` configuration file.
|
|
+
|
|
Each certificate configuration can contain the following values:
|
|
|
|
** The certificate file location is a required value.
|
|
** A single common name containing the API server DNS and IP address or IP address range.
|
|
+
|
|
--
|
|
[TIP]
|
|
====
|
|
In most cases, {microshift-short} generates a new `kubeconfig` for your custom CA that includes the IP address or range that you specify. The exception is when wildcards are specified for the IP address. In this case, {microshift-short} generates a `kubeconfig` with the public IP address of the server. To use wildcards, you must update the `kubeconfig` file with your specific details.
|
|
====
|
|
--
|
|
** Multiple Subject Alternative Names (SANs) containing the API server DNS and IP addresses or a wildcard certificate.
|
|
** You can provide additional DNS names for each certificate.
|
|
|
|
. After the {microshift-short} service restarts, you must copy the generated `kubeconfig` files to the client.
|
|
|
|
. Configure additional CAs on the client system. For example, you can update CA bundles in the {op-system-base-full} truststore.
|
|
|
|
. The certificates and keys are read from the specified file location on the host. Testing and validation of configuration is done from the client.
|
|
|
|
. External server certificates are not automatically renewed. You must manually rotate your external certificates.
|
|
|
|
[NOTE]
|
|
====
|
|
If any validation fails, the {microshift-short} service skips the custom configuration and uses the default certificate to start. The priority is to continue the service uninterrupted. {microshift-short} logs errors when the service starts. Common errors include expired certificates, missing files, or incorrect IP addresses.
|
|
====
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Custom server certificates have to be validated against CA data configured in the trust root of the host operating system. For information, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/securing_networks/using-shared-system-certificates_securing-networks#the-system-wide-trust-store_using-shared-system-certificates[The system-wide truststore].
|
|
====
|